Bret Victor - Inventing on Principle

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]

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 in

I love the design and the concept of the site as well as others in this space like jetstrap, easel, and divshot. To be honest, I've tried a few of these offerings and as a web developer this is not what I want, I'm looking for two things: 1. An editor like the one Bret Victor talked about in his "Inventing on Principle" talk[1]. I want to edit HTML and CSS and see updates reflected in real time[2]. 2. A way to hook this into a DVCS (Or better yet, a desktop application/desktop plugin). My development workflow relies heavily on Git and I don't think I'm going to download a zip payload and extract it every time I need to do a commit. [1] - [this video] [2] - [link]

No, they explain that LabVIEW and other visual languages are just different ways of representing the code. The idea here, I think, is that there's far greater coupling between the output of the program and the program itself. It's similar to some of Bret Victor's ideas: [this video] I'd like to incorporate this coupling idea into my own visual dataflow language ( [link] ), but haven't yet decided how to implement it. My approach has been to design the language from the bottom-up, so that simple programs can be simply drawn, and there are higher level programming constructs which simplify more complex code, avoiding the complexity problem (the Deutsch limit) you've seen with LabVIEW.

I think the next game-changing evolution in programming languages is moving beyond plaintext. Our basic building blocks of programming has not changed essentially since the beginning of programming. We still treat programs as nothing but a bunch of files and folders edited with the same tools that writers use to write romance novels (yeah yeah "intellisense" is not so intelli at the end of the day). We don't create beautiful images by writing RGB values in a text editor. We shouldn't be creating highly complex software systems with them either. We need model based editing environments that will allow us to have a much richer set of software building blocks. We have to allow software to be more than just characters in files. Software "source" is not a book. It's the blueprint for a system that has metadata and constraints attached to it. It can't comfortably and forever exist in a flat plaintext structure for human consumption. If you are interested go dig up my old comments I have written more elaborate rants about it before. And yes I'm ready for the inevitable and customary "NO IT AINT GON WORK WE TRIED BEFORE AND IT AINT WORTH TRYIN EVER EVER AGAIN" replies. Also relevant: [link] (I actually somewhat accidentally and indirectly caused the creation of the subreddit as a result of a discussion here on HN before) [link] [link] [link] [this video]