The title of the video, the premiss, the cover image… It's definitely not doing the best sales pitch here. I know it's not normally something I'd post here. Why post it then?
A bunch of my friends struggle with dating. What Adam's put together here is actually really great! Especially since he wrote an entire book and then just decided to give it away for free. It's unfortunately a Google Doc and I don't feel comfortable sharing a PDF version without his permission. Seriously though, check out How to survive dating in the 21st century. It's actually pretty great dating advice. Maybe not perfect, but a hell of a lot better than a lot of the advice grafters will try and sell you. Seriously, I'm posting this here so I can point my friends to go read it. Check it out!
This just sounds like rapid application development (RAD) again. (Everything old is new again.) Nothing against it, but it's been kind of funny watching the vibe coders essentially reinvent Visual Basic or Dreamweaver. Not a knock against either of those. It's just as you hear the argument go on, you get back to, "Why am I using a language at all?" Yeah, that's what RAD was all about. Then you have to ask, "Why isn't that the dominant way we program?" Could just be those older tools weren't as good as vibe coding is. From my experience though, it was because they suffered at scale, in stability, and labour shortage.
On the scale side, as the thing gets bigger and bigger, you need to actually understand and control what the computer's doing. I got my first job building and maintaining a Microsoft Access database. Very easy to click and drag a button or dropdown in, pick the table it loads from or add a bit of VBA for an element's event handlers. The problem is doing naive things like loading every record in the system into a dropdown element or doing a ten way join between tables to run reports. Not using transactions properly in batch operations and rollbacks. Trying to use a shared network drive as a client server protocol and then trying to manage serial write isolation by shouting down the hall. Add to that inexpertly and constantly trying to wrangle incompatible date parsing between machines by guessing and testing OS setting changes. You get the idea. All of these were solvable, but I didn't really understand everything I was doing. Looking back, there's really no way to fix all this stuff now that I do without a significant rewrite. They work great when you first build them and then fall apart a few years later when the system has thousands or millions of records.
The stability part stems from that. You've got someone building without really understanding what they're doing and the system's stability reflects it. I'd routinely leave work with the system not properly working. I'd ship a broken update a couple times while working on it. Lots of regressions. The business put up with it because I was making minimum wage and sunken cost fallacy makes cutting your losses hard. Now imagine a company like SAP or Oracle shows up with a tool that does roughly what your in-house solution was doing but has real robustness. It doesn't break every other day. It's expensive, but results in a lot more reliability for managing all the data your company has to deal with. You don't need an expert on the tool, you can just train staff who already handle more direct business value to work with this tool instead of your in-house thing. It's not as seamless or streamlined, but it's close enough and doesn't involve magic incantations by one person in the whole company able to fix it when things go wrong.
The labour shortage is an interesting one. We went through about a twenty year period where software developers were hard to come by. Businesses wanted more of them than we had in the economy. That meant learning to code could get you a really nice salary. Right now it looks like we're past that. There's now tens of thousands of unemployed programmers just in the United States of America. I left that job for a number of factors, but I'm not currently eager to go back to a minimum wage job managing an Access database right now. What does this mean? Not sure yet. Might even be unrelated. I left and then years later was brought back to quickly fix a report. I fixed it in about thirty minutes and billed an hour. Nobody's touched the system since I left. Nobody besides me understands how the thing works. They've all just learned to use it to do their job. With vibe coding, going back, I wouldn't have even understood it. Food for thought.
Both of the installations mentioned are actually pretty cool.
Still not a fan of how high-end physical art is basically valuable in so far as it facilitates tax evasion and money laundering. Still upset at all the assholes who used and continue to use the technology to destroy the lives of working class people. Still think fanatic techbros are something we as a society really need to address at some point. Still think buying a receipt for a link to a JPEG is absurd. Though I guess "certificates of authenticity" and the similar "deeds to real estate on the moon" have been with us for a while.
On the other hand, an extremely convoluted way to reopen those financial loopholes (as it would have to be) has provided a genuine window for high-end physical artists to make a lot of expensive art installations feasible for a little while without as many middlemen taking a cut. That's pretty cool. All the also-rans with ugly random character generators finally went home and now there's some space to appreciate the real work that's been going on.
I enjoy Python and JavaScript exactly because their most popular runtimes include a REPL and by extension, builtin debugger. That alone provides many of the live coding features he's talking about. They're not perfect, and TypeScript's running the other direction in the name of boxing people into VSCode, but those examples can help if you're unfamiliar with languages and runtimes from Clojure, Erlang, and Smalltalk.
But it's slow... The refrain I can hear many people saying is, but these languages are slow. No, the language is an abstract concept. You're confusing the runtime or build artifacts of a given compiler with the languages. To be fair, the talk also blurs the two for shorthand. Cpython is currently really slow. No debate from me there. PyPy is much faster. Nuitka is faster still. And Numba is likely faster than what you'd program in Rust or C++ and takes a fraction of the time to code. Idiomatic language use can also lead to slow code, but that's a skill issue.
No, the language runtime being slow isn't generally an issue. There are billion dollar companies running Python at scale in production. It just drives up the hardware costs and limits what you can do on a single machine for a reasonable price in a reasonable amount of time. A reasonably priced computer can still do an insane amount of compute though. Erlang programs run a large share of all the computers in the global telephone network. Many games grossing a million dollars or more have been built in Python, Lua, and GML. That said, why waste the compute unnecessarily? I'm constantly drawn to Jai, Zig, and Odin entirely because you shouldn't need a runtime penalty in a production environment.
What I'd really like is the ability to split production from development further when it comes to runtime. Build systems often already have debug and release builds. Zig even has the concepts of ReleaseSafe and ReleaseFast. If you then think about a concept like attaching to a running production system with your runtime, or the ability to both interpret and compile your language as truly first class primitives. Really design the language around iterative highly introspective systems with injectable runtime binding.
An ideal would be a zero cost development runtime. That is, you only pay the runtime cost when you attach to the program. You might object that production builds do a bunch of optimizations. Sure, but what's to say you can't hijack the control flow and feed it to an interpreter? Then you can run the source code that went into those optimized routines in a manner that provides full reflection, introspection, and manipulation. Even if a dozen functions have been inlined and fused, you could run an interpreted version of those by patching the landing sites. The environment would look exactly like you'd dropped a import pdb;pdb.set_trace() but it would be dynamically patching the optimized code paths to the interpreter. I'm sure it's way more complicated to get the optimization scoping right, but there's likely a reasonable tradeoff to scoping since optimizations usually need to bound their search space anyway to prevent combinatorial explosions.
Now we go a step further. You can iteratively program some of that code. Like incremental builds but without having to restart the process. Bring in some of that Bret Victor, hot dispatch looping. Add some of those automatic data structure visualizations by having more standard library data types with first class debugging visualizations. That's kind of what Python's __repr__() class methods were all about, but I've more often seen them abused in ways that make debugging harder by messing about hiding things for aesthetics sake instead of easier by gathering and presenting the rich inner workings of a given data structure.
The ability to essentially connect to your application like you're SSHing into it. Able to run individual functions through the live interpreter, to build them up in a editor and debug them live. The ability to address what Erlang would term processes, but which could be called threads, coroutines, or workers. Monitor their call graph, interrupt them with breakpoints, kill them, spawn new ones, or blue-green upgrade them in-place, all using the attached runtime harness. Almost like independent processes but with robust IPC.
Zig, Jai, and Go took a small step forward with their build system being able to quickly compile and run the program, but yeah, still not great at scale. Builds in very large projects can still take a while, especially as the number of generics expand. In these languages I haven't yet experienced full Rust or C++ level hour long build cycles, but they're still not instant. Not being able to attach to the compiled program, introspect and modify it is really limiting. I shouldn't be tempted to add print statements and restart the program. I should be able to start the program once when I sit down to work and then edit, debug, and evolve it while it's running. Not hot reloading, but proper multiprocess software development. That probably also means state snapshots and time travel debugging. I'm only usually working on a handful of codepaths at a time. The rest of the program should be running as a fully optimized build with only sections in this interpreted slow path.
If any of this sounds cool, check the talk. It's not a talk about what languages you should be using, it's a talk for language developers to really consider looking back at what cool things already exist. Making the case that if your language doesn't have these sorts of features, you're spending a lot of extra unnecessary time fiddling with all the work you have to do around the actual work.
This is exactly what I've been talking about when I say you need to practice more. This! This isn't just about drawing. It's about practicing your craft. Its about how you become great at anything. Programming, music, art, speaking Spanish, playing basketball, whatever. You just need to do it. The more you practice, the better you'll become.
The interenet has made measuring yourself, of getting bogged down in the meta, and endlessly distracting yourself with theories and critique, far too easy and fun. Stop sharpening your axe and just start cutting shit. Sure it'll be rough and ugly. That's how you get better. You cannot just think yourself better. You have to practice.
He's right on the money complaining that technology has held many people back. Too many people who decide they really want to learn a skill get distracted until they give up because the internet talks about all the technology they supposedly need. It creates this artificial impediment to actually doing the thing. They need a stylus hooked up to Photoshop with the right set of brushes, or need a MIDI keyboard hooked up to a DAW with the right set of VSTs, instead of things as cheap and easily obtainable as a pencil and some paper or a used guitar or keyboard. Heck a stick and some mud or a drum-able surface is all you need.
For programmers it's getting all wrapped up trying to download and use VSCode or trying to install Linux or whatever instead of opening a simple text editor and just hacking out a script to automate something or make a little webpage or game.
The best part about a pencil or an instrument is that the moment you start interacting with it, you start to create something. Something ugly and raw, your first time doing anything is going to be awful, but you quickly see the possibilities. It's real. You aren't faffing, you're failing, and failing is the first step to improving.
Sure, after you're practicing all the time, you can start to improve on the process. Use resources to learn new things to try. But I often tell people considering a gym membership to start by going for a walk every day. If you can't commit to a walk, be honest, you're not really going to commit to the gym. Same goes for practice. If you just start by watching lots of videos or buying some fancy gear or whatever, you're not likely to stick with it. You spent a bunch of time and money but you're still right where you started. You'll know how to talk the talk, even look the part, but you still can't walk. You won't be able to create anything of your own worth celebrating until you're regularly practicing.
So please, just start practicing. It's a much better use of your limited time on earth compared to spending it consuming things other people make. The things you've made will outlive you. The things you've consumed or only thought about die with you. Change only happens when we physically do things, create and build things. Not for others, but ourselves. Create things you enjoy. Share them if you like. But do it first and foremost for yourself because making things makes us happy.
I'm some goober typing words in a text editor and you're now reading them. That's the power of creation. And very rarely, someone like you might really enjoy that but we can't enjoy anything if you don't create something. Draw the pictures you want to see. Play the notes you want to hear. Make the videos you want to watch. Build the furniture you want to use. Write the works you want to read. Fabricate the cloths and accessories you want to wear. But start small, make it a habit, and create things because nobody can stop you.
I have no practical application for this knowledge, but it's one of those really cool obscure bits of Windows internals. Like knowing about alternative data streams in NTFS, or how you can't normally name files things like con, aux, or prn, because path resolution has devices like these globally available. Why? Because Windows has its roots in CP/M and takes backwards compatibility very seriously.
