Learnable Programming (2012)
worrydream.com
worrydream.com
To experiment with this example yourself, please follow the link: https://app.leporello.tech/?share_id=ece060b7c63121741be30fd...
As a shameless plug, earlier today I featured Leporello.js on Show HN [2]. If you have any questions, please feel free to ask.
When I open a text editor I am presented with an empty screen. I find this simultaneously reassuring and frustrating. Because changing sourcecode that someone else wrote is difficult: writing what YOU want is liberating. And two because you don't know what you can do until you know what you can do. (Read about available API functions. You have to learn lots of things.)
I can arrange glyphs into keywords and sentences of known keywords "for" "async" "await" "new" "function" You have to learn all these.
What I actually want to do is something similar to Terraform, I want to create an object, define all its properties and relationships and visually interact with it (such as in AWS console). I want moving it around to bidirectionally map to the glyphs.
I don't want to have to rerun the sourcecode to see if it does what I want, I want to CRUD create what I want exactly how I want it and the code be generated that creates that output.
Direct manipulation (of output).
Someone create a LISP that you can MOVE.
Bret Victor: Learnable Programming (2012) - https://news.ycombinator.com/item?id=27799420 - July 2021 (30 comments)
Learnable Programming (2012) - https://news.ycombinator.com/item?id=25331483 - Dec 2020 (48 comments)
Working Toward Bret Victor's “Learnable Programming” - https://news.ycombinator.com/item?id=10078089 - Aug 2015 (80 comments)
Designing a programming system for understanding programs - https://news.ycombinator.com/item?id=4864729 - Dec 2012 (2 comments)
Bret Victor: Learnable Programming - https://news.ycombinator.com/item?id=4577133 - Sept 2012 (183 comments)
Plus it's good for newer cohorts of HN users to get acquainted with the perennials and classics: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Issue is, if you were to inspect how they, the author themselves, someone who has personally and successfully learned programming, learned their skills at the beginning of their life, it would probably be 1) questionable ways to learn, and 2) nothing like what they are preaching.
I like reading pamphlets and this one makes sense, but what I'd like even more would be to look at people who succeeded and see what worked, then people who failed and see what didn't.
The way that many programmers came up is still available [1], and it is easier than ever to self-teach if you come at it with a similar set of faculties and obsessions and can just keep hacking at things until you understand it. The search for something new is to try to extend this to people who can't or won't follow that approach, for whatever reasons. Essays like this are trying to point out what he thinks those reasons are and how to build tools around them.
[1] I'm aware counterarguments to this, there's an ever-increasing gulf between popular computer entertainment and something a kid (or any single person) can do, and it's a lot more complicated to program even basic interactive things due to how much more complicated and protected computers are now.
Edit:
To expand on [1]: And there are projects, e.g. Processing.js, Scratch, Media Computation, OLPC, Raspberry Pi, and surely newer ones since I last followed the literature, that come at different angles of that problem.
Edit2: A large part of my own approach is to try making games where the player discovers what I find fascinating about programmable machines, so I can see what you're saying. But I am repelled when I approach a design that you need to already be a programmer to appreciate.
Two thoughts about learning:
-- Programming is a way of thinking, not a rote skill. Learning about "for" loops is not learning to program, any more than learning about pencils is learning to draw.
-- People understand what they can see. If a programmer cannot see what a program is doing, she can't understand it.
Thus, the goals of a programming system should be:
-- to support and encourage powerful ways of thinking
-- to enable programmers to see and understand the execution of their programs
The article disagrees with the idea that in order to _understand_ the machine, you must _become_ the machine. But, how to understand how it works without visualizing it quite concretely...
The ability to visualize and work with complex systems entirely in your head is a skill developed by an engineering education, and presumably by a software education too.
[ aaand... AI has entered the conversation ]
> In a modern environment, memorizing the minutia of an API should be as relevant as memorizing times tables.
I'm going to go out on a limb and suggest that some things should in fact be rote memorized when learning something new. For example, I do think that the multiplication table should be memorized, at least up until ten. I've counted floor tiles and made rectangles out of them with my growing children, but I made sure that certain very small, common multiplication products were repeated often enough to be memorized. Likewise, I do bother to memorize e.g. the intricacies of %f float representation with printf(). Memorizing does not preclude understanding root concepts.This is incorrect. If an artist doesn't know what pencils are, then leaning about pencils is learning how to draw.
> Thus, the goals of a programming system should be: to support and encourage powerful ways of thinking
People can naturally think, but they cannot naturally use advanced tools. The goal of education is to acquaint people with information they are lacking. It's not necessary to tell people how to think. Surprisingly enough, when you give a person the ability to build, thoughts on how to use tools will come organically.