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?
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.
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.
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]
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.
I've come around to feeling that if I'm going to make an experimental development tool, I need to make it in service of building something specific. Maybe something playful... if I'm building something "important" then it can put unwanted conservative pressure on the tool. But something, and if I do that then at least I have something interesting regardless of the fate of the development tool. Because yeah, there's a good chance no one else is going to be excited about the tool, so I have to build for my own sense of excitement, be my own most enthusiastic user.
I've dabbled a lot in this space as well- built an experimental language that natively supported live-coding, after building live coding capabilities through LSP for love2d (Lua) to get a feel for the feature set I wanted etc
One major issue with vibe coding is parsing divergent code paths, when different prompts create different solutions and architectural compromises.
Parsing that mess is a major headache, but with live coding and time travel,I bet those tools would make managing divergent code branches easier and really take advantage of branching repositories with multiple agents all working in tandem.
There was recently an HN post with a video of someone using a pretty cool environment that supported that kind of live-coding for creating an electronic music track -- it seemed very appropriate there, and I would guess likely to be popular.
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".
He was already inspirational before that; check out Magic Ink. Because Apple won't let him share his work for that period, he isn't known for it; it's sort of like a gap in the geological record.
The non-linear code structure (including visually) is something I've been thinking about for a long time and arrived at very naturally. I'm the "spread all the papers on the table to take in every interaction all at once" type of person, and so often I imagined a code editor that would allow me to just "cut" a piece of code and move it to the side. Separating stuff into files is kinda this, but it's not visual and just creates a lot of mess when I try to separate out small functions that are not reusable somewhere else. I don't even need the underlying non-linearity — just let me move the papers around on my code desk!
css is primed for this since you can write your rules in such a way that rule order doesn't matter, which means you really don't have to think about where your code it
in my dream world, i have very smart search (probably llms will help), i look at just the minimal amount of code (ideally on a canvas), edit it and remove it from my context
i don't care where or how the code is stored, let the editor figure it out and just give me really good search and debuggers
Emacs has first party support for these approach. Buffers are separate from the windows (aka panes) where they are displayed. And the latter are arranged in a tiling manner in frames (aka windows). The buffer themselves doesn't need to be tied to a file and you can use concept like narrowing to restrict the viewable part. In elisp, you will fine often the form feed ascii code (^L) which allows to define sections which can be restricted with the `narrow-to-page` command.
On my work laptop I usually have many emacs frames. One displaying a `term-mode` (terminal) buffer, another usually displaying some `compilation-mode` buffer (tests, lint) or `grep` results, two as active workspaces as I'm often dealing with different modules (one maybe the api and the other a UI component). I create other frames as I need them (like exploring another project or doing some git-fu with magit).
My favorite Bret Victor talk ever is „Drawing dynamic visualizations“ [1] that made me try to reverse engineer [2] the demonstrated tool that he sadly never released.
Call me grumpy and sleep deprived, but every year I look at this talk again, and every year I wonder... "now, what" ? What am I supposed to do, as a programmer, to change this sad state of things ?
Start the n-th "visual" or "image based" programming language (hoping to at least, make _different_ mistakes than the ones that doomed smalltalk and all other 'assemble boxes to make a program' things ?)
Start an OS, hoping to be able to get an "hello world" in qemu in a year or two of programming in my sparse free time ?
Ask an LLM to write all that would be so cool ?
Become a millionaire selling supplements, and fund a group of smart programmers to do it for me ?
Honest question. Once you've seen this "classic" talk ("classic", in the sense that it is now old enough to work in some countries), what did you start doing ? What did you stop doing ? What did you change ?
> Start the n-th "visual" or "image based" programming language (hoping to at least, make _different_ mistakes than the ones that doomed smalltalk and all other 'assemble boxes to make a program' things ?)
Unironically yes, this. Progress happens in this field one dead language at a time; people try a thing and make mistakes continually, so that other people can try again and make other different mistakes. Eventually, something good is found and they integrate it into C++.
But no one is going to find these ideas unless people keep trying and failing. This is a community effort, you can only do your part. And like the rest of us you will likely fail and never be thanked for your efforts -- except by the next poor sap who takes up the good fight, sees your failures, and deftly avoids all your mistakes. But the plus side is if you succeed... you also won't be thanked or rewarded so scratch all that you probably shouldn't bother if you respect yourself.
Bret Victor speaks so idealistically it's difficult to disagree with his vision, but in reality he's a radicalized, scrappy cult leader. His ideas sound super cool but they're impractical - that's why nobody can make them work. We're delusional for worshiping him.
I think you're 100% about this, but we have to define "impractical". If we take it to mean "the things he shows will never be how we develop software in the future" I agree, to the extent that what he shows is his vision of working, and it doesn't seem he likes to do the kind of work people get paid wages/salaries to do.
The thing though about "nobody can make them work" is that there's really not funding to do so, because corporations don't really see a payout on the other side. So is it "impractical" or just "of no interest to corporations"? Because with AI, we see what happens when corporations think there is a giant payday on the other side. Somehow "unlock our human potential through better ergonomic design of technology" doesn't open wallets but "replace your entire dev team with a robot" causes an endless tsunami of cash. One is "impractical" and the other is "our new reality". I'd say as far as feasibility goes, the former or more practical than the latter, but as far as fundability goes, the latter is more practical than the former.
If I'm going to take away anything from what Victor has said over the years, it's what the article starts off saying, that his...
vision is rooted in the idea that the computer revolution of the ’70s and early ’80s was cut short, primarily by premature commercialization. While the computer as a medium was still unfolding its potential, and way before it could do so entirely, it was solidified into commercial products, thereby stifling its free growth. Once corporations had built their businesses on the ideas developed so far, they were only interested in incremental change that could easily be integrated into the products, rather than revolutionary new ideas.
I think that's 100% true by construction, and we can see that in the languages that have risen to the top, which have all been molded for use by corporations for corporate purposes. In this case "impracticable" means "not suitable for corporate use", and it's simply not true that programming languages are only practical if corporations can use them profitably, because there are so many other purposes for programming languages.
And so I think that's the reason for the culty vibes, because without htem he wouldn't be able to do what he does. If he sold it in more grounded terms -- fundamental HCI research -- he can't get funded. So he talks in terms of human revolutions and then he gets some true believers and effective altruism people to open their wallets, get some of those SV devs to spread some of their big tech money around to causes they care about, because they're the ones who have to ultimately deal with the bad programming UX we've built for ourselves.
And that's what Bret Victor is ultimately advocating: better UX for devs, mostly through observability. That's not so radical or impractical. His work has to be because otherwise he doesn't have a job... moreover, he'd have to get a job. But that doesn't mean he doesn't have a good point.
39 comments
[ 847 ms ] story [ 1757 ms ] threadI still don't know what he means about not liking APIs though. "Communicating with Aliens", what insight am I missing?
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.
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
Playground: https://anykey111.github.io
Images: https://github.com/anykey111/xehw
https://m.youtube.com/watch?v=HnZipJOan54&t=1249s
It was a language designed alongside its IDE (which was a fairly rudimentary web app).
Love2D Demo https://github.com/jasonjmcghee/livelove
Language Demo https://gist.github.com/jasonjmcghee/09b274bf2211845c551d435...
One major issue with vibe coding is parsing divergent code paths, when different prompts create different solutions and architectural compromises.
Parsing that mess is a major headache, but with live coding and time travel,I bet those tools would make managing divergent code branches easier and really take advantage of branching repositories with multiple agents all working in tandem.
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 ?
Also, Erlang (non-explicitly) mentioned!
Also, I'm super glad we never got those "APIs" he was talking about. What a horrid thought.
"...Victor worked as a human interface inventor at Apple Inc. from 2007 until 2011." [1]
[1] https://en.wikipedia.org/wiki/Bret_Victor
• Inventing on Principle (https://vimeo.com/906418692) / (https://news.ycombinator.com/item?id=3591298)
• Up and Down the Ladder of Abstraction (https://worrydream.com/LadderOfAbstraction/)
• Learnable Programming (https://worrydream.com/LearnableProgramming/) / (https://news.ycombinator.com/item?id=4577133)
• Media for Thinking the Unthinkable (https://worrydream.com/MediaForThinkingTheUnthinkable/)
Or you could just check his website: https://worrydream.com/
css is primed for this since you can write your rules in such a way that rule order doesn't matter, which means you really don't have to think about where your code it
in my dream world, i have very smart search (probably llms will help), i look at just the minimal amount of code (ideally on a canvas), edit it and remove it from my context
i don't care where or how the code is stored, let the editor figure it out and just give me really good search and debuggers
On my work laptop I usually have many emacs frames. One displaying a `term-mode` (terminal) buffer, another usually displaying some `compilation-mode` buffer (tests, lint) or `grep` results, two as active workspaces as I'm often dealing with different modules (one maybe the api and the other a UI component). I create other frames as I need them (like exploring another project or doing some git-fu with magit).
[1]: https://youtu.be/ef2jpjTEB5U?si=S7sYRIDJKbdiwYml
[2]: https://youtube.com/playlist?list=PLfGbKGqfmpEJofmpKra57N0FT...
Start the n-th "visual" or "image based" programming language (hoping to at least, make _different_ mistakes than the ones that doomed smalltalk and all other 'assemble boxes to make a program' things ?)
Start an OS, hoping to be able to get an "hello world" in qemu in a year or two of programming in my sparse free time ?
Ask an LLM to write all that would be so cool ?
Become a millionaire selling supplements, and fund a group of smart programmers to do it for me ?
Honest question. Once you've seen this "classic" talk ("classic", in the sense that it is now old enough to work in some countries), what did you start doing ? What did you stop doing ? What did you change ?
Unironically yes, this. Progress happens in this field one dead language at a time; people try a thing and make mistakes continually, so that other people can try again and make other different mistakes. Eventually, something good is found and they integrate it into C++.
But no one is going to find these ideas unless people keep trying and failing. This is a community effort, you can only do your part. And like the rest of us you will likely fail and never be thanked for your efforts -- except by the next poor sap who takes up the good fight, sees your failures, and deftly avoids all your mistakes. But the plus side is if you succeed... you also won't be thanked or rewarded so scratch all that you probably shouldn't bother if you respect yourself.
The Future of Programming (2013) - https://news.ycombinator.com/item?id=44746821 - July 2025 (10 comments)
Bret Victor – The Future of Programming (2013) [video] - https://news.ycombinator.com/item?id=43944225 - May 2025 (1 comment)
The Future of Programming (2013) - https://news.ycombinator.com/item?id=32912639 - Sept 2022 (1 comment)
The Future of Programming (2013) - https://news.ycombinator.com/item?id=15539766 - Oct 2017 (66 comments)
References for “The Future of Programming” - https://news.ycombinator.com/item?id=12051577 - July 2016 (26 comments)
Bret Victor The Future of Programming - https://news.ycombinator.com/item?id=8050549 - July 2014 (2 comments)
The Future of Programming - https://news.ycombinator.com/item?id=6129148 - July 2013 (341 comments)
https://christophlocher.com/notes/ethnographic-research-on-d...
The thing though about "nobody can make them work" is that there's really not funding to do so, because corporations don't really see a payout on the other side. So is it "impractical" or just "of no interest to corporations"? Because with AI, we see what happens when corporations think there is a giant payday on the other side. Somehow "unlock our human potential through better ergonomic design of technology" doesn't open wallets but "replace your entire dev team with a robot" causes an endless tsunami of cash. One is "impractical" and the other is "our new reality". I'd say as far as feasibility goes, the former or more practical than the latter, but as far as fundability goes, the latter is more practical than the former.
If I'm going to take away anything from what Victor has said over the years, it's what the article starts off saying, that his...
I think that's 100% true by construction, and we can see that in the languages that have risen to the top, which have all been molded for use by corporations for corporate purposes. In this case "impracticable" means "not suitable for corporate use", and it's simply not true that programming languages are only practical if corporations can use them profitably, because there are so many other purposes for programming languages.And so I think that's the reason for the culty vibes, because without htem he wouldn't be able to do what he does. If he sold it in more grounded terms -- fundamental HCI research -- he can't get funded. So he talks in terms of human revolutions and then he gets some true believers and effective altruism people to open their wallets, get some of those SV devs to spread some of their big tech money around to causes they care about, because they're the ones who have to ultimately deal with the bad programming UX we've built for ourselves.
And that's what Bret Victor is ultimately advocating: better UX for devs, mostly through observability. That's not so radical or impractical. His work has to be because otherwise he doesn't have a job... moreover, he'd have to get a job. But that doesn't mean he doesn't have a good point.