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

When you realize computer science has become a culture, with even an archaeology department...

I remember reading this story about a company that was trying to send a program to a customer in France. Trying, because every time they did, it would fail to run customers' hardware. Finally they sent someone with a case that contained the program to sort things out. When he went through customs he dutifully declared the program as an imported product, whereupon the customs official pulled a few cards out as a required "sample" of the imported product. Oh joy.

This guy speaks so fast.. basically about 5 presentations in the time for 1, but somehow, he is completely understandable and he keeps the attention of the audience!

I was almost through this entire lecture when I realized that all these issues sound like "when you're a hammer, everything looks like a nail." We were trained by a thousand editors and programming languages to approach problems in a particular way instead of asking, "What is the best tool to approach the type of problem I'm working on?" Thanks for showing some really good tools and challenging us to make tools that are equally good for working with certain types of problems and data sets.

My first programming class used punched cards running FORTRAN on a Sperry/Rand UNIVAC computer (IBM 360 clone). As a consultant over the subsequent decades I would carry a little history kit to show the newbies - some punched cards, a coding pad (80 columns!), 9 track tape, 8" floppies, and a little bag of coal as a sample of what we had to keep shoveling into back of the computer to keep up a good head of steam. As my friend called it - "The age of iron programmers and wooden computers."

I think the biggest problem with all visual examples is that they work great for data-science or theoretical algorithms, but far less for your run-of-the-mill "corporate programming" such as (web)services. When building services, almost all of the programming is about creating a model of the real world, and not so much about visualizing and transforming data. All those examples of graphs, tables, flows etc. work really well for data-science (hence things like Jupyter are so popular there), but they don't generalize to domain modeling very well. I would absolutely love to have some sort of interactive and visual environment to build and maintain domain models, but I've yet to come across anything like that.

My high school had Apple ][s and UCSD Pascal but the teacher didn’t want to learn a new language so we had to do Fortran on punched cards, instead. The cards would go to a university about 30 minutes away but the results took a week to come back.

One of my more unmistakable descents into IT Madness: At Conrail, I had to write out my COBOL programs on 14-inch green-and-white coding sheets, and send them over to the 029 experts in the Punchcard Department. Next day, when they'd dropped the code into my Shared Storage, it would contain so many errors that I had to spend an hour fixing it... So I took to typing my code directly into Shared Storage, using my handy-dandy SPF Editor... and was REPRIMANDED for wasting my Valuable Professional Computer-Programmer Time.

This talk is so engaging it made be spontaneously clap along with the audience while watching it at home.

@11:06 rank polymorphism, I mispoke in the heat of the moment.

I would love this, but give me a language and IDE, that properly completes symbols for me, is context aware, is _interactive programming_ before I even wrote it. - That's why I like types. Kotlin, C# ... They are helpful sooner. They catch nearly all typos. In fact, I always tab-complete, so I never have to worry about typos. - I tried Elixir because the erlang model is so great, and I had dumb mistakes right away (typos, wrong symbol, etc), all costing lots of time to go back to. Only found through running tests, instead of before I even made them. - An environment that let's me make mistakes is worse, then one where I notice them ~live. Worse is only type checking (and no help) at compile time. Even worse is only getting errors at runtime, which sadly due to many reasons, when trying Clojure, that's where I would end up. A lot of things are a problem to do in the REPL, say I need to inspect argument to some callback. In Kotlin, I at least see the full type spec, and the IDE is helpful. In Clojure, I need to mock-trigger the callback, hope it roughly matches production, hope I can "suspend" inside the callback and and hand craft a reply, and that's even worse: How do I know what reply it wants? Reading docs is tedious. Filling out a clear type "template" provided by IDE is really nice and simple in comparison.

From 18:00 to 19:35 is such a good sequence haha, I finally understand VI keybindings

Lecturer: Talks about debugging in fancy visualization Me: Cries is performance

It isn’t every day I see a conference talk that reminds me why I want to work on being a better programmer. Thank you.

As a sort of self taught programmer, now I understand the purpose of notebooks. Thank you for that.

It's all spot on. Optimally, we would spend all of our time in solving the actual problem at hand, instead of spending most of it fighting the details that emerge from our choice of tools/solutions.

The history of the vi arrow keys and the home/~ connection blew my mind! Now it's time to go down the Unix history rabbit hole.

I have to say some things about this talk really irked me. Like the implication that APL has superior syntax because for this very specific use case it happens to be quite readable and more terse than the alternatives Most choices are a compromise one way or the other. Compiled languages might be "dead programs" but that's the cost you pay for function inlining, aggressive code optimization, clever register allocation, known static stack layout and so on. That's why compiled languages are fast and static and not slow and dynamic. It's all a trade off In fact just yesterday I had an idea for code hotreloading in Rust. One limitation that immediately came to mind is that every control flow that crosses the module border will have to use dynamic dispatch, mostly preventing any meaningful optimization between the two

Now I wish there where a part 2 of this talk that goes into more detail regarding modern language options that tackle these issues. A lot of the options mentioned seem near impossible to setup in a dev environment because the tooling is so outdated that I have to spend more time getting the environment to work than even thinking about programming in it. It especially seems like there are no options whatsoever when it comes to hard real-time applications like audio synthesis.

I never even stopped to think about it, now I have a name for it: introspection. Before studying the hard theory about regular expressions, I never actually understood them and just resorted to copy one from stack overflow. After learning the theory, I still don't write them as punch cards, instead I like using websites where you can test them in place, see explanations and so on. Now I don't feel bad for wanting to attach a java debugger to a live server haha

>It's what your processor wants No, it's what high level languages want. Just don't link to malloc and allocate the new array on the stack. And better yet, don't link code you can just assemble, include directly into the main file with (using an assembler like NASM) the 'incbin' directive and call without some rigid ABI. Ironically, he is shoehorning an archaic concept like "programs must be linked" into an assembly language program that does not need it. You don't actually need to link in assembly unless you specifically need a dynamically linked library. You are shoehorning a bunch of high level assumptions into assembly language programming. This sort of behavior makes me think you did not actually write this in assembly, that you wrote it in C or something and cleaned up the ASM output a bit.

APL actually has a shortcut for making a list like 1 2 3 4, such that you can do the example program in only 4 characters : 1+ι4 (that's the greek iota letter) instead of 1+1 2 3 4

Two things: 1) let the compiler blow up on the dev rather than the program on the user (especially if you seek the lowest runtime overhead, or you ARE making the runtime) 2) you can start getting this future, today, with current languages, using Jupyter notebooks and alike (e.g. literate Haskell)

I dislike that Tweet towards the beginning about how programmers will feel good about learning something hard that they will oppose things that make it easier. For several reasons. Firstly, it could be used to automatically dismiss criticism of something new as the ravings of a malding old timer. Secondly, it paints experienced programmers as these ivory tower smug know-it-alls. Thirdly, it implies that behavior is unique to programmers. Do old time programmers sometimes look down from their ivory towers and scoff at their lessers? Absolutely, and I am no fan of that either. But the Tweet at face value could lead to someone with a new idea (or something they believe is a new idea) being arrogant. The bit with the increasingly smaller ways to write an incremented array ignores the fact that the more you remove semantics which more obtuse languages have, the less clear it is what the program is _actually doing_ besides the high-level cliff notes. This can lead to extremely painful debug sessions, where the code you write is completely sound on a high level, but that the syntactic sugar is obfuscating a deeper problem. Lower-level languages have more semantics that they really need to, but the upshot is that it allows more transparency. It's often difficult to debug average issues with, but it's significantly easier to debug esoteric issues if you slow down and go line by line. Not to mention it makes very specific optimizations easier as well. A lot of the ideas in this video have been tried and didn't stick around not because of adherence to tradition, but because they simply were not as effective. Visual programming in particular. It has the same problem as high level languages in that it's easy to capture the essence of the program, but not the details. Ideally you would have both a visual representation side by side with the text-based semantics.

I realized my habit of printing out variables and what information is being calculated in what the speaker calls "dead languages" is exactly the point he's making. There needs to be easier ways to observe the data and processes we write as it runs.

It's very hard to carve a statue with a can opener. Selecting the right tool is key to success. But then most people also have an employee mindset, they are not toolmakers. It's good to see what other methodology is out there in order to set the right expectations in the users of programming environments and languages.

For those wondering, the title is likely a reference to Bret Victor's 2013 "Stop Drawing Dead Fish" talk.

It's not just the code itself that can have a lot of "this isn't part of the actual problem" problems. All of the "technical bureaucracy" (certificates, hosting, provisioning, deploying, releasing, building, source control, branches, pull requests, code reviews, unit/integration tests) contributes in a big way to stuff not part of the actual problem. In addition, "corporate bureaucracy" (development process, useless roles, incompetence, corruption) is a killer. At the end of the day, maybe 5% of your mental effort goes to solve the real problem, and the end result is ruined by the other 95%. Solving a problem with 5 lines of code versus 1000 lines just gets lost in all the other noise.

1:30 The 80-column "Hollerith" punch card design is an advancement over the original same-number-of-ROWS (12) with what I think were just 27 columns (circular holes rather than narrow rectangles) designed by the man named named Hollerith himself for tabulating the 1890 U.S. census, decades before there were "computers".

Terrific talk, laughed, and then I cried, then I was hopeful again. I won't turn to carpentry just yet. Thanks Jack.

What I really enjoy about Dart is that, even though it's punch card compatible, thanks to hot reload I need to compile the program usually just couple of times a day when I pick up some new thing. Most of the time code can be reloaded in real time at incredibly short feedback loop. I still wish there were more features that would help visualize the structure and relationships of code but it's already so much better than most of the tools in the mobile ecosystem.

Getting the night's production jobs loaded (via punch cards) as quick as possible was aided by the operators removing the rubber bands and lining up the "decks" on the counter. That is, until the night when the HALON system was accidentally triggered, sending the cards everywhere. It took quite a while to find cards stranded under equipment. Fortunately the strips on the sides of the cards helped. But it was a long, long night putting everything back together.

I see this often but it usually falls apart when you approach higher levels of complexity. There are many graphical programming languages, you could even call photoshop a programming language. The problem is there are tons of experiemnts but none of them really create anything "new". They spend their time trying to copy functonality from C. Stop copying C in your GUI Language.

I loved this talk but I don't know why the author is sounding as though typing is somehow a waste of time or insignificant. Most web Devs use typescript or Babel because otherwise you wouldn't catch a lot of errors while writing the program. Type checking has nothing to do with making the programming experience interactive, and in fact would aid it.

Dynamic, interpreted languages are better than statically typed, compiled ones? Now that is a hot take. Not a good take, but a hot one.

Incredible talk: I noticed the homage to Bret Victors: "Stop Drawing Dead Fish!"

I don't get the point. People have tried all the ideas presented here in various languages. If you don't understand the reasons behind standards, or why a mediocre standard that's actually standard is often more important to have than a "superior" one that doesn't develop consensus, you're missing a dominant part of the picture. For example, the reason TTYs are 80 columns wide is essentially because typewriters were. Typewriters weren't 80 columns wide because of computer memory limitations, they were that wide because of human factors -- that's a compromise width where long paragraphs are reasonably dense, and you also don't have too much trouble following where a broken line continues when you scan from right to left. Positioning that decision as just legacy is missing some rather important points that are central to the talk, which purports to be about human factors. I could start a similar discussion about why people do still use batch processing and slow build systems. There are a few good points in here, and if what you want is comedy snark I guess it's okay. But most of the questions raised have been well answered, and for people who have tried interactive programming and been forced to reject it because the tools just don't work for their problems, this talk is going to sound naive beyond belief. The presenter seems particularly ignorant of research into edit-and-continue, or workflows for people who work on systems larger than toys. The human factors and pragmatic considerations for a team of 10 working for 2 years are vastly different than someone working alone on data science problems for a couple months at a time. The one thing I'll give the presenter is that everyone should give the notebook paradigm a try for interactive programming.

I do agree that having runtime reflection is a great thing so that we can look at the environment / state over time. But i hard disagree with most of the other points in this talk. 1. comparing C / C++ / Rust / Zig with Lisp / Clojure etc.. is just plain wrong. anyone can see that these languages are targeted at different use cases. They are manually memory managed low level languages for precise control and peak performance to extract everything out of hardware. literally just a step above assembly. 2. This talk conveniently skips over things like Garbage collection (and performance in general) except for a reference to tweet talking about devs being okay with stop the world compile times but not stop the world garbage collection. Games or Apps sensitive to latency ( real time music/video editing, trading etc..) just cannot afford to have that garbage collection pause no matter what. But devs can very much afford that compile time. 3. Saying Rust and other ML family languages don't improve software is also debatable. Rust's typesystem turns runtime errors into compile time errors making the software more reliable. Rust is in trial mode in Linux kernel.. because it provides a proper safe typesystem that C doesn't. Most of the talk is about debugging, viewing runtime state and live interactive coding. Which is more about tooling surrounding the language rather than just the language itself. We definitely need better tooling and many projects shown in the video are good examples of what might be possible in the future. for anyone interested, i recommend watching the talk about dion format dion.systems/blog_0001_hms2020.html which also talks about editing syntax trees in a custom IDE instead of a text language with syntax. Rust has been getting decent tooling to improve developer experience. github.com/jakobhellermann/bevy-inspector-egui for example shows all the game State live AND allows you to modify it. there's github.com/tokio-rs/console for async server apps to provide a look into the runtime state. you can always add a scripting language to your application (like lua) and query any state you want. there's other initiatives like lunarg's GfxReconstruct which will dump all the vulkan state so that the developer can reproduce the gui/graphics state exactly on his machine by receiving the vulkan dump from user. people are working on lots of cool ideas to help with debugging state machines. Although, i think a custom rust specific IDE will go a long long way.

The only question I have is: "How do you mix heavy optimizations of Rust/C++ with powerful debugging and on-flight editing of Smalltalk?" If you have an answer, I'm willing to switch. From my experience JIT compiled code is always slower than AOT compiled. (And "lol just get a more powerful PC" or "stop running server workloads on a 10 y.o. laptop" are not valid arguments) If somebody has an example, of a performance-dependent software written in Smalltalk/LISP-like languages, like ray-tracing or video-encoding, I'd like to take a look and compare them to more conventional solutions.

In the multi-media programming world there are pure data and max/msp, that are very similar to his last examples and very commonly used by artists. This talk shed helped me understand why I keep coming back to those for projects where I have to iterate on ideas very quickly.

At the high school I attended in the 1970s we used punch cards typed in a KEYpunch machine (not "card punch"), and we fed them into the card reader and took the lineprinter (much faster than a teletype, although that was also an option for program output - program LISTING was always via lineprinter) printouts ourselves, so not all setups were equally primitive. Also, the reader was able to read either actual punches or pencil marks, and we developed "code cards" to allow us to make code with pencil marks (called "mark sense") so we weren't limited to the bottleneck of one or two keypunch machines for everyone to use, and I myself wrote the program to generate punched cards from marked cards, used at the school for several years after I graduated.

What a great talk, thanks Jack. I agree with most of what you said. I just don't know what to do about it. I think our industry as a whole is in a local maxima, and don't know how to get out of it.

I have to admit, the idea of messing with runtime as sysadmin and security guy sounds nightmarish. Great tools in the Dev env, but in production it seems like a system that limits checks and requires increased trust of the devs. Mind you I'm in the sysadmin camp that IaC and CaC greatest benefits is that you move AWAY from click here to do this administration and towards more formally tested and explicit ones.

The idea of visual programming was not ignored, it has been tried over and over and failed in many ways. The keyboard remains the best input device available and programming languages are structured around that, program input and algorithm expression. The visual cortex can process much more but the human mind cannot express ideas faster than it can speak them or type them. What we need are not non-text languages, we need better code visualization tools that take existing text code and annotates it in an easy to understand visual format. The entire compiled artifact diatribe becomes irrelevant if the programming environment has an Edit&Continue feature that recompiles a minimal amount of text code, relinks and reloads the parts effected, so you can continue debugging from the same state, or some saved intermediary state before the bug manifested.

Food for thought, though he glosses over why things like edit/compile/link cycles still exist. There are costs to things, and sometimes those costs aren't worth the benefit.

I have used an IBM 029 key-punch. When I was in high-school (about 1980) we used bubble cards, but the near-by university had key-punches so we would go there to type in long programs. We still had to send the card decks to the school board computer center (overnight), because we didn't have an account at the university.

This was an outstanding talk; interesting but with good humor. I think I need to go take a peek at Clerk.

The fact of the matter is that all of our hardware infrastructure expects the user to program in either ASM or C. Runtime environments are expensive and not available at the bare metal level without a ton of headaches. Lua is promising but it's written in C. I agree that modern hardware introduces many problems that don't have anything to do with solving the business problems that make us money. Maybe more people should become computer engineers and devise an ISA that allows for visual and runtime feedback natively.

Smalltalk was one of the best live coding environments. You could change source of active stack frames. The issue was delivering the program to “production” on one of 100s of servers.

Sooo... I work in the Energy industry, we just retired our last VAX in the last 18 months...though we still have a bunch of virtualized VAX for historic documentation. We also just replaced a real time system that had one of the very first mice ever made (it was actually a Trackball and it was MASSIVE).

Every popular language without static types eventually gets static type support, but worse than if it got it in the start. Have you tried debugging 50TLOC+ python codebases without type annotations? It's infuriating. Type systems are a must. They don't need to be rigid or obtuse, but there has to be some mechanism for the programmer to know at a glance what to expect. Also "build buggy approximations first" is objectively wrong. Everybody knows that generally managers don't allocate time for bugfixes and refactoring. If you teach all programmers to write buggy approximations, you're gonna have to live with code that is 70% buggy approximations. Maybe he's talking about TDD like that, but it comes off wrong. Also I don't understand why he says debuggability is mutually exclusive with correctness - it's not... Yes, interactive code is cool, but correct, readable interactive code where all type-driven possibilities are evident at a glance is 10x cooler. Also Rust has a REPL mode. A lot of compiled languages do. Isn't that exactly what he wants? Also also what does he mean by debugging code in production? I really wish he'd elaborate on that.

Those graphical representations may help some people, but they just seem like more work to interpret as they are like a new language in themselves. They should be used only when they are the better alternative to comprehension for the average dev.

That's a line printer, not a Teletype. (And yes, I too wrote Fortran on punch cards.)

This absolutely blows my mind. I've been daydreaming on my ideal programming language for a while now and it basically boiled down to interactive visuals in the way leif made them, combined with a notebook view of your program like clerk. I'm so excited to see other people have made these things already :D

42:34 is "someone made Mathworks Stateflow at home". 29:07 is "Anaconda Spyder from Ali Express". 37:28 is Jupiter Notebooks 2.0. 38:37 is "Mom, can we have Berkeley Madonna at home?" The truth is that all of these tools have existed for decades, but people just wanna be hackers and there's no changing that.

The scope of this lecture is basically GUIs and servers. That's basically what this guy has been doing it seems. And don't get me wrong, I agree with all this for GUI and server programming. But saying that compiled languages are garbage because developing GUIs is a pain... I mean you be the judge of that statement.

The PL/I Checkout Compiler, under VM/CMS was my first use of a tool set that provided a powerful interactive programming (debugging) environment. The ability to alter code at runtime was a treat, generally only approximated by even today's debuggers. Progress seems to be a matter of small steps forward, interspersed with stumbling and rolling backward down the hill quite often.

Yes! That's exactly what I've been saying, but when I began criticizing my uni for teaching Pascal for a whole year, I almost got cancelled for "Not respecting the history of programming" and "Not understanding that you have to start from the basics".

Building buggy approximations is my specialty.

I was on the edge of my seat yelling "yes!" more than I wanted to admit, until now. Inspiring presentation on multiple levels, Jack, thank you.

I find your view of things very interesting. I observe there is a lot of activity again in the "visual programming" section. However while I do agree to some extent at least with sentiments I find that textual models are still gonna persist. I would love to offer a notebook interface to "business" people, so that they can simulate the system before bothering me (it would sure cut on the feedback loop). But for the most part I think 70-80% of any codebase I worked with is "data shenanigans" and while I do like for textual data there to be visually adequate(formatted to offer better view of the problem) I do not find it enticing to expose those. Another problem I find is that, UIs are and likely will always be a very fuzzy, not well defined problem. There is a reason why people resort to VScode - as it is texteditor. So you also have this counter movement in devtools(counter to highly interactive/visual programming) and returning to more primitive tools as they often offer more stable foundations.

I think he conflates type safety with bad dynamic ergonomics. We can do better, and have both decent types and decent ergonomics

Woah, this was a refreshing talk! Thank you Jack Rusher, whoever you are, for sharing thoughts which I never knew I had as well - let alone that I agree with

A really strong start, we do a lot of dumb stuff for historical reasons, but the second half seems to totally ignore performance and honestly anything outside his own web realm. The reason programs start and run to completion is because that's what CPUs do. You can abstract that away, but now you're just using user level code and making it an undebuggable unmodifiable language feature. Sure functional languages look neat, but where are your allocations? How are they placed in memory? Are you going to be getting everything from cache or cold RAM?

Sometimes notebook/live coders create programs only they can run, because there is a certain dance you have to do with the machine, which acts like a magical incantation that produces output. The reason for Haskell style types is that the compiler will help you find the missing piece that fits the hole. Due to my low working memory I love machines that think for me. With unicode, most languages already support glyphs which are weirder than cosplaying tty.

This is a wonderful talk and I think it underline a lot of the weird things that non-programmers start finding and programming language. I was originally drawn while I was self learning to less because it was so different and because it does have some super powers compared to other languages. That seem so wrong that later languages did not incorporate a lot of the stuff that was innovative enlist even to this day. Erlang, Elixir, CLisp, Scheme, Clojure, Clojurescript are all wonderful and make my life a lot easier as a self taught dev. Elixir Livebook is wild

for those wondering, most of those things you get in C#. You can "skip" the hard things about types with dynamic keyowrd, see that it works, and then write the code in the proper way. You can create notebooks with C# code (and F# for that matter). You get hot reload for both UI apps and full on services. You get also one of THE BEST features ever, edit&continue. You can hit a break point, change the code and continue. What's more, you can drag the current line arrow before the if you just changed, and see right away if the change fixed the issue. Then you can attach the debugger to living program AND DO THE SAME THING. Think about that for a minute :D All of that runs reasonably fast in the end product and is very fast to develop (GC for memory, hot reload). You should really try dotnet 7, which is the latest version and as always is much faster than previous versions.

I feel like there’s a few arguments being made here, two of which are: program state visualization is good and less code is better. I agree with the first, debugging of compiled languages has a *lot* of room for improvement. If you think the most terse syntax is always best, please suggest your favourite golfing language during your next meeting :) Programmers today are wildly diverse in their goals and there’s no hierarchy on which all languages exist. An off-world programmer will need the ability to change a deployed program, one researcher might be looking for the language that consumes the least energy for work-done, an avionics programmer wants the language and libraries that are the cheapest and fastest to check for correctness. If you feel that all the features discussed in the presentation should all exist in one language maybe you don’t hate Stroustrup’s work as much as you think.

Why is it that in the software field, a lot of the communication is done through gigantic blocks of text? In the engineering disciplines, the main form of communication is diagrams.

I agree with the main concept of the talk, like, I'm always fighting with people over this stuff. That said, I'm a videogame programmer, and usually work in Unity so not much choice (even if I didn't most games use c++, Unity is C#). The thing is, in game development many of the things you say you have tools to implement and do. We can change variables on runtime, we can create different tools and graphs and stuff to see what's happening in runtime, visualize stuff, etc. Of course it's not the same exactly as the examples in the talk and these things are implemented due to the nature of how a videogame works, rather than for a better programming experience. Just wanted to point out a curious case of how game engines get a bit closer to this idea for different reasons.

Beside spreadsheets, I think the other very popular implementation of live programs that can change (and be inspected) while running are relational database management systems. They are robust, easy to use and to experiment, keep very often most of the business logic, easy to change, self documenting, self explaining (EXPLAIN and DESCRIBE etc), and highly optimized (to one part automatically, and you can give many hints to improve the optimization -> comparable to typing in programming), and secure. Indeed, the possible constraints are much better than in usual programming languages (with type systems and similar) by: expressibility, performance, durability, versioning, self-explaining, transactional behaviour and atomicity. They also ensure grants in different levels of details, while in a classic programming mode a programmer very often can see everything and change everything or nothing, but not much inbetween (like yes: you can do experiments on the running system, but it's guaranteed that you can't change or break something if you have rights to select from other namespaces, create views and similar in your namesapce, but no rights for altering or similar things, and get down prioritized when in doubt of performance automatically vs the production system). This liveness of the system might be one part of the story why an incredible amount of business logic is inside such databases and not in classical programming logic.

Hey i’m still using a tty terminal on an M2 Macbook faster than a Cray2 Supercomputer

Jupyterlab helps with visualizations. OEIS includes setting series to music.

The algorithm sent me here. What a fascinating take on compiled/batch vs interactive programming.

I usually do this to better understand computing, I don't even work as a developer of anysort so I'm just doing this as a hobby and it's fun to have these challenges

I know that in his opinion that live programming languages are appealing, but they aren't always practical. These types of languages have a great deal of overhead and aren't suitable for certain applications. The best example of this is operating systems. In this talk he bashes on Rust a little, but the simple truth is that it was never made for this purpose. I know people want the "One Programming Language that rules them All!" so they don't have to learn multiple languages, but reality isn't so kind. Certain languages are simply better at some tasks than others.

Clerk is then basically the same as Mathematica, just in lisp and with fewer functions

Entertaining but deliberately simplistic. How desirable would Linux be if its kernel were written in Haskell?

Jupyterlab might be a way to recognise that sometimes, no one language does it right and be able to support interacting runtimes of more than one language.

There are some low code platforms that somehow try to implement some of those ideas. I'm talking about power apps and their "programming language fx". Obviously, it has some bigger limitations and still a bit painful work with it coming from actual code... but it's quite nice being able to modify something "live"

Really can't disagree more with the "visual paradigm superiority" part as well as backward compatibility stance of this talk. The opposite of backward compatibility is a complete chaos and retaining it for a long time is totally worth it. I'm a long time vi user and unix user, but I came from a windows background and initially a lot of things didn't make sense to me. I'm in digital art nowadays and after learning and embracing the simplicity of vim and bash shell I can do things naturally: working with all sorts of files, writing scripts for almost all my purposes - like converting images, media files, custom backup scripts, 3d modeling and animation and many more. In windows and mac you can use nice GUI, but it comes at a huge cost of being burdensome to use, resisting scripting capabilities (try writing something to automate a process that involves a necessary clicking a button in some program that doesn't support command line interface) and so on and so forth. Our technology exists today thanks to "dead" programs that cared enough to support wider variety of interfaces. Text medium, while fancy like nice web page with all sorts of graphics can get it too far and turn to presentation which will try to convey the idea via picture but lack precision of concise text description. Someone said "Writing is nature's way of telling us how lousy our thinking is". If that's not convincing enough - one of the most successful companies - Amazon - intentionally discourages presentational style of conveying information about new ideas or new technologies in favor of rather writing it in a short and concise manner - if you're interested read an article "How Amazonians share their ideas". So, if you're new to programming, take this talk with a grain of salt. Clarity of thoughts is indispensable when you work on a complicated design and I'd argue is hardly achievable if you can't produce or consume a good old written content. Can't agree on "spec is always incorrect" argument. While I agree that spec is impractical for complete program it could actually be useful for some of its parts. For example, a consensus protocol "paxos" could be described in quite strict terms, proven and finally its implementation to some extent could be decoupled from the main program. Programming is about combining multiple parts into a whole and some parts (cryptography, distributed protocols ensuring livability and robustness of the system) may be a great fit for actually writing the spec. Also can't agree on "programming is about debugging" - it couldn't be farther from real world programs running on your mobile devices or in big datacenters. Logging, metrics is what actually matters to give you introspection on what your program and your users are doing. Also ability to quickly recover - e.g. issue a patch. I'd change this stance to "programming is about testing" when it comes to professional programming as big distributed programming could be too hard to debug and reproducing a particular debug sequence could be both hard and impractical.

I've watched to 11:46 in at this point...and I'm getting a smell. I'm not saying he's not correct overall, but his first two examples (Assembly and C), he's writing a re-usable function that, given an array, creates a new array, stores into the new array the values of the input array incremented by 1, and then returns the new array. In his last three examples (LISP, HASKELL and APL) he's hard-coded the array as a literal and the results of the function aren't being returned into a variable for further use. He's NOT doing the same thing. He's purposefully left out 'boiler plate' or 'ceremony' code or whatever you call it to make the difference seem more dramatic than it really is.

I still have warm memories of being able to do commericial Smalltalk development. Nothing else has ever felt quite the same.

My stock has risen! Licklider taught me to teach and Sussman taught me to program, some four decades ago, and now they're both mentioned in this excellent talk. Speaking as someone who helped port Scheme (written in MacLisp) to a DEC timesharing system for the first Scheme course at MIT, l don't know why your LISP examples aren't written in Scheme. Harrumph

Recently looking at fast ai , I can see the notebook live method has huge benifits compared to my line -by-line pycharm script. fascinating coverage of first principles progarming. I will buy the Kadinski point,line,plane. data rabbtis and racket. Im going to print and display the chemical elements for the tea room wall. There are so many stupid methods for doing simple things but the complexity gives some people a warm feeling that propogates the fools errand. great talk.

I have used the punch machine myself. I wrote a simple toy pascal compiler in PL/I on IBM 370 for college course (the "dragon" book) assignment. Compiling job is processed once a day in collage computer center. Now we come a long way and are living in age that AI can write computer code. What a wonderful days to live.

I don't really understand what he has against static artifacts being generated like with compiling Go. Relatively speaking, Go is easy to deploy to a different environment because of this.

What do you think of org-babel for literate programming? Seems quite similar to the notebook thing shown at the end. Otherwise, thanks for this talk. Really great. I’ve had this feeling for a long time and never quite knew how to express it. I always love to work in an interactive way and would feel hamstrung if I had to save, compile, debug, edit, save… every time I wanted to check something I’ve done.

R is also a one-liner: 1 + c(1, 2, 3, 4). Or even better: 1 + 1:4.

Use interactive programming to write the interpreter for the programming language.

Reminds me of the Gary Bernhardt talk from Stranger Loops 2012.

He's wronger than he is right. I'd love to be convinced but I think that most of these prescriptions would bring marginal improvement or go backwards. The better a visual abstraction you use, the more specific it is to a certain problem and confusing for others. The more power you give a human operator to interactively respond on a production system, the more likely they are to rely on such an untenable practice. The one thing I'd like out of all this is the ability to step into prod and set a breakpoint with some conditions in prod which doesn't halt the program but records some so I can step through. EDIT: Reached the end of the video and thought his Clerk project and the idea of notebooks being part of production code is fairly nice and much more limited than the earlier hyperbole.

This was such a fantastic talk, both in the subjects covered and in the very charismatic presentation. Thanks for sharing your insights Jack!

Flutter does a semi-good job with the "make changes as you go" thing

Man, I enjoyed this a lot more than I expected to.

Very interesting talk. Thank you.

There are a lot of gems in this talk and I like the really "zoomed out" perspective. But talking about all the "traditional" programming languages we use, I couldn't agree less with this statement: 27:24 "And I think it's not the best use of your time to proof theorems about your code that you're going to throw away anyway." Even though you might throw away the code, writing it obviously serves a purpose (otherwise you wouldn't write it). Usually the purpose is that you learn things about the problem you're trying to solve while writing and executing it, so you can then write better code that actually solves your problem after throwing away the first code. If this throwaway-code doesn't actually do what you were trying to express with the code you wrote, it is useless though. Or worse: You start debugging it, solving problems that are not related to your actual problem but just to the code that you're going to throw away anyway. "Proving theorems" that can be checked by a decently strong type system just makes it easier to write throwaway-code that actually helps you solve your problem instead of misleading you due to easily overlooked bugs in it.

(re-posting, looks like my comment got flagged for having a link in it) Excellent talk! One thing, Zig *will* have live code reloading, there's already been proof of concept working on Linux. It's just not at the top of the priority list, given the compiler should be correct first!

For SQL Server, we actually have a bunch of extensions to WinDBG in order to introspect dumps (and while debugging). So you can absolutely have interactivity and introspection with programs even if you are working with native code.

17:17 that machine, yeah I did work on that when I started working in the early 90s, they were phased out within a year for faxes.