I am a massive fan of Bret Victor and his talks. 'Up and down the ladder of abstraction' [0] was eye opening for me, and has informed my pedagogical style ever since.
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]
I think Bret Victor is right. We need more of those tools, and the future of programming will include them. No, his demos don't seem to generalize. Yes, it looks hard to arrive at that goal. But we absolutely should work towards it!
> 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.
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.
Ah, this is interesting. It seems like the rust community are doing similar things with updating UI paradigms as they are with updating CLI conventions!
Thanks for this, I will bookmark it and read it in more detail.
I looked it up. The main reason that I'm excluded from the audience is not due to Borland but rather that I don't have Microsoft Windows as my operating system.
Bret Victor was definitely an influence when I sought to combine the visual graph-patching paradigm (for audio programming) with a repl-like experience on a more-powerful-than usual functional backend [1].
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 :)
I agree. I've put a lot of work into building these types of visualizations (Red Blob Games) and I've been able to come up with useful visualizations for only some of the problems I work on, and for a small subset of the data structures. For example, with my A* pages I purposefully chose graphs that are planar and have at most a few hundred nodes, because that works well for the visualization. But if you were to ask me to make my A* visualizations work for any graph, including non-planar or millions of nodes, I wouldn't know how. I know some people want general purpose tools "for practioners" but I don't know how to get there, and years of making these visualizations has not gotten me any closer! :-( Maybe someone will come along and figure out a generalization, but I don't think it will be me. I think the "trailing wheels" style pages are a subset that clearly benefits from visualizations, so I'll focus on those.
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 analogy
the 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)
It should all be taught together. Trigonometry is the easiest thing in the world, it just feels complicated because of the way you learnt it first. What is complicated about going around a circle? Is it really more complicated than writing programs?
I have a blog post in the $SOMEDAY pile where I warn about technologies that keep using the same example over and over again. If something is broadly applicable, people should be able to come up with independent examples of how it's useful. If the same example keeps coming up over and over, one should become suspicious that it only works on that example.
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.
The classic "hello world" for visual programming languages tends to be a Fahrenheit to Celsius converter. Not only is this example a very simple calculation, it happens to be a reversible, total function, which can often (unintentionally?) imply a degree of flexibility and interactivity which does not generalize to stateful or non-reversible programs.
Sometimes I forget that there is a difference between a programmer and a software engineer. I actually think that mathematics should be emphasized more where programming is concerned, practicing applicable maths improves on your ability to be logical and therefore a complementary skill for a programmer.
I love Bret Victor's essays and talks, they are truly inspiring, including this one.
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.
Excel can be beautiful and pain free and I would still hand over my taxes to an accountant. Its all nonsense that everyone needs to code or enjoy it. And that the tools are the issue.
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.
This makes sense to be domain specific. But it’s all in the realm of what interests people.
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.
This is a lot like saying “I choose not to drive, but it’s nonsense that people think cars are the issue.”
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.
I experience these things differently. I'm not a writer but I'm still able to read and write. I don't have a writer (scribe) next to me that translates things I think into this little text box, whenever I need it. Similarly I don't call an accountant to plan my holiday budget.
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 love this essay so much. So much that I tried to implement all of the demos in JavaScript, which you can try in interactive form here: https://www.newline.co/choc/
such great points! I've always found the tooling lacking for teaching beginners programming, sure there are good languages, but as he points out the environment is also vital. I find it very hard to introduce programming to my social science friends (who would actually benefit greatly from knowing how to manipulate data), most of those who have extra time go to learn excel or spss.
Love this! I love tutorials which fulfill these requirements like [1]. I'm making my language fngi using these principles as much as possible as well, and my whole civboot project is in pursuit of exactly this ideal.
30 comments
[ 2.9 ms ] story [ 84.2 ms ] threadI 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...
[5] http://ncase.me/trust
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....
[1]: https://github.com/ocornut/imgui
[2]: https://github.com/ocornut/imgui/issues/3793
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...
3: https://dspace.mit.edu/handle/1721.1/61549
unfortunately, i wasnt able to get any audio output on my ipad....
the 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.
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)