| title |
|---|
About |
Welcome to the podcast and open-journal research project to create the future of coding.
Large advantages are confered upon those who know how to instruct computers:
-
As the fabric of the world becomes software, and those that can manipulate software become powerful magicians.
-
Learning to communicate with computers teaches one how to think more clearly, precisely, and powerfully.
These reasons, among many others, mean there is a lot of value in learning to code. This is why almost everyone who hears that I "teach coding to children" asks if I can teach them to code. However, the current cost of learning to code is high. Lowering this cost could vastly improve the world.
The cost of learning to code is high because the langauges and tools that we currently use to communicate with computers have poor usability:
-
They require hundreds of hours grueling of practice to learn to use.
-
Even after you are familiar with them, they are still not easy to use.
But we need not despair! We've repeately improved the usability of the tools by which we communicate with computers, from punchards and binary, to assembly, to Fortran, to C, to Python, to Haskell.
In fact, I believe that we can improve the usability of general programming to that of MIT's Scratch, or Microsoft Office applications like Word, Powerpoint or Excel, or even a user-friendly application like Facebook.
However, there's a mystery here: we haven't made much progress on this front in decades. If improvement is possible, where is it? What are the barriers?
I started working on this problem, developing programming languages prototypes, a few years ago. When I first began working on it, I thought I'd have the whole thing solved in just a matter of months. I was wrong.
While I did contribute some novel ideas to the space, 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, learn about what others have done here.
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 journal which at the time became the core of my research project. After Irvin became busy with his new job, I took over the group that I originally thought was a waste of time. What a 180 degree turn!
It was also around this time that I began my Future of Coding Podcast, where I alternate each week between recapping my own research and speaking with experts. It's been an incredibly valuable experience for me: 1) helping add structure to my research, 2) gain new insights through collaboration, 3) encourage me to reflect on my progress, and 4) give me energy as people respond to my episodes with exciement and ideas of their own.
While podcasting, journaling, reading papers, and playing with others' prototypes are key to the success of this project, they are only valuable insofar as they move me closer to my main objective. So what is this objective?
I want to live in a world where every human can make their thoughts precise enough for machines to understand them.
There are two parts to this goal:
-
Education. People need to learn to make their thoughts precise. This is often called "computational thinking." Even with amazing programming environments like LOGO or MIT Scratch, it takes students hundreds of hours to develop the thinking proccesses to communicate their ideas with computers. That's what my company The Coding Space is all about: providing an environment for students to learn computational thinking. This is to say, building an amazing tool is not enough.
-
Tools. However, building an amazing tool is an enabler! The work done at The Coding Space would not be possible without the work of Seymour Papert on LOGO which inspired Mitch Resnick to create MIT Scratch. And the work I've done on WoofJS also enables our students to learn more than they could've without the tool.
Thus you need both education and tools. As I move away from working at The Coding Space, I am shifting my focus from education to tools because I see that as currently the main limiting factor.
Our curriculum in Scratch is wonderful. Kids learn computational thinking while making fun games. This wonderful curriculum is continued in WoofJS where students work on learning more valuable concepts while building more complex games. However, there are two related problems:
- What do students do after they are done with WoofJS?
- What if students don't want to make simple and silly games in Scratch or WoofJS? What if they want to create real applications to solve real problems? Why should they have to mess around in toy programming environments for a couple hundred hours before getting to "real coding"? And then once they get to real coding why must these students spend hundreds more hours learning "real coding"'s tools with such poor usability?
Clearly what's needed is a tool with the power of a general-purpose programming language with the usability qualities of a standard end-user application
There are a few notable things missing from this goal which I want to make explicit:
-
My aim is not to create a company. My aim is to produce a tool. If it seems like a company is the best way to accomplish this aim, so be it. However, I aspire to be able to create this tool outside of a traditional company structure, more like Linux or CycleJS.
-
I don't need to be the person who creates this tool. I will judge this project an unqualified success if it somehow inspires or informs the creation of this tool by someone else. Would I prefer to create it myself? Yes, that does seem fun. However, I aspire to not be sad if someone beats me to the punch. I aspire to give that person a metaphorical high five, and them move on to the next world-changing project on my to-do list.
-
Yes, this goal is vague. I do not want to commit to what this tool will look like in its goal. You can read my specific design priciples about what it may look like here.
-
My time. Currently it's limited to 20ish hours per week for this project. Over time I will increase this time as I decrease my commitmentes to other projects. However, as my work-life balance is important to me (and to the long-term sustainability of this project), I will have a maximum of 40ish hours per week here. Thus it is important both to 1) spend my time in a maximally useful way and 2) to leverage other people.
-
Capital. While I do have enough capital to sustain myself working on this project indefinitely, I do not currently have the funds to sustain others. I wonder if this will become more of a blocker over time as I collaborate with others that need day jobs to pay the bills and what creative solutions we can come up with to overcome this.
-
Knowledge. While I have been programming for a decade and developing programming languages for years now, there is still so much more for me to learn. It sometimes feels endless, because even as I gain appreciation for all the work that has been done before, it is impossible to stay astride of all the new innovations in the field that are being developed constantly. Filtering out the noise will become increasingly important.
- Articulate the goal
- Come up with a plan to achieve the goal
- Get feedback on the plan, and revise the plan accordingly
- Attack the plan
- Periodically reflect on how the plan has made progress towards the goal. If the goal has not been acheieved, return to step 2. If it has been achieved, pick another goal and return to step 1.
I have the goal, and the strategy, so now I need a plan...
- Code on github.
- Engaged developer community.
- Engaged user community
- Compile target
- Early use cases
- Early customers
- Interface / paradigm
- Have an idea for a tool
- Begin prototyping it
- Test it out with users
- Iterate on it until it
- Get user traction
- Get contributor traction
- Manage its development until its ready to be passed onto someone else
There are a few different activities I can do:
- General research (like reading Alan Kay or Bret Victor)
- Working on a specific project (like reading Conal Elliot to learn about FRP for StreamSheets)
- Build a community (hosting meetups, connecting people, podcasting)
- High-level strategy (master planning like this)
But at the end of the day, only (2) working on a specific project will lead to the endgame. Everything else is just a way to arrive at (2). So the way to get there faster is by both 1) increasing the amount and quality of ideas, and 2) increasing the speed at which we can invalidate bad ideas.
I should partake in (1) general research only when trying to come up with better ideas because we don't have good ones to work on.
I'm not entirely clear how to think about (3) building a community, because while it won't directly lead to me accomplishing the endgame, it will increase the odds that I inspire someone else to, which would also accomplish my goal. As a reasonable approximation, I want to spend ~10% of my time (or 4 hours per week) on this.
Finally, I am finding a lot of value in Master Planning in this way. I think I should reflect on my progress towards this plan weekly if not more often, but set aside special time to think more deliberately about it.
TODO LINK
TODO LINK
TODO LINK
Blocks, structured editor, flow diagram, spreadsheet interface, multiple representations (email guy)
With FRP WoofJS, I know the compile target (HTML canvas, JS, Elm, or CycleJS), early use case (games and animations), and early users (my students at The Coding Space). The only think I don't know is the paradigm / interface for the tool.
get Paul's advice here, as well as Scott Mueller, Emmanuel Schnazer, and Christopher Anand.
read Conal Elliot, Ludcid, play with Elm, Pyret, Reflex
build a few toy apps
<script> (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','https://www.google-analytics.com/analytics.js','ga'); ga('create', 'UA-103157758-1', 'auto'); ga('send', 'pageview'); </script>