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....
However thanks to Borland mismanagement only old timers or devs working at enterprises are fully aware of its existence.
Thanks for this, I will bookmark it and read it in more detail.
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.
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 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