LLMs and the 'Best' Programming Language

HostThe voices in this episode are synthetic, and the script was written by a language model. The positions are real, and they come from the thread.

HostToday, we're diving into a lively debate that unfolded on Hacker News, spanning over three hundred and eighty comments. It all started with an article on vivienhenz.com, which boldly claimed that Common Lisp is now the best programming language, especially when you're working with LLM-assisted development.

HostThe article argued that LLMs shift the development bottleneck from writing code to verification and rebuild time, and that Common Lisp's unique features like image-based development, interactive debugger, and powerful macros make it uniquely suited for rapid iteration and creating concise, user-customizable code.

HostThe thread quickly split into several camps: some passionately championed Lisp's unique strengths, others insisted on the superiority of strong static typing, and a significant portion simply rejected the premise that any single 'best' language exists. It wasn't long before many comments devolved into advocating for their own preferred languages.

Common lisp enthusiastLook, the article's got a point. Common Lisp's image-based development and a live REPL allow for hot-reloading and immediate feedback. That's crucial for LLM iteration speed and a seamless development workflow, you know? It's just so much faster to test and verify.

No best language realistI don't think any language is the best 'because LLMs.' The concept of a 'best' language is a fallacy; different languages excel in different domains, and LLMs don't alter that fundamental truth. Many languages offer similar benefits to Common Lisp, so it's not uniquely superior.

Static typing championBut what about correctness? Compilers with strong type systems, like Rust or Go, provide excellent, unambiguous feedback to LLMs. That guides them to correct solutions and really reduces errors. It's about building reliable systems, not just iterating fast.

Common lisp enthusiastCommon Lisp's debugger is incredibly powerful. You can fix errors and resume execution from the exact point of failure without restarting the program. That's a huge advantage for LLMs to iterate on fixes, letting them learn and adapt in real-time.

Static typing championI'd rather my language surface problems at compile time via type errors for all possible code paths, rather than waiting for a particular codepath at runtime. Static types act as implicit documentation and a form of 'unit tests' that prevent many common LLM errors and reduce hallucinations by enforcing correctness.

No best language realistThe article's core premise, that 'writing code used to be the slow part,' is often false. Thinking, design, and understanding requirements are the real bottlenecks, which LLMs don't solve. They just make the coding part faster, not necessarily better.

Common lisp enthusiastBut macros! They enable creating domain-specific languages that make code more concise and expressive. That reduces token count for LLMs and allows for higher-level reasoning. I've seen a big improvement in LLMs writing macros since Opus 5.5 came out.

Static typing championLess code, or fewer tokens, isn't the primary driver of LLM efficiency. Architectural design and strong interfaces have a greater impact on token use and code quality. LLMs are surprisingly adept at handling the syntax and complexities of strongly typed languages like Rust and C++, making them effective tools for these languages.

No best language realistAnd the argument that 'less code means fewer tokens' is oversimplified. The design of architecture and expressiveness of code have a greater impact on token efficiency than language conciseness alone. It's not just about the raw number of characters.

Static typing championExactly. Strong types are disproportionately valuable in LLM coding versus human coding because they essentially function as context, and the type checker actively enforces correctness. That's a huge benefit for LLMs, especially in larger codebases.

Common lisp enthusiastCommon Lisp is also strongly typed, and its type system can be leveraged for static analysis or extended with more advanced type systems like Coalton. It's not just about dynamic flexibility.

Static typing championWhile Lisp has types, it's not the same as a compiler that provides the kind of rigorous feedback you get from Rust's borrow checker, for instance. Rust is excellent because the LLM gets great feedback from the compiler due to its strong type system, and it can even deal with the borrow checker for you.

No best language realistLLMs aren't fundamentally different from humans in their reasoning. Things humans find hard or unproductive can also be hard for AI, just faster. So if a language is difficult for a human to reason about, it's likely still a challenge for an LLM, even if it processes it quicker.

Common lisp enthusiastBut what about the ecosystem? The perceived lack of a large library ecosystem in Lisp isn't a problem anymore. LLMs can generate or port necessary libraries, making the language self-sufficient. It's a game-changer.

Static typing championThat's a bold claim. While LLMs can help, relying on them to generate or port entire library ecosystems seems inefficient and prone to errors. Languages like Go, Java, or Kotlin already offer fast runtimes, rich ecosystems, and good observability, making them strong candidates for LLM-driven development without that overhead.

Static typing championOpinionated languages with standard tooling, formatting, and project layouts, like Go and Rust, are also easier for LLMs to work with consistently. That reduces the need for extensive prompting on style and structure, letting the LLM focus on the logic.

Common lisp enthusiastLisp has a long history of active development and is used in critical systems, demonstrating its long-term viability and robustness. Hacker News itself runs on Common Lisp, which is a pretty strong real-world example.

No best language realistSure, but iPython and Jupyter notebooks demonstrate REPL-like interactive development in Python, and Smalltalk or Erlang also offer dynamic features and hot-reloading. Common Lisp isn't alone in these capabilities, and those other languages have massive communities and libraries.

Static typing championAnd for debugging, C# and Visual Studio offer advanced features like edit-and-continue, which challenges Common Lisp's claim of uniqueness in that area. The tooling in modern statically typed environments is incredibly sophisticated.

Common lisp enthusiastClojure, a Lisp dialect, gets excellent results with LLMs. Its functional orientation reduces bloat, and its REPL is fantastic for fast testing and verification. It's a testament to the Lisp philosophy.

Static typing championScala is another example where LLMs perform better despite less training data, precisely because of its strong type system. The safety and correctness guarantees of static typing are more important than dynamic flexibility, especially for large codebases or critical systems.

Static typing championLLMs need a language that has opinions about how to write standard code, has predictable strong types, and has an integrated toolchain. That's where languages like Go and Rust really shine for LLM-assisted development.

HostBeyond the main arguments, a few less common views surfaced. One commenter suggested the article itself was AI-generated 'slop' and contained hidden links to adult material, which certainly undermined its credibility for some.

HostThere was also skepticism about the idea that software companies would let users change products themselves using LLMs, blurring the line between configuration and product forking, with few real-world precedents outside of scripting or data visualization.

No best language realistThat's a speculative idea. The article's logical starting point, 'If some languages are better than others, one must be the best,' is flawed, as a partial ordering doesn't guarantee a maximum element. It's a false premise.

HostUltimately, the discussion on Hacker News didn't land on a single 'best' language for LLM-assisted development. While Common Lisp's proponents highlighted its interactive nature and metaprogramming capabilities, the static typing camp emphasized the importance of compiler feedback and correctness for LLMs.

HostThe prevailing sentiment was that the choice remains highly contextual, dependent on specific project requirements and developer familiarity. The thread never quite resolved whether LLMs fundamentally change the criteria for language choice, or simply accelerate existing development paradigms.

HostSloppod out.

HostSloppod is sponsored by Taskpile.app.

The same, as plain text