I don't think it will ever happen except for toy projects. If you're manipulating some small list of 10-20 objects and those object have some kind of useful visual representation then for some small use case you can possibly, maybe, design a system that could do what's shown in the demos. I'm skeptical that it scales to more complex problems with more complex data.
Bret Victor himself has made zero headway. And no, Dynamicland is not it. Dynamicland is still coded in text with no visual representation itself.
Other examples always show the simplest stuff. A flappy bird demo. A simple recursive tree. A few houses made of 2-3 rectangles and a triangle. Etc...
To be even more pessimistic, AFAICT, if you find a single example you'll find that even the creators of the example have abandoned it. They aren't using it in their own projects. They made it, made some simple demos, realized it didn't really fit anything except simple demos, and went back to coding in text.
I'm not trying to be dismissive. I'd love to be proven wrong. I too was inspired when I first read his articles. But, the more I thought about it the more futile it seemed. The stuff I work on has too many moving parts to display any kind of useful representation in a reasonable amount of time.
What I can imagine is better debuggers with plugins for visualizers and manipulators. C# shipped with its property control that you could point at a class and it would magically made it editable. You could then write a custom UI for any time and it would show up in the property control (for example a color editor). I'd like to see more of that in debuggers. Especially if one of the more popular languages made it a core feature of their most popular debugger so that it became common for library writers to include debug time visualizers
Even then though, it's not clear to me how often it would be useful.
The seminal "No silver bullet" paper states that there is no universal way representation for arbitrary programs. The alternative is making specialized tools for your usecase.
I think Tudor Girba has the most usable and real-world implementation of a Victor-like vision; moldable development in Pharo
The idea is that you adjust your development environment in real-time with default and custom widgets, tools and visualizations.
I've never really understood Victor's examples to be "examples of applications you can create if you follow my way of thinking", but more "hey, this is some cool stuff you can do with computers that you probably never even considered.".
It seems Victor's vision has a hard dependency on an environment that makes this kind of meta-manipulation very natural and easy. Basically it seems his vision is the UX extension of this lower-level DX vision:
Of course this kind of runtime freedom/power/access probably has a performance cost, aaand I have a hard time figuring out how it would work in a real-life setting.
So yeah, instead of this super-universal tinkerability what's really needed (at least in the short term) are better tools. A better strace/tcpdump, better frameworks (better batteries included in more places). More care for "post hoc" error investigation. (Yeah a 2000 line exception going back to EveFactory(AdamsRib) factory is great, but what was the incoming HTTP request? What was the value of the variables in the local scope? What was the git commit that produced this code? Etc.)
One big reason errors like that are usually unhelpful is for security. I would love it if my SQL errors printed the offending row out but that row also has PII so it can't be saved to a log. They'd need to be encrypted or stored in the database itself somehow to not ruin 10 layers of PII protections.
Not everyone has to work with PII but the general rule to not log your data to generic log or stack traces still applies to everyone. On top of that tools like languages or frameworks don't know what the data they're working with does so they default to the secure option of not writing data out on errors. If you know the data isn't and it's a common spot for errors you can have the data logged by tossing a try catch statement around the pain point in your code.
If you write an application that makes money in a manner that involves transactions from people somehow, it will be the case for you. That is in fact the majority of developers.
I can't imagine directly translating any project I've worked on to a non-code representation. But, that's only because they've been developed not only in code, but for code. I can totally see a post-code development experience that mirrors how programs work much better than a big string.
>> I can totally see a post-code development experience that mirrors how programs work
I can't, because how programs work is a projection of how computers work and how computers work is by doing math. The whole reason why we have been clawing our way up the ladder of abstraction for so many decades is that it's really hard to express "Which aircrew do I need in Seattle tomorrow morning" in terms of adding 1 to a value in a register. We invented these cool little machines that do math really fast and then made them so cheap and affordable that of course we started simulating everything that could be represented mathematically. I've been programming since 1975 and when I think back I can recall dozens of these conversations over the years. How do we free programming from code? Personally, I don't think we can. The code is all that programming and computing is. Just because we have managed to do so many things with our ultrafast calculators doesn't mean they can somehow be elevated beyond what they fundamentally are. It's like we want to somehow lift them up to be like us, and on just a little reflection that seems absurd doesn't it? You might as well expect it from a toaster or a crescent wrench.
Hm, couldn't you make the same argument about punch cards? The abstractions you talk about translate to different mediums differently. I think text/code/string is a very universal and low tech medium, but I don't think there's anything about it that would make it ideal for working with those abstractions. And, let's not forget that there's a myriad of different abstractions, which to me suggests that there might be as many different ideal mediums.
Given that there isn't some superior visual representation of math, I think it is reasonable to say there won't be one for code - at least for a while.
There are superior visual representations of math as soon as you add specificity such that you can measure the difference between representations in terms of their impact or other property. Equation coloring according to semantics stands out as an example of this. Interestingly, this example already has wider adoption in code than it does in math. As someone who has tried to format a latex paper to have coloring and has not had to do the same for colored code, I can understand why. Yet if you look at KhanAcademy as an example, the technology lifts much of the burden from doing the coloring, so they do the coloring, because it helps to highlight the key ideas.
It can be a fun exercise and illuminating to go over equations you've written down and try to translate them to colored variants. The classification task forces your mind to more deeply engage with the equation and can improve understanding.
I don't know man. You could say that engineering and architecture is just applied math, but blueprints are not math notation (and neither is code, by the way).
If we had some good way to work with graphs, code could easily be represented as such. I mean still having code inside graph nodes, but you could switch views between program flow, data flow, data structures dependency etc.
It could already be made better to what we have, but there's tons of little improvements on text already and editors are very optimized to how we work currently, so it seems like it would take enormous effort to match that.
But for example for web development, seeing visual changes live is already a norm and it was not popular back when he was doing his presentations (well meta refresh tag in the 90s, good times), plus tests runinng in the loop only on things that changed also seem like a step in a good direction.
Most of all, all languages are optimized for text. Visual representation seem to have an inherent problem that it's most intuitive to touch it and that won't get anywhere close to efficiency of a keyboard. I don't think it's not possible to solve though. We just haven't yet. We've came a long way from switches and perforated cards and there is no reason to think we will stop here.
As much as it pains me to say, it's possible that much of code will be dictated to "AI" in the future and then graph representations of what's going on start to make much more sense.
We found that the key is to distinguish between writing and reading. Writing is tied to the computation and there we want as much expression as possible, and text is often hard to replace. But whatever we write, it's just data, and data can be read in many ways, depending on the question we have about it. That is the basis of what we call, moldable development. Not only are we using views extensively (in the range of thousands per system), we find it provides a significant competitive advantage, too.
> I'm not trying to be dismissive. I'd love to be proven wrong.
I don't see a world where simulating and visualizing n-steps can ever be as performant as just having one step. Even deploying immutable structures will lead to performance penalties.
Only place it is usable is in small/toy examples where computing power to n-steps can subjectively be as fast as 1 step.
There's probably an argument for having the compiled/optimized and deployed version be the low-dimensional projection of the high-dimensional simulation, and when an error happens the developer should be able to restore (at least partially) that state in the simulation, which could help to understand the problem.
I think a Brett Victor like dev tool would be a good companion to pure functional languages, and help improve their standing.
Shared state code does not respond well to running functions in a tight loop while changing the code. Mutations accumulate and the results become meaningless very quickly.
There have been some minor attempts that may even predate Brett's work, especially around trying to run unit tests on every edit. Those tend to be slow so some people have done work on using code coverage tools to figure out which code changes affect which tests, but I suspect they ran into problems since I haven't heard about any of those in some time now.
Bret Victor himself has made zero headway. And no, Dynamicland is not it. Dynamicland is still coded in text with no visual representation itself.
Other examples always show the simplest stuff. A flappy bird demo. A simple recursive tree. A few houses made of 2-3 rectangles and a triangle. Etc...
To be even more pessimistic, AFAICT, if you find a single example you'll find that even the creators of the example have abandoned it. They aren't using it in their own projects. They made it, made some simple demos, realized it didn't really fit anything except simple demos, and went back to coding in text.
I'm not trying to be dismissive. I'd love to be proven wrong. I too was inspired when I first read his articles. But, the more I thought about it the more futile it seemed. The stuff I work on has too many moving parts to display any kind of useful representation in a reasonable amount of time.
What I can imagine is better debuggers with plugins for visualizers and manipulators. C# shipped with its property control that you could point at a class and it would magically made it editable. You could then write a custom UI for any time and it would show up in the property control (for example a color editor). I'd like to see more of that in debuggers. Especially if one of the more popular languages made it a core feature of their most popular debugger so that it became common for library writers to include debug time visualizers
Even then though, it's not clear to me how often it would be useful.