Skip to content

Commit

Permalink
added pictures, spellcheck, removed sections, clean up intro
Browse files Browse the repository at this point in the history
  • Loading branch information
Steve Krouse committed Dec 25, 2018
1 parent dc10b83 commit 43a27ed
Showing 1 changed file with 34 additions and 45 deletions.
79 changes: 34 additions & 45 deletions about.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2,47 +2,52 @@
title: About
---

# About
<h1>About</h1>

## tl;dr
Future of Coding is a [community](/slack), [podcast](/episodes), and [research project](/log) organized by Steve Krouse.

Future of Coding is a research project and podcast by me, Steve Krouse. My research is focused on building an open-source programming langauge. The podcast alternates between interviews with programming language experts and reflections on my own research journy.
The community lives on Slack: you can [join here](/slack) and [learn more here](slack-readme). The podcast alternates between interviews with programming language experts and reflections on my own research journy. My research is focused on building an open-source programming langauge.

This work is funded by [repl.it](https://repl.it) and my generous patrons. If you find this work valuable, [please consider supporting](https://patreon.com/stevekrouse).

## Me

Hi, my name is Steve Krouse. When I meet people, I like to begin with life stories. Context is important. Here's mine - as it relates to this project:
<img src="https://user-images.githubusercontent.com/2288939/50344796-70be6c00-0524-11e9-8e01-5d3c6ae89ff7.png" height="300px">

I was born in NYC in 1994 and raised in South Florida.
Hi, my name is Steve Krouse. When I meet people, I like to begin with life stories. Context is important. Here's mine - as it relates to this project:

As a kid, I was "bad at school", and particularly "bad at math." However, as I was a "computer kid", I started going to a wonderful after-school computer science program, [IMACS](https://imacs.org). Through learning LOGO, Scheme, Java, and Haskell in middle school and high school at IMACS's self-paced, nurturing environment, I became a computational, mathmatical, and introspective thinker. I became very good at school, especially mathematics and physics.
As a kid, I was particularly "bad at math." However, as I was a computer nerd, I started going to a wonderful after-school computer science program, [IMACS](https://imacs.org). Through learning LOGO, Scheme, Java, and Haskell in middle school and high school at IMACS's self-paced environment, I became a computational, mathematical, and introspective thinker. I became very good at school, especially mathematics and physics.

I went to the University of Pennslyvania for college. After taking most of the CS classes at Penn, I left without graduating in early 2014, and went to work at [Looker](https://looker.com). I left Looker at the end of 2014.
I went to the University of Pennsylvania for college. After taking most of the CS classes at Penn, I left without graduating in early 2014, and went to work at [Looker](https://looker.com). I left Looker at the end of 2014.

While at college and Looker, I was deeply influenced by Bret Victor and Seymour Papert. Ever since my experience of transforming from a self-identified "stupid person" to a "smart person" in middle school, I was curious about how it happened and if similar changes could be nurtured in others. Reading Papert in college, I learned that my own transformation was was no accident - Papert intentially set out to create mathmatical thinkers from math-haters with LOGO, and he accomplished his goal in me.
While at college and Looker, I was deeply influenced by Bret Victor and Seymour Papert. Ever since my experience of transforming from a self-identified stupid person to a smart person in middle school, I was curious about how it happened and if similar changes could be nurtured in others. Reading Papert in college, I learned that my own transformation was was no accident - Papert intentionally set out to create mathematical thinkers from math-haters with LOGO, and he accomplished his goal in me.

With these thoughts in mind, in July 2015 I co-founded [The Coding Space](https://thecodingspace.com), where we taught kids to code in a self-paced environment similar in spirit to IMACS. I created [a Scratch-based curriculum](https://coding.space), as well as [WoofJS](https://woofjs.com), a JavaScript framework and oneline IDE to transition kids from Scratch to JS.
With these thoughts in mind, in July 2015 I co-founded [The Coding Space](https://thecodingspace.com), where we taught kids to code in a self-paced environment similar in spirit to IMACS. I created [a Scratch-based curriculum](https://coding.space), as well as [WoofJS](https://woofjs.com), a JavaScript framework and online IDE to transition kids from Scratch to JS.

In mid-2017, I left The Coding Space to work on programming langauges full time.
In mid-2017, I left The Coding Space to work on programming languages full time.

At first, I thought I'd have the whole thing solved in just a matter of months, all by myself. I was wrong. While I did make some interesting prototypes, I spent a lot of time retracing the steps of those that came before me. I learned the hard way that I need to read my history.

In the summer of 2017, I was approached by Irvin Hwang who suggested starting a NYC-based meetup group for people interested in the future of programming. I thought that was the dumbest idea I'd ever heard: why talk to other people when I could read Alan Kay papers in my room? But I went to the first meeting and it blew my mind wide open. I learned so much in that hour! It inspired my [log](./log) which has become the core of my research practice. After Irvin became busy with his new job, I took over the group, and created a Slack for "future of programming folks" all over the world. I learned the easy way the importance of community.

It was also around this time that I began the podcast. It alternates between recapping my own research and speaking with experts. It's been an incredibly valuable experience for me, helping add structure to my research, gaining new insights through collaboration, encouraging me to reflect on my progress, and giving me energy as people respond to my episodes with exciement and ideas of their own.
![image](https://user-images.githubusercontent.com/2288939/50345144-e5de7100-0525-11e9-8404-6162ccfc2bfd.png)
_Future of Coding London Meetup #1 (Nov 2018)_

It was also around this time that I began the podcast. It alternates between recapping my own research and speaking with experts. It's been an incredibly valuable experience for me, helping add structure to my research, gaining new insights through collaboration, encouraging me to reflect on my progress, and giving me energy as people respond to my episodes with excitement and ideas of their own.

My framing for this project has gone through a number of turbulent stages (Bret-Victor-wannabe, total-disenhartenment, irrational exuberance, etc), but I have recently (as of Fall 2018) come to a very positive mental space, described below. These days, I describe myself as a *programming language designer*, because my goal is to create a working system (not just produce research) that resembles a programming langauge in its expressive power, but will feel more like a system in the Excel or Smalltalk sense than a text-and-compiler-based programming language.
My framing for this project has gone through a number of turbulent stages (Bret-Victor-wannabe, total-disenhartenment, irrational exuberance, etc), but I have recently (as of Fall 2018) come to a very positive mental space, described below. These days, I describe myself as a *programming language designer*, because my goal is to create a working system (not just produce research) that resembles a programming language in its expressive power, but will feel more like a system in the Excel or Smalltalk sense than a text-and-compiler-based programming language.

## Mission

The mission of this project is to *enable all people[1] to modify the software they use in the course of using it*.
The mission of this project is to *enable all people [[1](#1)] to modify the software they use in the course of using it*.

This mission would cause the following changes, in order of increasing importance:

1. All software will be co-created by decentralized communities, rather than centralized groups or companies.
2. Through the power of crowd-sourcing, the quality of all software will become much higher than existing software.
3. All software will be much more composible, interoperable with other pieces of software.
4. All software will be arbitrarily customizable, allowing for bespoke, tailored experiences.
5. Learning to communicate with computers teaches one how to think more clearly, precisely, mathmatically, and powerfully. If one can manipulate the software one uses, if only one learns how to organize one's thoughts, many people will self-teach themselvse to do just that.
5. Learning to communicate with computers teaches one how to think more clearly, precisely, mathematically, and powerfully. If one can manipulate the software one uses, if only one learns how to organize one's thoughts, many people will self-teach themselves to do just that.
6. As the fabric of the world is eaten by software, the ability to fully manipulate that software one uses is an essential freedom.

This vision is not new nor creative: it's obvious that people would change things if they could. Yet this problem has proven stubborn over the decades and most have given it up as insoluble. We have all but forgotten the essential characteristic of computers: their malleability.
Expand All @@ -60,13 +65,21 @@ My (current) angle on this problem is most influenced by:
And is comprised of the following claims:

1. The *comprehensibility* of *large* software is of utmost importance.
2. In order to enable comprehensibility without sacraficing expressivity, we must strive to eliminate all forms of incidental complexity in programming. Programming should be describing the essential nature of the problem: the view from the user - if the user were made to see all the implications of things.
3. Mathmatics is the langauge of essence, or as close as we can get. Something like the lambda calculus is the langauge of computation free of mechanical and historical accidents.
4. The solution is to create denotative languages, languages where each term denotes an equivalent mathmatical object.
2. In order to enable comprehensibility without sacrificing expressiveness, we must strive to eliminate all forms of incidental complexity in programming. Programming should be describing the essential nature of the problem: the view from the user - if the user were made to see all the implications of things.
3. Mathematics is the language of essence, or as close as we can get. Something like the lambda calculus is the language of computation free of mechanical and historical accidents.
4. The solution is to create denotative languages, languages where each term denotes an equivalent mathematical object.
5. We must [rid ourselves of the IO Monad](http://conal.net/blog/posts/can-functional-programming-be-liberated-from-the-von-neumann-paradigm), replacing it with better abstractions for whole systems.
6. We must have an editing experience that's lively and fluid. These mathmatical abstractions scare people because their UI stinks. This is a very difficult UI problem, but tractible.
6. We must have an editing experience that's lively and fluid. These mathematical abstractions scare people because their UI stinks. This is a very difficult UI problem, but tractable.

## Vague dream programming langauge system

All in all, there are 4 large problems to solve:

1. Replace the IO abstraction (on the front- and back- ends)
2. Improve the programming experience (PX) of strongly typed, denotative programming
3. Version control in a world with many, many more forks at many more levels
4. The adoption of this new system

## Vague dream programming language system

* Haskel-ish structured-ish editor in the style of Lamdu, early Unison prototypes, Dark, Luna, Isomorf, etc. This UI problem is large and unsolved. It will likely be one of the most complicated UIs ever created, and thus eventually bootstrapping would be great.
* Web based. It’d be great if it could run in browsers but not terrible to have it communicate over socket to begin with. Eventually compiling to WebAssembly will raise all boats.
Expand All @@ -80,30 +93,6 @@ Changing a definition only produces a new definition but you are given the optio

## Killer app

If/when this platform is built, the first app I'll build in it is a build-your-own-email-app kit. Everyone's email workflow is specific and it's a huge part of how we all run our lives. Being able to customize things to exactly how we'd like them would be a superpower. For myself, I'd like to be able to combine my email app with features of task management applications, such as re-ordering items and nesting items within other items. Part of the inspiration for this "killer app" is that Google Inbox, my preferred email client, is being shut down in a few months. The economics of building a consumer quality app only allows for lowest-common-denominator experiences. The only way to mantain sustainable personalized experiences is with a crowd-sourced development platform. I imagine we'd want to leverage GMail's API to do this.

### How is this different from...?

[This section is quite messy.]

* Unison? It’s web-based. More UI-builder focused than cloud-focused. Also more focused on the UI than the implementation... but so was Paul in early days.
* Lamdu? It's web-based. More UI-focused. It has no interest in reading or writing to files, putting characters on the terminal, opening sockets, etc.
* Luna? Web-based. More concerned with UI-builder and higher-level abstractions.
* Isomorf? It's more UI-builder focused. More of a focus on live-ness.
* Dark? It's more focused on the front-end.

## Open questions

1. Cannonical-ness - I’ve written about this elsewhere. I think it has to do with intense type and math theory stuff.
2. While we don’t want to expose IO to the user at all, we do want to enable developers of this tool to write abstractions over IO. How do we handle that? The way Haskell does, with the IO monad?
3. Version control in a world with a ridiculous amount of branches on branches on branches on branches.

## Next steps

1. Protoyping live interface in graphics
2. Learning about how to implement some of these features / PL theory, playing in code
3. Abstracting over cloud data, users, authentication, permissioning, realtime games, Real World, etc

[1] - "All people" is a strong phrase. Apparently 77% of Wikipedia is written by 1% of editors - and that's not even counting users. The difference with software is that people will want to customize it for themselves, while Wikipedia is for a general audience, so there's less motivation to edit it.

If/when this platform is built, the first app I'll build in it is a build-your-own-email-app kit. Everyone's email workflow is specific and it's a huge part of how we all run our lives. Being able to customize things to exactly how we'd like them would be a superpower. For myself, I'd like to be able to combine my email app with features of task management applications, such as re-ordering items and nesting items within other items. Part of the inspiration for this "killer app" is that Google Inbox, my preferred email client, is being shut down in a few months. The economics of building a consumer quality app only allows for lowest-common-denominator experiences. The only way to maintain sustainable personalized experiences is with a crowd-sourced development platform. I imagine we'd want to leverage Gmail's API to do this.

<a name="1">[1]</a> - "All people" is a strong phrase. Apparently 77% of Wikipedia is written by 1% of editors - and that's not even counting users. The difference with software is that people will want to customize it for themselves, while Wikipedia is for a general audience, so there's less motivation to edit it.

0 comments on commit 43a27ed

Please sign in to comment.