💾 Archived View for thrig.me › blog › 2022 › 10 › 18 › stop-writing-dead-programs.gmi captured on 2024-07-09 at 00:53:41. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-14)
-=-=-=-=-=-=-
Apparently there is a video titled "Stop Writing Dead Programs" that I was able to find a transcript for and clean it up (with some Perl) into a somewhat readable form.
TL;DR I mostly disagree with the author.
"Hella long feedback loops."
All my code compiles mighty quick (and that was on the 2009 macbook with a spinny metal disk), especially when the problem has been boiled down to a minimal test case, if we want to trade anecdotes.
"But how many of you guys have compile cycles that can take 45 minutes?"
This could be made better with caching, isolating new code into a very small test case, etc. C++ does sound like a special sort of trainwreck, exactly the sort of thing someone would cherrypick to make their "compile/run cycles bad!!" argument look good.
"We're all running web apps now"
No?
"stuff it in a Docker container"
No?
"and then ship it out to the cloud"
No?
I could support a "most" here but "all" is plain wrong. Maybe if there were a document that one edited (the compile phase) then critiqued (the run phase) this sort of trivial bug might get worked out.
"Docker shouldn't exist"
Well, yes, but in that universe odds are that someone would invent Docker' and then... maybe there is some multiverse somewhere where LISP and live coding thing isn't some marginal thing, who knows.
Could it be that live coding just don't suit some folks? Possibly most folks? Nevermind! Put on your blinkers, we're going to the stars!! And you should be ashamed, ashamed I say if you don't dittohead and follow!!!
Yeah...
"that your program is going to start up from a blank State and then run to termination. Now, how many programs that we actually write do that?"
Most of mine do exactly that.
"sorry, failures just halt your progam"
This is a feature when there's a security problem, and in other cases. For example, when an attacker attempts a stack pivot, do you allow that, or kill the process? Or, when a process goes out of control, do you let it rack up a huge cloud bill, or kill it?
"What kind of programs do we really write? Mostly long-lived servers. I've got server processes with uptimes of a thousand days"
High uptime wang-waving generally indicates that security patches and firmware updates are not getting applied. Also how do you know it's going to start up correctly if the last guy who started it retired five years ago? Well, it was amusing when that never rebooted always works Bank Mainframe did fall over.
"how many of you use an editor that has vi key bindings?"
This vi has vi keybindings. And guess what! This vi is going to be terminated when I'm through with this document.
"Instead, all of your program state is still there while you're working on it."
And the bugs, and the lord knows what else state I've forgotten about that is busy backstabbing me. No, thanks!
And let's not assume that the live coding even works, or that you have time to get it working, if it can be made to work. Consider:
< seletz> What lisp are you using? I'm trying to get my grip on common lisp
< thrig> SBCL
< seletz> I ask because i had problems using SBCL on mac within emacs -- cl-glfw3 examples would freeze the lisp inferior. It runs on command line, though. I've read some hints on swank multi-threading issues in the CEPL repo which I'm about to try out.
< thrig> I'm not using emacs
< seletz> Well then :)
Never did hear whether they got it working, or not.
"This means you can debug"
I can also debug without a live programming environment complicating matters.
Also, even with the vaunted live coding environment a problem still might be dead, as a transaction or web request or bluetooth pairing could have vanished by the time the on-call engages (after one hour of bad sleep at 2AM in the morning--good luck with that debugging). Possibly you might keep all such requests around but even then what you record may not be enough to debug whatever went wrong, and on linux the OOM killer is doubtless looking to kill due to all that memory use. Programmers also excel at filling up the disk, if you want to stash all that state for potential future debugging not in memory. Ask me how I know.
"All software is continuous change."
I'd argue that most software does not change most of the time, and that the "continuous" is, like, totally wrong. The change, if it happens, is more of a punctuated equilibrium. I would agree that computer scientists suck at naming things.
"The spec today is not the spec tomorrow"
Trivial to disprove by finding any number of specs that have not changed in a good long while now. Maybe step off the web hamster wheel for a change? Or, what if the specification was designed not to be changed? Can you find an example of that?
"So, for example, in a dead coding language, I will have to run a separate debugger, load in the program, and run it ..."
No, you won't. You can add print statements or other such logging, or can write a minimal test case to prove some point or the other, use process tracing such as strace or sysdig, etc, etc etc. You can also sit on your hands and think about the problem. This is deeply unpopular, and does not sell shiny toys to programmers with tunnel vision. I have used GDB in production, but that is very rare; most often there are better tools to debug problems in production. Like, do you attach your live coding environment debugger to the political layer, how? Or where is the live coding debugger for the load balancer, the DNS, the router that someone setup two years ago and forgot about?
And there are good reasons to not allow a live coding environment in production; security and regulatory compliance come to mind, or, I don't know, cowboy programmers having a poke. "Oops! I didn't realize I was in production!" Heard that too many times; if your shiny toy is creating work for me then obviously I'm going to be opposed to it. Especially when some rockstar diddles production then wanders off on their big ski trip.
Oh, and is the live coding environment actually documented, so an on-call can triage an issue at 2AM in the morning after an hour a bad sleep? Or would a documented dashboard be better to spend time? If you can afford to page the programmers into production for every issue, sure, let them use their live coding or whatever (provided it is not a security or regulatory disaster). Otherwise, there might be better ways to maintain production systems.
"and they're rushing forward into the future and we should follow them"
A cliff? What could that be?
I can think of plenty of rushes that shouldn't be blindly followed (land wars in Asia come to mind) and plenty more that went nowhere. Remember that whole Atonality thing in music? Can you think of any examples?
tags #lisp