Mentioning LessWrong and 4chan in the same breath made me chuckle, but it's actually a good summary of the modern Internet: to be ad-free, you need to either care very much, or simply not care at all. The middle of the road has been bought, fenced, and you need to pay (with money or attention) to access it.

As an Emacs user, I can testify that it's a game-changer. Codex CLI paired with `emacs --batch` is perfectly capable of setting up, developing, and testing just about any kind of extension you'd want. And with packages integrating LLMs into Emacs, you don't even need an external harness - open a buffer, type a prompt, get a useful extension or customization. It really works quite well.

But I stand by my opinion: Emacs is just one piece of software, not completely unknown, but rather niche, all things considered. Almost no other app supports seamless extensibility at Emacs' level (not even web browsers come close, and not by accident - it was a conscious decision to drastically limit what plugins can do).

Most programmers don't feel the need to make their apps easily and deeply extensible. Most users don't feel the need to extend their apps - even simple customization is rare. Most product owners don't want users to have "too much" freedom to change things.

So, while LLMs do give us a realistic path towards making extensible/malleable software attractive to users, almost nobody is taking that path right now. Realizing LLMs' potential in this area requires large parts of both the user and developer populations to recognize the possibilities and then actively pursue them for a few years. For now, it doesn't look like anything like that is happening.

Possible, yes. Reasonable to assume? I don't think so.

The issue is that we had that for a decade or two already: people who lived through the era will tell you more, but Smalltalk environments and Lisp Machines already realized this "malleability" to the extreme and... died. We got DOS instead; the rest is (a pretty shameful) history.

Emacs is just about the only artifact (along with Squeak-derived Smalltalk-likes) of the era that still exists and is in popular use. The PC revolution killed interactive, vertically integrated, fully programmable environments. It happened because of hardware limitations of the time, but the consequences are cultural: the LispMachine-like environment simply faded from the collective imagination of programmers who learned programming by writing "resident programs" for DOS in assembly. It didn't happen immediately: DOS was sufficiently open for modification that (if you knew x86 assembly) you could mold it to your preferences, but the hardware wasn't powerful enough to do much with it. As hardware advanced, PC OSes ossified, adding abstraction level after level in both hardware and software. Early Windows was trivial to dissect - I remember WindowBlinds, a set of apps that transformed Win 95/98 into almost anything you wanted. I recently checked, and nothing like that is possible in the recent Windows versions. GNOME on Linux seems to have followed the same trajectory (fortunately, there are still a few other desktop environments there).

So I don't think the "malleable software" is going to return any time soon. We have not only rigid software everywhere - we have 30 years of shared culture of developing and using such rigid tools. With the size of the programmer population, changing that culture in any meaningful way seems very hard. There will be people who rediscover Lisp Machine ideas, there will be a segment of users swearing by Emacs and similar apps, but we'd need a revolution in corporate and educational policies to get anywhere beyond that, I think.

[1] https://arxiv.org/abs/2503.23303

Given another commenter's mention of a similar project written in Nim that yielded a 1.6 MB binary, my first guess is that the 6 MB Zig binary simply isn't optimized for size - it might be a debug build. If not that, then I'm not sure what's happening, but yeah, in the context of Zig, 6mb for a CLI app is a bit strange.

To your point on installation: sure, but if you value it that much, just pay Valve to add you to the Steam store? And that would be the only possible solution given my constraints, all explicitly mentioned at least once in the linked conversation:

   - binary produced today works
   - without changes
   - on both Linux and Windows
   - is a GUI app
   - has some dependencies
   - is developed on Linux (no Windows needed)

For other constraints, it's a solution. Worth considering. That's all.

The full discussion about this I had with ChatGPT is here: https://klibert.pl/statics/Steam-Linux-Runtime-Stack-2026-08...

However, Steam Runtime for Linux was still in beta, last I checked. Plus, it doesn't solve the cross-platform part. But for Linux-native development, Steam Runtime might be what's needed to have long-term compatibility for apps (finally).

It works. It works great. It's actually the only sensible solution if you want something compiled today to work without changes on both Windows and Linux in 10 years.

I did an experiment, implementing a GUI calculator, and Rust + Slint + cross-compiling to Windows (I develop on Linux) + Proton runtime was the clear winner:

    - compiled bundle: 20 MB (F#/dotNet + Avalonia: 207 MB)
    - loc: ~1000 (dotNet: ~700)
    - dlls: none other than what Wine provides (dotNet: 67 .dll files)

Another option I considered was Zig with the Win32 API, but the LOC count was unacceptably high.

I'm working on a write-up for the experiment. The premise was: "I'm working on Linux and want to create a GUI app that will, with the build done today, continue working on Windows and Linux for the next 10 years". Steam/Proton + mostly static compilation + bundled libraries is the only solution that makes this mostly painless.

I try to use LLMs for Kotlin, Python, Emacs Lisp, and Smalltalk (among many others, but these are what I have ongoing projects in). You'd think that Kotlin and Python would be much easier to generate than the other two, right? But that's not what I observed: Elisp is very close to Python in terms of how fast and how many tokens it takes to generate the code! The generated Elisp code is often better on the first try than generated Kotlin code for a comparable task.

Smalltalk is... complex. It's meant to be developed interactively in a running image, but running Codex on API pricing is too expensive, and Codex CLI cannot interact with the image without a lot of plumbing. I ended up building multiple tools that live in the image and a protocol for calling them, and a set of skills for using them - including code search, docs search, test runner, and script/string evaluator. I also defined a way of annotating types for method arguments and return values (without having a type checker), which helped a lot. Still, it's an uphill battle; I wouldn't go there on API pricing!

My takeaway is that it's not obvious which language fits the LLMs and a given task best.

Agreed. To me, full-program (or system) formal verification is something I'd love to have, but I also acknowledge that even champions of formal methods (like Tony Hoare you mentioned) doubt its practicality, due to how large our software systems tend to be nowadays. If so, then let's take as much as we can from those methods (powerful, expressive type systems) and let's complement that with proper infrastructure for ensuring correctness (contracts, invariants, various kinds of automated tests) that are weaker, but much more applicable in practice.

Unfortunately, we're still stuck in a place where a plain `assert` - basically a "goto of ensuring correctness" - needs to be introduced to people with posts like the OP's...

> To me this is the need of the hour and yet i don't see people talking about it

Yes, I feel the same. I think the reason here is that we (programmers, collectively) didn't really take correctness of our programs seriously before, so there's just not much awareness about the research and work done in this problem space. Many people now are ready to admit that yes, we do need stronger, more comprehensive and better integrated tools for controlling, showing, and ensuring correctness - but the need for them arrived so quickly (and along with so many other, serious changes to the craft), that they simply haven't been able to catch up on the prior work fast enough. It'll probably take a few years, at least, for the urgent need for better tools to become widely recognized. It'll take even more time to get to usable implementations.

> (gradual typing is whole another beast altogether)

It's actually not. Contracts in Racket are duals of types (well, not fully, since you can put arbitrary code in a predicate and make that into a contract; however, that's more of an escape hatch than the default use of contracts in Racket). Typed Racket can wrap a typed value in a contract that guarantees that, when the value comes back, it exactly conforms to its type. This way, you can avoid expensive casts. Moreover, Typed Racket has refinement types (ie. that a given int will always be greater than 0), and these refinements have direct contract equivalents, too. So a Typed Racket value can be statically proven to have that property on the typed side, and then you don't have to check or prove it again when it comes back from the untyped world.

I believe this is an extremely neat capability that ties types and contracts together, opening some very interesting possibilities. Like, if a contract can be expressed as a refinement on a type, and we already have support for that in the type checker, we can automatically promote such contracts into types! That's huge, because if the contracted value never leaves a well-typed environment, we can eliminate all runtime checks without affecting correctness. It also addresses the most common problem with contracts (and assertions): runtime overhead.

I'm aware of all that because I decided to build an environment that would blend a fast, interactive development loop, an isolated environment in which agents can comfortably live, and an expansive toolkit for checking and ensuring correctness. I'm building it on top of Pharo Smalltalk, Glamorous Toolkit, and an extended Gradualtalk implementation that would also handle contracts. There are some problematic parts, but if I manage to achieve my goals in a Smalltalk image, I feel like it'll prove it can be achieved in literally every other environment, too :)

EDIT: Forgot to mention, there's a pretty extensive list of papers on contracts and gradual typing here: https://samth.github.io/gradual-typing-bib

EDIT: "Types to contracts" is already presented in papers I referenced before (Typed Racket ones); forgot to mention the "contracts to types" (or rather, static verification of contracts) part: "Soft Contract Verification for Higher-Order Stateful Programs" and "Soft Contract Verification" by Phuc C. Nguyen et al.

It's not. The latest-and-greatest models on $200/mo subscriptions routinely produce bloated code full of boilerplate. They are incapable of producing elegant, concise, readable, correct-by-design code - they literally can't do it, even with the smallest samples, and it gets much worse as the scale of the implementation increases. You can't will the capability into them through prompts. You probably could do so with fine-tuning or other techniques, but I suspect that would just make the variance higher - and the average code quality would be much lower than it already is.

The code generated by LLMs is passable, but never truly good. The same is true for LLM-generated designs and architectures, just even more so. They are trained on all the code out there, and the percentage of really good code is so vanishingly small that it's incredibly hard to replicate even for humans after a lifetime of learning. LLMs would need to reach a next level of capability to consistently recognize good code. Generating it consistently is out of the question for at least the next few generations of the AI.

Not all code has to, or needs to, be good. LLM-generated code is useful and helpful. It's an incredible time-saver for one-off scripts, and you can make an LLM implement and maintain parts of the program you need, but don't care to make good at the moment. LLMs are very efficient (if we ignore externalities) and easy-to-use code generators, which is huge in itself. However, they are not great or even good at generating code.

Last weekend, there was a post showcasing a Rust library with utility functions for writing parsers. It featured a simple line-by-line INI file parser. I decided to rewrite it in Python with PyParsing, a library I happen to know well. GPT-5.6-Sol High wrote the grammar that worked. It was tragically bloated, poorly factored, and multiple grammar problems were masked by parse actions. It worked, but it was decidedly bad code. I then rewrote the grammar by hand, getting it down to 1/3 of the length, eliminating all parse actions, and improving error messages in the process. I then spent 2 hours trying to convince the model to perform the same refactorings I did, but had to give up: no matter what I tried, the model couldn't get all the needed changes to coexist at the same time. When it got the terseness right, it inevitably ruined error handling. When it got the grammar right, it ruined the factoring. And so on.

Later on, I decided to make the model rewrite the PyParsing grammar in Smalltalk's PetitParser - a pretty close match in terms of capabilities. I gave the model my version of the grammar. I told it to translate that Python code. It still butchered more than half of it, doing "optimizations" (the model's words) that replaced a cached production with a literal + 3 message sends in 8 places in the (trivial!) grammar. I explained what I value in the original code, why those are important features to keep, and tried again. It still couldn't give me an idiomatic Smalltalk translation, though it did get significantly closer. I concluded that the model has a very limited understanding of how concepts I wanted can manifest in actual code and called it a day.

To give you an idea of the scale: excluding blank lines and imports, the grammar is exactly 10 lines of Python...

So no - LLMs are not good at generating code. They are just fast and convenient, and again - that's huge. But it's nowhere near a level where it can be steered to produce good code - much less being able to generate good code by default.

(I realize this post is a bit off topic and it's just an anecdote - but I've experienced this daily for the past half a year; I'm not basing my opinion on just that last attempt.)

YMMV, but OP, if you read this, please consider disabling the text-shadow for code snippets... or disabling syntax highlighting in code snippets. These two things are not a good thing together.

- Matthias Felleisen, Sam Tobin-Hochstadt, “Interlanguage Migration: From Scripts to Programs” (DLS 2006)

- Sam Tobin-Hochstadt, Matthias Felleisen, “The Design and Implementation of Typed Scheme” (POPL 2008)

- Sam Tobin-Hochstadt, “Typed Scheme: From Scripts to Programs” (2010).

- Asumu Takikawa et al., “Gradual Typing for First-Class Classes” (OOPSLA 2012)

- Esteban Allende, Johan Fabry, Éric Tanter, “Cast Insertion Strategies for Gradually-Typed Objects” (DLS 2013)

- Esteban Allende, Johan Fabry, Ronald Garcia, Éric Tanter, “Confined Gradual Typing” (OOPSLA 2014).

- Nadia Polikarpova, Ilinca Ciupa, Bertrand Meyer, “A Comparative Study of Programmer-Written and Automatically Inferred Contracts” (ISSTA 2009).

There's a lot more research and literature on the topic. Naive approaches were tried ~2010 and were shown to be performance disasters, but by ~2015 we already had those issues mostly solved. I seriously thought that every new language (or new release of an existing PL) after that would feature first-class support for contracts and gradual typing, along with built-in support for automatically generating/harvesting types and contracts from tests. It's 2026, and the mainstream still doesn't seem aware of the possibilities, much less actively going in that direction. It's nuts!

For some reason, DbC seems to be virtually unknown to most programmers. It's incredibly strange: I was sure that DbC would be the next big step after gradual typing. It's just such a natural fit: where the type system gives up (any/dynamic), the contract system can step in. There are papers on automatically generating contracts from types (and vice versa) to allow typed values to flow through untyped code; there are papers showing how to make that performant enough; papers showing how to instrument systems to generate types and contracts from tests; etc. They are all 15-20 years old now, yet there's still nothing suggesting that the mainstream even looks that way, much less actually implements something usable.