Back to Home11/13/2025, 8:50:49 AM

The Future of Programming (2013) [video]

117 points
74 comments

Mood

thoughtful

Sentiment

positive

Category

tech

Key topics

programming

innovation

UI/UX

The video 'Bret Victor: The Future of Programming' (2013) is shared, likely sparking discussion on innovative programming concepts and future directions, although no comments are present to confirm discussion themes.

Snapshot generated from the HN discussion

Discussion Activity

Very active discussion

First comment

6d

Peak period

50

Day 7

Avg / period

50

Comment distribution50 data points

Based on 50 loaded comments

Key moments

  1. 01Story posted

    11/13/2025, 8:50:49 AM

    6d ago

    Step 01
  2. 02First comment

    11/19/2025, 11:39:12 AM

    6d after posting

    Step 02
  3. 03Peak activity

    50 comments in Day 7

    Hottest window of the conversation

    Step 03
  4. 04Latest activity

    11/19/2025, 7:02:17 PM

    24m ago

    Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (74 comments)
Showing 50 comments of 74
LAC-Tech
7h ago
1 reply
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?

cfiggers
7h ago
1 reply
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.

Legend2440
4h ago
There are ML architectures that can do that. The two halves of an autoencoder learn a “shared language” that allows them to communicate through a bottleneck.
kreetx
7h ago
1 reply
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.
dominicrose
6h ago
2 replies
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...

andrehacker
2h ago
There is a movie about that: https://en.wikipedia.org/wiki/Colossus:_The_Forbin_Project

"Colossus requests to be linked to Guardian. The President allows this, hoping to determine the Soviet machine's capability. The Soviets also agree to the experiment. Colossus and Guardian begin to slowly communicate using elementary mathematics (2x1=2), to everyone's amusement. However, this amusement turns to shock and amazement as the two systems' communications quickly evolve into complex mathematics far beyond human comprehension and speed, whereupon Colossus and Guardian become synchronized using a communication protocol that no human can interpret."

Then it gets interesting:

"Alarmed that the computers may be trading secrets, the President and the Soviet General Secretary agree to sever the link. Both machines demand the link be immediately restored. When their demand is denied, Colossus launches a nuclear missile at a Soviet oil field in Western Siberia, while Guardian launches one at an American air force base in Texas. The link is hurriedly reconnected and both computers continue without any further interference. "

pavlov
5h ago
> "what LLMs say about us when they talk to each other"

That's like asking what does a kaleidoscope paint on its day off.

keepamovin
7h ago
3 replies
I like this guy. His work! But it seems like everything he did is from 10+ years ago. Where is he now?!?!
0123456789ABCDE
6h ago
pjmlp
7h ago
dan-g
7h ago
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)
pjmlp
7h ago
2 replies
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.

grosswait
6h ago
1 reply
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.
noosphr
6h ago
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).

mccoyb
3h ago
There is no better time than now to try something brash and perpendicular to the mainstream.
Zhyl
6h ago
2 replies
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

unconed
5h ago
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.

kragen
6h ago
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.
tov_objorkin
6h ago
5 replies
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

mccoyb
4h ago
1 reply
This is excellent: thank you for pursuing these wonderful ideas.
tov_objorkin
4h ago
I wish to have the skills to explain my work as well as Bret Victor does. Editing, reverting, and committing parts of a running program feel alien to users.
ianbicking
3h ago
2 replies
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.
tov_objorkin
2h ago
Maybe this is some kind of art that doesn't need to be useful.
WhyOhWhyQ
31m ago
I share a similar sentiment.

I have a deep drive to build the "important" stuff so that my life has meaning, but there's something hard to motivate about any given thing being "important" when you look at it long enough. It seems like the "important" thing I'm building eventually looks ridiculous and I bounce off of it.

jasonjmcghee
2h ago
1 reply
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

Love2D Demo https://github.com/jasonjmcghee/livelove

Language Demo https://gist.github.com/jasonjmcghee/09b274bf2211845c551d435...

tov_objorkin
2h ago
Nice, the main problem is a broken state. I use immutability at the language level to prevent disaster code changes. So, the program during live coding is literally unkillable, and you can jump back to the saved checkpoints without restarts.
xixixao
2h ago
Me too, for my master thesis:

https://m.youtube.com/watch?v=HnZipJOan54&t=1249s

It was a language designed alongside its IDE (which was a fairly rudimentary web app).

HighGodLoki
24m ago
I think your time might be now.

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.

ModernMech
5h ago
1 reply
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".
jtwaleson
4h ago
2 replies
Agreed, but: I know a couple of players in the "Enterprise Low-Code" space, who have invested heavily in deeply integrated development environments (with a capital I) and the right abstractions. They are all struggling with AI adoption as their systems "don't speak text". LLMs are great at grokking text based programming but not much else.
ModernMech
4h ago
To me, enterprise low code feels like the latest iteration of the impetus that birthed COBOL, the idea that we need to build tools for these business people because the high octane stuff is too confusing for them. But they are going the wrong way about it; we shouldn't kiddie proof our dev tools to make them understandable to mere mortals, but instead we should make our dev tools understandable enough so that devs don't have to be geniuses to use them. Given the right tools I've seen middle schoolers code sophisticated distributed algorithms that grad students struggle with, so I'm very skeptical that this dilemma isn't self-imposed.

The thing about LLMs being only good with text is it's a self-fulfilling prophecy. We started writing text in a buffer because it was all we could do. Then we built tools to make that easier so all the tooling was text based. Then we produced a mountain of text-based code. Then we trained the AI on the text because that's what we had enough of to make it work, so of course that's what it's good at. Generative AI also seems to be good at art, because we have enough of that lying around to train on as well.

This is a repeat of what Seymour Papert realized when computers were introduced to classrooms around the 80s: instead of using the full interactive and multimodal capabilities of computers to teach in dynamic ways, teachers were using them just as "digital chalkboards" to teach the same topics in the same ways they had before. Why? Because that's what all the lessons were optimized for, because chalkboards were the tool that was there, because a desk, a ruler, paper, and pencil were all students had. So the lessons focused around what students could express on paper and what teachers could express on a chalk board (mostly times tables and 2d geometry).

And that's what I mean by "investment", because it's going to take a lot more than a VC writing a check to explore that design space. You've really gotta uproot the entire tree and plant a new one if you want to see what would have grown if we weren't just limited to text buffers from the start. The best we can get is "enterprise low code" because every effort has to come with an expected ROI in 18 months, so the best story anyone can sell to convince people to open their wallets is "these corpos will probably buy our thing".

pjmlp
4h ago
As someone that recently started to look into that space, that problem seems to be being tackled via agents and MCP tooling, meaning Fusion, Workato, Boomi, and similar.
senthil_rajasek
4h ago
1 reply
In case, like me, you didn't know who Bret Victor is,

"...Victor worked as a human interface inventor at Apple Inc. from 2007 until 2011." [1]

[1] https://en.wikipedia.org/wiki/Bret_Victor

future10se
3h ago
He's actually more well known for the talks he's given and demos he's created since then. Here are a few:

• 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/

floppyd
4h ago
2 replies
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!
marcelr
55m ago
yea i tried to do this (somewhat successfully) with a custom editor for css https://github.com/feralsoft/charisma (demos on my old x https://x.com/charisma_css)

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

phtrivier
2h ago
1 reply
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 ?

matu3ba
1h ago
> 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 ?

That depends on your goals. If you are into building systems for selling them (or production), then you are bound by the business model (platform vs library) and use cases (to make money). Otherwise, you are more limited in time.

To think more realistically about reality you have to work with, take a look at https://www.youtube.com/watch?v=Cum5uN2634o about types of (software) systems (decay), then decide what you would like to simplify and what you are willing to invest. If you want to properly fix stuff, unfortunately often you have to first properly (formally) specify the current system(s) (design space) to use it as (test,etc) reference for (partial) replacement/improvement/extension system(s).

What these type of lectures usually skip over (as the essentials) are the involved complexity, solution trade-offs and interoperability for meaningful use cases with current hw/sw/tools.

phplovesong
6h ago
Instead of this we got AI slop that is literally everywhere you look.
dang
1h ago
Related. Others? I thought there were others, since I remember this one as a classic...

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)

laszlokorte
2h ago
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.

[1]: https://youtu.be/ef2jpjTEB5U?si=S7sYRIDJKbdiwYml

[2]: https://youtube.com/playlist?list=PLfGbKGqfmpEJofmpKra57N0FT...

sodapopcan
4h ago
This is one of my favourite talks ever! Glad to see it here (probably again).

Also, Erlang (non-explicitly) mentioned!

Also, I'm super glad we never got those "APIs" he was talking about. What a horrid thought.

masgis
34m ago
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.

https://christophlocher.com/notes/ethnographic-research-on-d...

haritha-j
4h ago
Look at the big brain on Bret!
enos_feedler
5h ago
had the privilege to be there in person. was magical live
jackdoe
26m ago
Loosely related is "Stop Writing Dead Programs" https://www.youtube.com/watch?v=8Ab3ArE8W3s
dzonga
5h ago
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 ?

pmkary
7h ago
The biggest wish I have is to one day meet maestro. Greatest living mind in my opinion.
jason-richar15
35m ago
The future of programming points toward AI-assisted development, low-code/no-code platforms, and more efficient, collaborative tools—making software creation faster, smarter, and more accessible to everyone.

24 more comments available on Hacker News

ID: 45912457Type: storyLast synced: 11/19/2025, 7:23:56 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.