"Stop Writing Dead Programs" by Jack Rusher (Strange Loop 2022)

I made my way through part of the talk on youtube, it was interesting but far too much for me to stomach. It really drove it home when he flashed slides of graphic organizations of complex data. While some parts might be better than a textual description, graphic representation of data needs to be useful , that is, you need to be able to look at a graph and glean information from it. At the section where he flashes an image of a re-imagined periodic table[0], he immediately exclaimed "look how beautiful it is!" and I was immediately instead confused. What does this image show? If it is a periodic table, can I see the periodicity? For example, can I tell two elements have electrons in the same shell by just looking at it? Can I see if two elements have the same filling of the subshell, and thus will covalently bind in similar ways? Can I tell which elements are more electronegative? I can glean all that from the "boring periodic table," which yes is a graphic representation and cannot easily be written in sequential text, but this new representation doesn't give me any of that at least as far as I can tell. The desire to represent an already existing set of data in a new graphic representation that seems to give no value apart from being novel is not helpful. I can extrapolate this down. A lot of things in life are the result of historical evolution; that is just how things are. While that history can lead to problems, it is just the way things are. And yet, it should be beyon

I was inspired to post this by watching the following talk: "Stop Writing Dead Programs" by Jack Rusher (Strange Loop 2022) [VIDEO]

Are you talking about this? [VIDEO] It's not inserting images into the code. It's a structured editor presenting an alternative view of the code. It's just code. That's all there is to this. Man, frustrating.

Jack Rusher mentioned the Glamorous Toolkit in his talk "Stop Writing Dead Programs" [VIDEO] And here we have the Glamorous toolkit. This is Tudor Gîrba and feenk's thing. They embrace this philosophy completely. They have built an enormous suite of visualizations that allow you to find out things about your program while it's running. We should all take inspiration from this. This is an ancient tradition, and they have kind of taken this old thing of Smalltalkers and Lispers building their own tools as they go to understand their own codebases, and they have sort of pushed it – they've pushed the pedal all the way to the floor, and they're rushing forward into the future and we should follow them.

To quote "Stop Writing Dead Programs" [1]: "If what you care about is systems that are highly fault tolerant, you should be using something like Erlang over something like Haskell because the facilities Erlang provides are more likely to give you working programs." [1] [VIDEO]

Oh my... Does anyone remember Cobol? Pascal? How about Prolog (the 5th gen language)? Standard ML? and now Rust. Compilers are a dying technology. Stop Writing Dead Programs" by Jack Rusher (Strange Loop 2022) ( [VIDEO] ) Meanwhile, the hardware world is moving to field programmable gate arrays (FPGAs), Neurocomputing, in-memory logic, dynamic soft-core processors, analog memory, etc. What does Rust do with memory that self-modifies, or has no defined logic values, processors that dynamically add or remove instructions, etc. What does Rust do with programs that self-modify? How long will it be until C++ (2090?) adds borrow checking and Result handling? What's so "Secure" about Rust? Does it handle row-hammer attacks? DMA overloads? Heartbleed? Rust is reaching "peak hype". Sigh.

Because we live in a free society and smoking is a proper right. It is unhealthy and largely outdated habit but if you want to light a cigarette, you can. Programming in C++ is also an outdated habit. There are better languages, better technologies, and there are generally better ways to create software than writing code, compiling the code, replacing std::abs with abs (real issue, these are different functions) and recompiling the code again. But writing in a horrible language is a proper right as well. People write in Brainfuck for fun and good for them! Jack Rusher sums up what better programming looks like in his Strange Loop talk [VIDEO]

I think they are. When a crash happens, the cause is identified, we patch the bug, and redeploy the system. After that, the software cannot fail for the same reason again—it's leas fragile than before. A fragile thing is like a wine glass. Once it breaks, it cannot be restored to its original state and especially not made better than before. However, if you're talking about patching the system while it's still running. Check out "Stop Writing Dead Programs" from Strangeloop last year. [VIDEO]

It seems Victor's vision has a hard dependency on an environment that makes this kind of meta-manipulation very natural and easy. Basically it seems his vision is the UX extension of this lower-level DX vision: [VIDEO] "Stop Writing Dead Programs" by Jack Rusher (Strange Loop 2022) Of course this kind of runtime freedom/power/access probably has a performance cost, aaand I have a hard time figuring out how it would work in a real-life setting. So yeah, instead of this super-universal tinkerability what's really needed (at least in the short term) are better tools. A better strace/tcpdump, better frameworks (better batteries included in more places). More care for "post hoc" error investigation. (Yeah a 2000 line exception going back to EveFactory(AdamsRib) factory is great, but what was the incoming HTTP request? What was the value of the variables in the local scope? What was the git commit that produced this code? Etc.)

Your "unpopular rant" (or one pretty much like it) has 376k views and 12k likes on youtube![1] (Recommended watch, not least for demystifying the origin of vi's navigation keys and the choice of ~/ for /home/you.) 1: [VIDEO] (link jumps to 16:52)

I believe this to be an artifact of our current paradigm of software development, which is based purely around static "batch processing" where the software can't be molded easily. (I didn't want it to come off as a plug, so I didn't add it to my original message, but I'm working on something to solve that.) To get a better idea of what I think is the better approach, check out these talks: Tudor Gîrba - Moldable development - [LINK] Jack Rusher - Stop Writing Dead Programs - [VIDEO]

Very cool! This is something Jack Rusher cries for in his talk "Stop Writing Dead Programs" [VIDEO]

It's pretty much impossible to explain to people what it's like to work in a CL environment. A good presentation on what we're missing: [VIDEO]

> trying to understand what's happening in code is even harder It's different in Lisp because you basically program a thing from the inside out, meaning that you don't just read the code from top to bottom. Instead, you constantly evaluate expressions and expand macros while going through it. It's practically like playing a game, and there's a good amount of fun. People often dismiss Lisps (Clojure, CL, Fennel, Racket, etc.) after reading Lisp code without any connected REPL and often don't even grasp what makes it so awesome. It's like disliking food after seeing it for the first time in a cooking show on TV. Good talk of relevance: "Stop Writing Dead Programs by Jack Rusher" [VIDEO]

> simple examples comparing Lisp ... that illustrate the benefits of using Lisp over another language It depends on what you're trying to get out of it. For example, you can grab a simple code of some React components with JSX and ask ChatGPT to write it in Hiccup (Clojure). That would show you how s-expressions can reduce the syntax boilerplate and make it smaller. You can do the same thing with Lua and Fennel - Fennel code would be much shorter and cleaner. However, without proper understanding and using structural editing and connected REPL, you probably won't see any benefits right away. Lisp code is not the best to be read off the "dead medium" - paper or screen. It's better when you have a connected REPL because it allows you to evaluate every single expression on the fly. Instead of trying to understand what (foo x y z) means, you can evaluate it and immediately see the results. With a connected REPL, you can evaluate them separately (individually), or together. Good talk of relevance: "Stop Writing Dead Programs by Jack Rusher" [VIDEO] Next step in understanding the benefits of Lisp code is learning structural editing. Because everything is a symbolic expression, you can easily move, transpose, change, and replace parts of your program. Instead of rewriting a function of seemingly arbitrary syntax constructs, you'll be dealing with well-structured forms that you can easily move around. No, it not the same, better or worse than using refactoring features of your IDE wi

Hi I think is in the hypothesis (I'm not sure) of that we have edition made by the pdp 11 keyboard developer and tooling that's old and design whiout introspection in mind showcase in this video, the video is really cool but little bit long [VIDEO]

I think we might potentially be looking at this backwards. There is a great talk by Jack Rusher [1] on why having really slow iteration loops and being too disconnected from running programs creates a desire for theorem proving because it becomes the faster way to arrive at a correct solution. I am of the belief that we need to return to modifying live environments instead of sending code through a lengthy build pipeline. Instead of trying to make live environments secure and durable we got scared and now we have modern CI/CD. [1] [VIDEO]

Live development is still so under-explored, and is just so exciting to work with. One of my favorite talks is "Stop Writing Dead Programs" ( [VIDEO] ) and touches on a lot of what could be in terms of live development. Lisp is very well-suited to live development due to code being data, but live development doesn't need to be lispy. I built a live development extension for Love2D which lets you do graphics livecoding (both lua and glsl) in real-time - every keystroke updating the output, (if a valid program). [LINK] Here are some (early) demos of things you can do with it: [LINK] So many cool things once you break down the barrier between editor and running program. I've also asked myself the question of, what would a language look like that was natively built for live development, and built out a prototype - though it's definitely a sandbox so haven't posted it anywhere yet, other than demos on mastadon.

> eventually gave up because -- well, Lisp, right? That would be an utterly misguided approach. Lisp is amazing, you just need to give it a chance to be appreciated. Accept it with all its flaws and immense power, surrender to the malleability of the structure, dynamism of types and its homoiconic nature and you may find something incredible that would last you a lifetime. You need to conquer two aspects - structural editing and REPL. Learn basic structural editing idioms - find a way in Emacs (or whatever editor of your choice) for automatically balancing parentheses, for slurping, barfing, transposing s-expressions, cutting and pasting them. That will make all your programming like literally assembling lego blocks - something every other (more traditional) programming language promises yet somehow fails to deliver. Then learn eval commands - get into the habit of REPL-driven development. With Lisp, you don't have to wait for compiler, transpiler, linker, linter, etc., you can just write anything and see how it runs in-place. Often, you don't even have to save anything to a file. Relevant video to watch: [VIDEO] - Stop Writing Dead Programs by Jack Rusher. Try modern Lisp dialects - there's plenty to choose from depending on what kind of tasks you're trying to solve - Clojure, Janet, Fennel are all very fine candidates. Clojure is especially nice if you need to deal with data. In my opinion it's hands down the best medium for data manipulation - nothing even comes close to t

I agree with the author. I've written my fair share of typed code, but it is way more valuable to probe your program while running. I feel Jack Rusher puts it quite nicely in this talk: [VIDEO]