Bret Victor's talks, particularly 'Learnable Programming' and especially 'Inventing On Principle' [0] served as the inspiration behind my creation of an IDE called Leporello.js [1]. You can find my interpretation of his example from 'Learnable Programming' here: https://vimeo.com/870708017
Thanks for this. I also want to use computers differently. I want them to present to me what they can do.
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.
I see "direct manipulation of output" and some boredom/frustration from reading internals of the source code, and I think the solution you seek is a kind of repl LLM, that would understand and rewrite on user input every internal code in order to produce the effect you may want.
In that case I'm glad you hadn't! Reposts of good things are just fine after a year or so. There's no reproach encoded in those "Related" lists. They're only there for curious readers who like to look at past discussions.
See, what I hate about those kinds of pamphlets is they're written by established programmers with an audience that they half-expect to be partially full of their peers. Therefore they are always careful not to sidestep into more dodgy advice out of fear of getting called out for preaching out bad practices.
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.
This is me projecting from my own thoughts on designing new ways to learn programming, which doesn't quite match with Bret Victor's approach but might be similar enough:
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.
-- 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
> -- 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.
> 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.
The way I see it: Memorizing puts things in your RAM (which may be slow to access), or CPU cache (if recently used). Looking them up would be equivalent to having them stored on your hard disk, or perhaps a remote system if you have to search a while to find them again. Clearly, this is a trade-off and the optimal approach depends on the specifics.
> Learning about "for" loops is not learning to program, any more than learning about pencils is learning to draw.
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.
Thx for posting this. I was trying to remember where I read this a few years back. Of course it was Bret Victor. Many of the very cool things I've seen in the last decade came from Bret.
I find quite funny that one reason why its "fill..ellipse" example is hard to read is because it's setting global variables and this is never discussed in the webpage.
> my_nice_color = color(161, 219, 114);
ellispe(65, 50, 60, 60, my_nice_color)
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.
[0] https://www.youtube.com/watch?v=PUv66718DII
[1] https://leporello.tech/
[2] https://news.ycombinator.com/item?id=37751041