Bret Victor - Inventing on Principle

>Brett Victor - Inventing on principle: ▶ this video This gave me a sharp moment of clarity, thank you so much for this! I'll work on the wording over time, but here's a rough sketch of my principle: My principle is that no person should ever be forced to blindly trust a computer to do the right thing. Computing shouldn't be either blindly trust the black box, or get nothing done. Nobody should have to hand over their wallet to buy an ice cream cone, you can just take the exact change out and pay. Why should you have to give a program access to everything when you just want to edit one text file?

Nice, but I think I can raise you. That talk mostly seemed pretty predictable (though I incorrectly guessed gfx via sixels[0], not a(nother) terminal emulator). If your interest was piqued with that parent video though, prepare to have your mind blown with this[1], who’s thesis maybe similar in the sense of “stop _just_ simply working”. Bernhardt seems to be saying don’t be afraid to take time and think deeply and “go deep”, while Victor is explicitly saying make it count by way of targeting with intention what’s important to you. A sort of “fight the good fight.” [0] link [1] ▶ this video

I think most here have already seen it, but I find that Bret Victor's Inventing on Principle talk[1] is one of the best I've seen. I re-watch it every so often to help prevent my thinking from falling into a rut. When developing software as a career, it's so easy to just fall into a pattern where you use the same tools and techniques over and over again. Watching this talk this talk inspires me to investigate alternate approaches to developing and delivering software. It's easy to think of software development as something that always need to involve code, and nothing but code. But watching this talk inspires me to go and try things like Node Red and Unreal Blueprints. In both cases, code is usually still involved, but they both offer a visual way of connecting components. I find it helpful to be able to visualize software this way so I can immediate understand how data flows through the application. [1] ▶ this video

If you are a skeptic on this, I really urge you to listen to Bret Victor. I have generally been skeptical of these kinds of things in the past, but just in the last week Bret Victor's talk (▶ this video) combined with his excellent 2006 paper that digs into related concepts (link) has made me re-think that position. One of the key points in his talk that made me think about this more is that there are whole avenues of exploration that are completely inaccessible when the feedback loop is as long as it is with current programming techniques. I think it depends highly on the kind of programming you do. The more closely related your programming is to math (e.g. engineering simulations or stats), the less likely you are to see an issue because you're directly manipulating the "stuff" you're working on. But if you write software that operates more in the human space (e.g. something like an email client), then you're acutely aware of how far removed the code is from the user and what the program does. You basically have to keep a giant mental model in your head as you code. That is a huge cognitive load that all of us take for granted as part of "programming" but why must this be so?

Author here: yeah, this is a good point and something I think about even outside the context of agentic coding. I've also tinkered with this idea myself in the context of prompt engineering with my Grace Browser project (link), which converts code to an equivalent dynamic web form live within your browser. I do think it's useful to remember that code is not the end goal and is itself just another mediated interface to the actual goal: the product your building. However, I think even if you cut code out of the picture the chat interface is still not necessarily the right interface for building a product. A great example of how to build a non-chat interface to product building (predating the AI boom) is Bret Victor's Inventing on Principle talk (▶ this video) and there might be ways we can refresh the ideas in that talk for the AI era (although I still don't have any specific thoughts along those lines yet).

I absolutely care about things that take hundreds of milliseconds for my builds. The faster I can build, the faster I can iteratively try new things things out. The goal should be to be able to see changes instantly after you make them, and Tailwind is usually just 1 part of a build pipeline. Bret Victor's Inventing on Principle is probably the best demonstration of why this matters; in the first 10 minutes he shows a very concrete example of an insight that would not have occurred without instant feedback ▶ this video

Great to see. More generally: I feel like playgrounds are grossly underused in our industry. It's possible the issue is in the name -- it immediately connotes that whatever you're doing isn't real work, it's just a place to, well, "play". But really these kind of playgrounds are at least a cousin, if not a direct descendant, of the immediate feedback principle that underlies everything from a REPL to the kind of systems (Symbolics, etc) that allow you to edit running code. Their potential is beautifully illustrated in Brett Victor's famous 'Inventing on Principle' talk: ▶ this video Three areas that I'd love to see playgrounds mature beyond teaching beginners CSS: 1) Integrated directly into developer documentation. You can see some of that in systems that are documenting services -- for example, the Google Sheets API documentation has a 'Try this Method' box that lets you post a request to the service on the same page that describes it, but what I really want is something like that when I'm reading the man page of a destructive disk command, or a complex database query, or a low-level C graphics library. That'll require a playground wired to something as big as a VM, maybe. 2) Integrated into textbooks: for the last couple years the astonishing posts from Bartosz Ciechanowski ([Sound](link), [Bicyle](link)) have demonstrated just how much better a textbook could be if you could interactively play with the concepts you're reading about. Unlike dev docs, the thing you're interacting with doesn't even have to be "real". 3) Most ambitiously: integrated into the input form of bug/issue tracking tools. This is the opposite of play: it means a running system would need to be in cahoots with a playground, so that mature apps could let you record and playback what you saw as a user, allow you to edit irrelevant parts of input and output out and submit a complete here-look-see-it-is-busted asset for analysis. A Stackoverflow of the future would be orders of magnitude more interesting if each question was posed as a broken playground.

For the people asking who is Bret Victor: When "What are your favourite tech talks of all time?" is asked on HN, he gets more mentions than anyone else, usually. Some of his talks: Inventing on Principle ▶ this video The Future of Programming link The Humane Representation of Thought link Media for Thinking the Unthinkable link Seeing Spaces link Drawing Dynamic Visualizations link link

Rich Hickey - Hammock-driven development: link Brett Victor - Inventing on principle: ▶ this video Programming is terrible: link Dave Beazely - Python concurrency from the ground up (applicable to languages in general, with generator and corourine functionality) link Functional programming, with birds: link Short and classic: Wat link