There were 12 apostles of Jesus Christ. 1 betrayed him. 1 denied him. Thus the first church suffered corruption, as they do till this day. However, his blessed holy mother Mary never abandoned him. She knows the pain of every mother, more than you can ever imagine.

CC: @xah_lee

CC: @usereditable

CC: @ShriramKMurthi From the guy who wrote the Emacs-like in Chez Scheme.

If you prefer to watch on YouTube: piped.video/fn5itw2Yk-4

Project: github.com/paveluv/Schevana

Amazing talk by @odersky addressing similar claims.

Grok's summary of the video: **Summary of the ~15-minute rant** (your video from the post “It’s become fashionable to say: ‘coding is solved’… My rant”): The core argument is that claims like “coding is solved,” “we don’t need to care about source code anymore,” or “agents can just generate machine code from English” are shortsighted. Those views work for routine, well-understood tasks (simple web pages, CRUD apps, line-of-business software you’ve built many times). For those, you can often ignore the code. But they fall apart at the frontier—when you’re modeling genuinely new domains or working at the edge of what’s known (e.g., plasma behavior in a tokamak). There, high-information-density formal notations (programming languages and mathematics) remain essential. Key points you develop: - **Communication and modeling require formal languages.** Programs and mathematics exist to express advanced ideas precisely so they can be shared with other humans *and* with computers. English is too loose and low-density for the most sophisticated thoughts. As long as we want to communicate (human-to-human, human-to-agent, or agent-to-human) and steer novel work, these languages matter. Formal languages will become *more* important, not less, for humanity’s hardest problems. - **Think bigger than “just make it fast.”** Examples cited include DHH showing Rust rewrites that are much faster but hard to understand, and talk of generating assembly or machine code directly from English (including remarks attributed to Elon). The right standard is higher: generate code that is both extremely high-performance (top of benchmarks, robust, efficient) *and* written in a literate, humane, Knuth-like style that a trained engineer can actually understand and navigate. There should be no forced tradeoff between performance and understandability. Early web “view source” was magical precisely because a lot of it was hand-written and relatively inspectable; we need that level of transparency again (and better). - **The holy grail of programming languages is still unsolved.** We still lack a language that is highly expressive and abstract (no unnecessary manual memory management, borrow-checking, etc.) while matching the performance of hand-tuned assembly. Until agents can reliably produce code that is both fast *and* clearly understandable, coding is not “solved.” Agents should be directed to write as if they were Donald Knuth, or a graduate student of Sussman and Abelson, etc.—imitating high literary standards of code. - **Lean-style mathematical proofs illustrate the same problem.** Agents/Lean can produce proofs that the kernel accepts as correct, yet world-class mathematicians say they cannot understand the routes, techniques, or presentation. The demand should be: produce a correct proof *and* write it in a navigable, humane style (e.g., “as if you were John Nash”) so a trained person can follow it. Offer scaffolding, tutorials, or knowledge checks if the user needs to build up to it. One “bill of rights” for users of agents is that anything produced must be understandable and inspectable by a suitably trained human. - **Always prefer inspectable, elegant formal representations.** Even for simpler programs, if the tools exist, agents should produce understandable source. Most people will interact via the UI, but there are times you need to see the underlying equations or model. Inspecting the formal version also serves as a diagnostic: a small English request that balloons code size (or a language spec that stays bloated) is a signal something is wrong. Agents should help compress and refine designs toward elegance. Clearer formal notation helps humans *and* makes the artifact easier for agents to reason about. Efficiency (speed, energy) and understandability reinforce each other. - **Code as literature / beauty.** The body of source code should meet a high standard of beauty and humaneness, analogous to Steve Jobs insisting the internal PC boards be aesthetically excellent even if almost no one sees them. (You linked the folklore.org piece on this in a follow-up.) Every program should be written so it can be inspected, understood, and modified by people who know the domain and language. You note that we’re not there yet on agents imitating high literary coding styles or eliminating the expressiveness/performance tradeoff, and that the people claiming “it’s solved” likely haven’t been operating at the frontier where formal notation is indispensable. The video is a spoken monologue (selfie-style) that circles back to these ideas several times, which is why a condensed version works well for sharing. The main thrust is consistent: demand that agents serve human understanding and high standards, not just raw generation of working (or fast) code. Formal languages and readable source remain central tools for thinking and collaborating at the highest levels.

Steve Jobs on PC boards looking beautiful. Code should be beautiful and understandable, even if 99% of the users don't look at it. folklore.org/PC_Board_Esthet…

Major influence on the design and implementation comes from legmacs by @MGasperowicz and E by @PavelUvarov They showed that small and innovative emacs-like editors are practical! github.com/nooga/legmacs github.com/paveluv/e