I was greatly inspired by his work. After getting enough skills, I even built my own IDE with live coding and time traveling.
Its practical use is questionable, and it seems like nobody is really interested in such tools.
The future we have yet to achieve as we kept ourselves too busy doing UNIX clones.
While the ecosystem got a few good ideas for software development, even the authors eventually moved on to creating other OS and programming languages designs, some of which closer to those ideas like Inferno and Limbo, or ACME in Plan 9.
The big failure is that we stick with languages designed for computers and not people.
A C (or Rust) kernel is a heroic effort that takes man-years to complete. A Lisp one is an end of semester project that everyone builds for their make belief machine (also implemented in Lisp).
A toy C kernel is also an end of semester project.
What makes real kernels take man years to complete is the hardware support, the majority of Linux source code is drivers - the endless tables of hardware register definitions, opcodes and state machine handling.
It is unfortunate that this field underestimates the importance of the "people" part in favor of the "computer" part. There's definitely a balance to be stricken. I do believe that languages that are designed for computers have done a pretty decent job at adapting features that are geared more towards the "people" part of the equation. Unfortunately, programmers are very tribal and are very eager to toss the wine out with the cork when it comes to ideas that may help but they've misapplied.
Considering how much of modern software is written in JavaScript and python, I have a hard time seeing how lisp overhead would pose much of a problem. Erlang is good enough for telecom equipment for 30 years ago, so that also gives us a data point.
If entertain the idea that the Von Neuman architecture may be a local maxima, then we can do even better; lisp machines had specialized instructions for lisp which allowed it to run at competitive performance to a normal programming language.
The issue doesn't seem to be performance; it seems to still come down to being too eccentric for a lot of use-cases, and difficult to many humans to grasp.
>The issue doesn't seem to be performance; it seems to still come down to being too eccentric for a lot of use-cases, and difficult to many humans to grasp.
Lisp is not too difficult to grasp, it's that everyone suffers from infix operator brain damage inflicted in childhood. We are in the same place Europe was in 1300. Arabic numerals are here and clearly superior.
But how do we know we can trust them? After all DCCCLXXIX is so much clearer than 879 [0].
Once everyone who is wedded to infix notation is dead our great grand children will wonder what made so many people wase so much time implementing towers of abstraction to accept and render a notation that only made sense for quill and parchment.
It's not about prefix notation, it's that the fully uniform syntax has legitimate ergonomic problems for editing, human reading, and static analysis. Sexprs are better for computers than for humans in a lot of ways.
This part is interesting with regarding to LLMs: https://youtu.be/8pTEmbeENF4?t=817. He presents as if it were the year 1973, pokes fun at APIs (think HTTP), then says that computers in the future will figure out by themselves how to talk to each other. The opposite had become true when the presentation was actually done, but now the situation is turning.
I love Bret Victor and believe he has some very important things to say about design (UI design, language design and general design) but a lot of his concepts don't scale or abstract as well as he seems to be implying (ironic because he has a full essay on "The Ladder of Abstraction" [0]).
He makes some keen observations about how tooling in certain areas (especially front end design) is geared towards programmers rather than visual GUI tools, and tries to relate that back to a more general point about getting intuition for code, but I think this is only really applicable when there is a visual metaphor for the concept that there is an intuition to be gotten about.
To that end, rather than "programming not having progressed", a better realisation of his goals would be better documentation, interactive explainers, more tooling for editing/developing/profiling for whatever use case you need it for and not, as he would be implying, that all languages are naively missing out on the obvious future of all programming (which I don't think is an unfair inference from the featured video where he's presenting all programming like it's still the 1970s).
He does put his money where his mouth is, creating interactive essays and explainers that put his preaching into practice [1] which again are very good for those specific concepts but don't abstract to all education.
Similarly he has Dynamicland [2] which aims to be an educational hacker space type place to explore other means of programming, input etc. It's a _fascinating_ experiment and there are plenty of interesting takeaways, but it still doesn't convince me that the concepts he's espousing are the future of programming. A much better way to teach kids how computers work and how to instruct them? Sure. Am I going to be writing apps using bits of paper in 2050? Probably not.
An interesting point of comparison would be the Ken Iverson "notation as a tool of thought" which also tries to tackle the notion of programming being cumbersome and unintuitive, but comes at it very much from the mathematical, problem solving angle rather than the visual design angle. [3]
Ideas that scale don't scale until they do. The Macintosh didn't come out until people had been using WIMP GUIs for 10 years. People tried to build flying machines for centuries before the Wright Brothers figured out how to control one.
The solution to seeing more Bret Victor-ish tooling is for people to rediscover how to build the kind of apps that were commonplace on the desktop but which have become a very rare art in the cloud era.
Direct manipulation of objects in a shared workspace, instant undo/redo, trivial batch editing, easy duplication and backup, ... all things you can't do with your average SaaS and which most developers would revolt for if they'd had to do their own work without them.
Probably my favourite tech talk of all time. I did at least read the actor model paper! (though the 1973 one doesn't say much, you want the one with Baker, "Laws for Communicating Sequential Processes".
I still don't know what he means about not liking APIs though. "Communicating with Aliens", what insight am I missing?
When two humans want to talk but don't speak a shared language, if they spend enough time together, they will figure out how to communicate eventually.
But when two computers want to talk to each other and don't speak a "shared language" (aka, the client specifically must conform to the server's "language"—it's very one-sided in that sense) then no amount of time will allow them to learn one another's rules or settle on a shared communication contact without a human programmer getting involved.
My unpopular opinion is if we had just done a lot of the stuff Bret has been talking about for 10 years -- investing in better developer tooling -- we could have realized productivity gains better than what AI provides without having to spin up massive data centers. Unfortunately "dev tools" don't get funding today unless they're "AI dev tools".
I was greatly inspired by his work. After getting enough skills, I even built my own IDE with live coding and time traveling. Its practical use is questionable, and it seems like nobody is really interested in such tools.
Playground: https://anykey111.github.io
Images: https://github.com/anykey111/xehw
This is excellent: thank you for pursuing these wonderful ideas.
The future we have yet to achieve as we kept ourselves too busy doing UNIX clones.
While the ecosystem got a few good ideas for software development, even the authors eventually moved on to creating other OS and programming languages designs, some of which closer to those ideas like Inferno and Limbo, or ACME in Plan 9.
Seems to me the big failure was sticking with the Von Neuman architecture. Perhaps that was a forcing function towards where we’ve ended up.
The big failure is that we stick with languages designed for computers and not people.
A C (or Rust) kernel is a heroic effort that takes man-years to complete. A Lisp one is an end of semester project that everyone builds for their make belief machine (also implemented in Lisp).
A toy C kernel is also an end of semester project.
What makes real kernels take man years to complete is the hardware support, the majority of Linux source code is drivers - the endless tables of hardware register definitions, opcodes and state machine handling.
It is unfortunate that this field underestimates the importance of the "people" part in favor of the "computer" part. There's definitely a balance to be stricken. I do believe that languages that are designed for computers have done a pretty decent job at adapting features that are geared more towards the "people" part of the equation. Unfortunately, programmers are very tribal and are very eager to toss the wine out with the cork when it comes to ideas that may help but they've misapplied.
How is Lisp performance these days? It was around in the 70’s, right? So I guess the overhead couldn’t be too bad!
Considering how much of modern software is written in JavaScript and python, I have a hard time seeing how lisp overhead would pose much of a problem. Erlang is good enough for telecom equipment for 30 years ago, so that also gives us a data point.
If entertain the idea that the Von Neuman architecture may be a local maxima, then we can do even better; lisp machines had specialized instructions for lisp which allowed it to run at competitive performance to a normal programming language.
The issue doesn't seem to be performance; it seems to still come down to being too eccentric for a lot of use-cases, and difficult to many humans to grasp.
- https://en.wikipedia.org/wiki/Erlang_(programming_language)
- https://en.wikipedia.org/wiki/Lisp_machine
>The issue doesn't seem to be performance; it seems to still come down to being too eccentric for a lot of use-cases, and difficult to many humans to grasp.
Lisp is not too difficult to grasp, it's that everyone suffers from infix operator brain damage inflicted in childhood. We are in the same place Europe was in 1300. Arabic numerals are here and clearly superior.
But how do we know we can trust them? After all DCCCLXXIX is so much clearer than 879 [0].
Once everyone who is wedded to infix notation is dead our great grand children will wonder what made so many people wase so much time implementing towers of abstraction to accept and render a notation that only made sense for quill and parchment.
[0] https://lispcookbook.github.io/cl-cookbook/numbers.html#work...
It's not about prefix notation, it's that the fully uniform syntax has legitimate ergonomic problems for editing, human reading, and static analysis. Sexprs are better for computers than for humans in a lot of ways.
This part is interesting with regarding to LLMs: https://youtu.be/8pTEmbeENF4?t=817. He presents as if it were the year 1973, pokes fun at APIs (think HTTP), then says that computers in the future will figure out by themselves how to talk to each other. The opposite had become true when the presentation was actually done, but now the situation is turning.
I wonder what LLMs say about us when they talk to each other.
"They're made out of meat" maybe. https://www.mit.edu/people/dpolicar/writing/prose/text/think...
> "what LLMs say about us when they talk to each other"
That's like asking what does a kaleidoscope paint on its day off.
does that mean things like graphql will make a comeback in the A.I world ?
since with graphql - an agent / a.i can probe - gradually to what information another program can give vs a finite set of interfaces in REST ?
had the privilege to be there in person. was magical live
I love Bret Victor and believe he has some very important things to say about design (UI design, language design and general design) but a lot of his concepts don't scale or abstract as well as he seems to be implying (ironic because he has a full essay on "The Ladder of Abstraction" [0]).
He makes some keen observations about how tooling in certain areas (especially front end design) is geared towards programmers rather than visual GUI tools, and tries to relate that back to a more general point about getting intuition for code, but I think this is only really applicable when there is a visual metaphor for the concept that there is an intuition to be gotten about.
To that end, rather than "programming not having progressed", a better realisation of his goals would be better documentation, interactive explainers, more tooling for editing/developing/profiling for whatever use case you need it for and not, as he would be implying, that all languages are naively missing out on the obvious future of all programming (which I don't think is an unfair inference from the featured video where he's presenting all programming like it's still the 1970s).
He does put his money where his mouth is, creating interactive essays and explainers that put his preaching into practice [1] which again are very good for those specific concepts but don't abstract to all education.
Similarly he has Dynamicland [2] which aims to be an educational hacker space type place to explore other means of programming, input etc. It's a _fascinating_ experiment and there are plenty of interesting takeaways, but it still doesn't convince me that the concepts he's espousing are the future of programming. A much better way to teach kids how computers work and how to instruct them? Sure. Am I going to be writing apps using bits of paper in 2050? Probably not.
An interesting point of comparison would be the Ken Iverson "notation as a tool of thought" which also tries to tackle the notion of programming being cumbersome and unintuitive, but comes at it very much from the mathematical, problem solving angle rather than the visual design angle. [3]
[0] https://worrydream.com/LadderOfAbstraction/
[1] https://worrydream.com/KillMath/
[2] https://dynamicland.org/
[3] https://www.jsoftware.com/papers/tot.htm
Ideas that scale don't scale until they do. The Macintosh didn't come out until people had been using WIMP GUIs for 10 years. People tried to build flying machines for centuries before the Wright Brothers figured out how to control one.
The solution to seeing more Bret Victor-ish tooling is for people to rediscover how to build the kind of apps that were commonplace on the desktop but which have become a very rare art in the cloud era.
Direct manipulation of objects in a shared workspace, instant undo/redo, trivial batch editing, easy duplication and backup, ... all things you can't do with your average SaaS and which most developers would revolt for if they'd had to do their own work without them.
The biggest wish I have is to one day meet maestro. Greatest living mind in my opinion.
Probably my favourite tech talk of all time. I did at least read the actor model paper! (though the 1973 one doesn't say much, you want the one with Baker, "Laws for Communicating Sequential Processes".
I still don't know what he means about not liking APIs though. "Communicating with Aliens", what insight am I missing?
When two humans want to talk but don't speak a shared language, if they spend enough time together, they will figure out how to communicate eventually.
But when two computers want to talk to each other and don't speak a "shared language" (aka, the client specifically must conform to the server's "language"—it's very one-sided in that sense) then no amount of time will allow them to learn one another's rules or settle on a shared communication contact without a human programmer getting involved.
I like this guy. His work! But it seems like everything he did is from 10+ years ago. Where is he now?!?!
He's around! You can see his current work at https://worrydream.com. He's mostly been working on Dynamicland (https://dynamicland.org). He'll also occasionally post on Bluesky (https://bsky.app/profile/worrydream.com)
Doing this kind of stuff,
https://www.youtube.com/watch?v=7wa3nm0qcfM
https://worrydream.com
My unpopular opinion is if we had just done a lot of the stuff Bret has been talking about for 10 years -- investing in better developer tooling -- we could have realized productivity gains better than what AI provides without having to spin up massive data centers. Unfortunately "dev tools" don't get funding today unless they're "AI dev tools".
Instead of this we got AI slop that is literally everywhere you look.