The Future of Programming (2013) [video]

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 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...

Doing this kind of stuff,

https://www.youtube.com/watch?v=7wa3nm0qcfM

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)

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.

There is no better time than now to try something brash and perpendicular to the mainstream.

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.

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.

This is excellent: thank you for pursuing these wonderful ideas.

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.

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).

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...

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.

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.

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.

I envy you sooo muuchh

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/

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.

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

You might like https://cs.brown.edu/~spr/codebubbles/

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).

> 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.

You could start a new project or contribute to an existing one. You could try out other people's projects and write about what you learned. You could write about what you learned from your own projects. You could give a talk that starts with a killer demo. You could try to find work that improves the situation, however slightly, instead of worsening it. You could sharpen your skills so that when you have more spare time you can make faster progress.

> 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.

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 com­mer­cia­li­za­tion. 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.

wow i was really primed to hate this article and this take because i, for lack of better terminology, genuinely view Bret Victor as an idol of mine. but i guess that is the thing with idolatry… to be clear to anyone who doesn’t care to read the article (understandable): there’s nothing untoward or unseemly, just a research group that is clearly lost, and Bret as BFDL not being able to “save” it. i will say that the other researchers come off as being pretty soft and useless, but that obviously does reflect back on the group’s raison d’etre and thus, by extension, its leader. like, imagine being recruited to a research group by Bret fucking Victor and being like “nah, i don’t want to work on anything useful, and if i can’t do exactly what i want to do, i quit”. i say this all, despite appearances, with the utmost respect for all those principals, who i have stalked on github, X, etc. to an unreasonable degree out of a pure, assuredly naïve desire to get more bits from people who i consider to be doing the so-called “Lord’s Work”… the people they brought on absolutely are legit enough to have earned the right to not genuflect to anyone, but… where’s all the idealistic belief in building something better for tomorrow that they all portend to care about, from their own words? i don’t want to get political, and won’t, but… it feels like the most self-centered take on idealism since… aw shucks, yesterday… it’s my fault for putting these incredibly brilliant people on a pedestal, but i still find the whole thing incredibly disappointing, as someone who, well… idolizes them. and i would rather be disappointed than chastened and cynical— the world has PLENTY of that to go around, and i still believe in the power of the intellect to transcend this kind of bullshit, this case notwithstanding.

A cult is usually what it takes to turn impractical ideas into practical ones. This link is great, thanks!