Bret Victor: Learnable Programming (2012)
worrydream.com
worrydream.com
It's too a comprehensive and far reaching essay for me to comment on in general, but I have a few random thoughts to share:
Right at the first example what immediately came to mind is simply having a better API. It's a boring but effective solution to say fill(color(r,g,b)). It also teaches data abstraction which is a common and powerful concept in programming (and I think it was introduced in an early chapter in SICP as well).
Secondly I think there are not enough good tools that empower non-programmers (not full-time) to program. Programming literacy (to some degree) should be more widespread and I agree with the notion that it is a way of thinking rather than just mechanical.
For example Excel is a tool that has managed to democratize programming to a high degree. When I teach designers to code websites, there are some who have had some experience with Excel, and they typically have less of a problem to understand some of the programming basics.
On the other hand Excel is also terrible, because it hides relations behind cells. The broader concept of this is also criticized in this essay.
In essence we need to find useful abstraction layers between what is main stream programming and main stream GUIs. I know many are actually doing that with varying degrees of success. But I think we need to be much more playful and drawing from history and science rather than thinking in terms of products (to sell) if we want to reach the stated goals.
As a non programmer with a PhD its a waste of my time, memory and energy that could otherwise be spent on my own domain. Its much simpler to have a 10 minute chat with a professional coder to get what I need.
Similar to the waste of time and skill development required to explain complex domain knowledge to the public. Talking instead to a professional writer makes my life much easier. I dont want to think about what tools the accountant, coder and writer use.
Personally, I like to code, I like to draw, I enjoy maths, music and many other things. All of those skills actually augment each other: geometry aids art, art aids programming and so forth.
I don’t agree with Bret Victor though I think design and algorithms should actually be explored with pen and paper and through other means. And I think the current way of doing things is okay like in REPLs but understanding the design and ideas outside of the computer is crucial.
You’ve made a choice within your time management framework to not take on the challenge of writing software. Rather than ponder the situation if it weren’t the challenge it is today for you to accomplish what you need with a computer, you declare the mere thought of that itself to be nonsense. That is nonsensical and, frankly, quite odd coming from a researcher.
We can do all of those things on our own to a reasonable degree as it gives us a degree of autonomy that we wouldn't have otherwise. That's the basic level. But perhaps more importantly it has spiritual impact as it enables different perspectives and types of thinking and doing.
I hope it's rewarding for him and his team, but I do hope he comes out EVENTUALLY and does talks and articles again!
[1]: https://www.google.com/url?sa=t&source=web&rct=j&url=https:/...
If there's something else out there in common use, I would love to know!
(not something niche like Lisp Machines or SmallTalk systems)
I think, though, even though I agree broadly with what he has to say on visual programming and gaining an intuitive understanding of what programmes do, I feel like the emphasis he puts onto areas he feels are weaknesses are not the areas that I feel are the areas that are most in need of tooling.
Let me explain.
Victor puts a lot of emphasis on real-time visualisation of outputs, dedicating a lot of time in his talks [1] to drawing a tree and showing how visually representing how the code is drawing onto the canvas allows for greater exploration of ideas and possibilities, whilst creating a greater mental link between code and screen.
I agree that having this link is useful, but I think what it disregards is the amount of effort that it takes to get to a situation where you have an interactive real-time IDE for the purposes of drawing a tree. True, there is a deeper point he is trying to make about making ideas more visual, but the examples he uses and the aspects of modern computing that he criticises doesn't generalise well without a lot of interpretation.
He says in the closing paragraph of the featured article that these "are not training wheels" and that this is how all programming should be, but I think it would actually only be helpful in a subset of contexts, and commercially viable to invest in the tooling required in only a very small subset of cases.
I feel like a more applicable use of this IS training wheels - interactive explainables that can bring a topic or a concept to life which can then be applied to a number of different contexts that will then not need specialist software or tooling to facilitate. Examples would be Stephen Wittins [2], Betterexplained [3], Red Blob Games [4] or Nicky Case [5]
[0] http://worrydream.com/LadderOfAbstraction/
[1] https://vimeo.com/71278954
[2] https://acko.net/blog/how-to-fold-a-julia-fractal/
[3] https://betterexplained.com/articles/intuitive-convolution/
[4] https://www.redblobgames.com/pathfinding/a-star/introduction...
I agree with your view, but one of the reasons for this is that there is still a lot to ask from the GUI frameworks in most languages (especially languages like C++ and Rust). However, I still believe that this can change.
Raph Levien is driving some pretty targeted work on pushing the state of GUI frameworks for Rust [0].
In C++ Dear ImGui is heavily used by the game development community [1]. My experience is that it is really fast to get a visualization for most projects going in very little time using this framework. See the gallery threads [2] for examples. This project also gets better every month.
[0]: https://raphlinus.github.io/rust/druid/2020/09/28/rust-2021....
Thanks for this, I will bookmark it and read it in more detail.
However thanks to Borland mismanagement only old timers or devs working at enterprises are fully aware of its existence.
He does talk about real-time visualization of outputs. IDEs for building trees is definitely not where we want to go.
However, there's an aspect in there that I'm utterly convinced about: direct manipulation of program objects! The ability to grab hold of program objects, tweak and move them and see the response, almost like you had some cord or lever in hand that connects to the program, feels amazing. To me, it's the most amazing aspect of Sutherland's super early work [2]. Hancock's dissertation also deals with some of these things [3].
As you observed, we struggle with generalizing such direct manipulation. Especially the composition and abstraction of such components. That's the difference between a IDE to draw trees and a magic medium between thought and computing. Will we some day have the latter? I do not know.
1: https://kronoslang.io/ (It's all written by yours truly, including the website, WASM jit compiler and frontend, so please be gentle :)
2: https://blogs.commons.georgetown.edu/cctp-797-fall2013/archi...
unfortunately, i wasnt able to get any audio output on my ipad....
I feel like a more applicable use of this IS training wheels - interactive explainables that can bring a topic or a concept to life which can then be applied to a number of different contexts that will then not need specialist software or tooling to facilitate.
this is probably arguing analogies, but i think its worth delving a bit more on the training wheels analogythe reason i think so is because with training wheels they seem like a shortcut/helpful but actually they actively harm and mislead about how to ride (leaning vs turning) and you become dependent on them and cant really function without them, but if you start out with the bicycle low enough where kids (or even adults) feet can tough the ground easily, they will just naturally put their feet to the ground when they loose balance and (quite quickly) learn to balance and ride much faster than if they ever used training wheels [0]
my claim is that we should help people to program, but not with training wheels but in a way that naturally occurs from using the tool (it goes without saying thst this is _very_ hard to implement)
[0] https://kidsrideshotgun.com/blogs/news/stabilisers-suck-why-...
I loathe teaching of programming through math and trig. I feel using math and trig to teach programming is a bigger barrier than anything else.
I observe that this style of programming only ever seems to be used for geometric programming of very visual things, or sometimes audio processing pipelines. I'm becoming suspicious that it may not be good for much of anything else. I'd be interested in seeing a mockup of how to use this technique for a JSON parser or a web handler or something and obtain any utility vs. what we already do.
I don't deny that it may be useful in a certain domain or potentially useful as an early teaching tool, but I remain highly skeptical that the promises/claims/demands that it be used for general-purpose programming is possible or a good idea, and the more I see the same examples over and over the deeper my skepticism becomes, no matter how slick the presentation.