--- title: Abstract Heresies: Why vibe code in Lisp? | daily.dev description: An experienced Common Lisp programmer argues for using Lisp as the target language for AI-assisted (vibe) coding rather than mainstream languages like Python,... canonical: https://daily.dev/posts/abstract-heresies-why-vibe-code-in-lisp--o2rhku1pd twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Abstract Heresies: Why vibe code in Lisp? | daily.dev og:description: An experienced Common Lisp programmer argues for using Lisp as the target language for AI-assisted (vibe) coding rather than mainstream languages like Python,... og:url: https://daily.dev/posts/abstract-heresies-why-vibe-code-in-lisp--o2rhku1pd og:image: https://api.daily.dev/og/posts/o2RhKu1pd.png og:image:alt: Abstract Heresies: Why vibe code in Lisp? og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Abstract Heresies: Why vibe code in Lisp? **[Hacker News](https://daily.dev/sources/hn)** · 4 min read · 0 upvotes · 0 comments ## Summary An experienced Common Lisp programmer argues for using Lisp as the target language for AI-assisted (vibe) coding rather than mainstream languages like Python, TypeScript, or Java. The reasoning centers on Lisp's homoiconicity making it easier for LLMs to generate pure AST structure instead of fighting surface syntax, its macro system acting as context compression to save tokens, the REPL enabling live introspection and interactive debugging without full restarts, and its condition system offering superior error handling. The author frames Lisp as a tool for elite hackers rather than a language chosen for popularity or ease of hiring. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why would someone use Common Lisp instead of Python for AI-assisted vibe coding? Lisp's homoiconicity means code is structured as the data it manipulates, so an LLM predicts pure AST structure rather than surface syntax like brackets, semicolons, and whitespace. Its macro system compresses boilerplate to save context tokens, and REPL-based development lets a model redefine functions and inspect live state without restarting the program, unlike compiled mainstream languages. _Developers weighing language choices for AI-assisted coding can track emerging vibe coding practices on daily.dev._ ### How does developing in a Lisp REPL change the debugging workflow when AI writes buggy code? Errors are caught by the condition system instead of causing a hard crash, so the model can analyze the stack trace and debug interactively at the point of failure. There's no need to restart the program from scratch (ab initio); a single function can be redefined and tested immediately while the rest of the application's state stays intact. _Anyone iterating on AI-generated code follows workflow tricks like these through daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 135 comments across hackernews, lobsters (as of 2026-08-13). **TL;DR:** Most of the reaction fixates on the post's framing of Lisp as an 'elite' language, sparking a long tangent about whether that framing is arrogant or fair, while a smaller but substantive thread debates whether Lisp actually helps or hurts LLM code generation in practice. **Sentiment:** 20% positive · 30% mixed · 50% skeptical **The case for** - Some longtime Lisp users report LLMs write reasonably dense, workable Common Lisp/Clojure once prompted well, especially with tools that auto-repair mismatched parens. - A few argue Lisp's small, regular syntax and REPL-driven feedback loop let agents verify code quickly and use tokens efficiently. - Several people say frontier models no longer confuse Lisp dialects or struggle with parens the way they used to. **The pushback** - Many commenters were put off by the post's self-description of Lisp (and its users) as 'elite,' calling it cringe, elitist, or historically harmful mythology. - Several argue LLMs generate left-to-right and are trained mostly on verbose, repetitive patterns, making them poorly suited to Lisp's deeply nested, compressed style. - Multiple people report persistent paren-matching/closing errors from LLMs on Lisp-family languages, requiring extra tooling to repair. - One detailed rebuttal argues LLMs behave like 'StackOverflow users' optimized for common, verbose patterns, which is the opposite of what makes Lisp valuable, so the post's premise may be backwards. - Some note Common Lisp's real-world ecosystem/library support is thin compared to mainstream languages, undercutting practical adoption for vibe coding. **By community** - hackernews (heated): A long, contentious argument over the 'elite' framing dominates, alongside a genuinely split technical debate on whether Lisp's syntax helps or hinders LLM code generation. - lobsters (mixed): No comments were available to characterize the discussion. **Hottest debate:** Whether Lisp's homoiconic, deeply-nested syntax actually helps LLMs produce cleaner code (via AST-like reasoning and token efficiency) or instead hurts them (via left-to-right generation and frequent paren-matching errors). **Open questions** - Do frontier models truly reason about Lisp's AST/s-expression structure, or are they just pattern-matching on training data without any special structural advantage? - Can tooling fully solve the paren-mismatch problem, or does it just paper over a deeper mismatch between how LLMs generate text and Lisp's nested syntax? - Would an LLM asked to write idiomatic macros actually choose to compress code that way, or does it default to verbose, macro-free code unless heavily prompted? **Highlights** > My gut feeling is, this post is 180° wrong. LLMs are the exact opposite of "elite coders", they're perfect StackOverflow users: * they memorize adapt and write back small-scale patterns very efficiently; * they know widespread libraries inside out, and can learn others in minutes, even if their doc sucks; * they often produce good results, because most of the time we write unoriginal code, which paraphrases something it already has dozens of versions of in their training corpus; * but they're bad at seeing meaningful, non-obvious, simplifying abstractions, we really have to spoon-feed those to them; * they _love_ verbosity, that's literally how they "think"; * they also love repetition: the other term for "repetition" is "patterns", and they're basically excellent pattern matchers. So, Lisp is enjoyable for your typical LLM-complementary hacker, but not for LLMs. LLMs typically replace the kind of "non-elite" developers who hated Lisp, for remarkably similar reasons. What I'd love would be an LLM trained to faithfully rephrase a "normal" program into Lisp-ish pseudo-code, that would make reviews faster, more reliable, more enjoyable. But hand-written code is going the way of hand-written machine code; let LLMs have what suits them best, and higher level tools for the more abstract jobs where we're still relevant, and that would be various forms of code reviews. As for calling "elite" the kind of developer won't understand that development is a team sports, and that the proper tool is the one that fits the team, not their own peculiar quirks, I'm not going to address that, it isn't the keystone of his argument; but a lot could and should be said about that too. > — [fab13n on hackernews · 1 comments](https://news.ycombinator.com/item?id=49283394) > The counterweight is that Lisp syntax is tiny and regular, the language is concise, and it encourages the composition of small pure functions. There's very little context to get confused about; the code can be reasoned about locally. Then verified in the live REPL, which gives the agent much tighter feedback loops. So in practice, Lisp uses tokens very efficiently and tends to get things right, fast. The syntax just is not an issue one has to worry about (and your harness should be checking your model on this btw) > — [perrygeo on hackernews · 1 comments](https://news.ycombinator.com/item?id=49285021) > I have a hunch (based on using the Kimi models to write some clojure) that the article's AST point is exactly wrong. I had to spend a lot of time cleaning up when it miscounted closing parens, which implies that while the LLM may be operating on the AST, mapping to and from the token stream is harder, not easier, when the individual tokens carry less information. If the author is finding that it works well, I suspect there's something else (code or comment style, maybe) that's compensating for it which didn't seem worth mentioning. > — [regularfry on hackernews · 3 comments](https://news.ycombinator.com/item?id=49283075) > It seems to happen a lot with Lisp enthusiasts for some reason, usually without any evidence to back it up. It always makes me laugh because the real world runs on C/C++, not Lisp. So perhaps by “elite” they mean something other than being successful in the real world? Maybe they think they “get it” while everyone else doesn’t, which somehow makes them “elite”? A bit like conspiracy theorists who think they’re among the few smart enough to know the “truth.” Not sure. > — [deterministic on hackernews](https://news.ycombinator.com/item?id=49281773) > I'm into Lisp because Lisp languages are easy to work in. I advocate the family as being good for nonprogrammers. Small children should learn some kind of Lisp, and easily can. Richard Stallman famously shared an anecdote in the article "My Lisp Experiences and the Development of GNU Emacs" (https://www.gnu.org/gnu/rms-lisp.en.html) about the secretaries: > The editor itself was written entirely in Lisp. Multics Emacs proved to be a great success—programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program. People, whether inside or outside of Lisp, who spread myths that that it is some scary, esoteric elite family of languages, have been pretty harmful. > — [kazinator on hackernews · 2 comments](https://news.ycombinator.com/item?id=49280560) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49269429) · 134 points · 134 comments - [lobsters](https://lobste.rs/s/tkzdj2/why_vibe_code_lisp) · 4 points · 1 comments ## Similar posts on daily.dev - [If You’re Going to Vibe Code, Why Not Do It in C?](https://daily.dev/posts/if-you-re-going-to-vibe-code-why-not-do-it-in-c--j9qbgvhqz) · Hacker News · 1 upvotes · 0 comments - [Linus may vibe code, but that doesn't make it best practice](https://daily.dev/posts/linus-may-vibe-code-but-that-doesn-t-make-it-best-practice-h6mp947gd) · The Register · 1 upvotes · 0 comments - [Haskell for all: My experience with vibe coding](https://daily.dev/posts/haskell-for-all-my-experience-with-vibe-coding-akml65ddg) · Planet Haskell · 0 upvotes · 0 comments - [Vibe Coding: How AI Quietly Rewired the Way Software Gets Built](https://daily.dev/posts/vibe-coding-how-ai-quietly-rewired-the-way-software-gets-built-ffgj6qndq) · Medium · 1 upvotes · 0 comments - [What is vibe coding? AI writes the code so developers can think big](https://daily.dev/posts/what-is-vibe-coding-ai-writes-the-code-so-developers-can-think-big-vepiaw7sc) · InfoWorld · 0 upvotes · 0 comments --- Tags: [#vibe-coding](https://daily.dev/tags/vibe-coding), [#lisp](https://daily.dev/tags/lisp) [View this post on daily.dev](https://daily.dev/posts/abstract-heresies-why-vibe-code-in-lisp--o2rhku1pd) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Abstract Heresies: Why vibe code in Lisp?","url":"https://daily.dev/posts/abstract-heresies-why-vibe-code-in-lisp--o2rhku1pd","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/abstract-heresies-why-vibe-code-in-lisp--o2rhku1pd"},"datePublished":"2026-08-13T00:13:43.696Z","dateModified":"2026-08-13T20:40:54.891Z","description":"An experienced Common Lisp programmer argues for using Lisp as the target language for AI-assisted (vibe) coding rather than mainstream languages like Python,...","image":"https://media.daily.dev/image/upload/s--0_ODbtD2--/f_auto/v1722860399/public/Placeholder%2008","thumbnailUrl":"https://media.daily.dev/image/upload/s--0_ODbtD2--/f_auto/v1722860399/public/Placeholder%2008","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/abstract-heresies-why-vibe-code-in-lisp--o2rhku1pd","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"vibe-coding,lisp","timeRequired":"PT4M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Abstract Heresies: Why vibe code in Lisp?"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/abstract-heresies-why-vibe-code-in-lisp--o2rhku1pd#faq","mainEntity":[{"@type":"Question","name":"Why would someone use Common Lisp instead of Python for AI-assisted vibe coding?","acceptedAnswer":{"@type":"Answer","text":"Lisp's homoiconicity means code is structured as the data it manipulates, so an LLM predicts pure AST structure rather than surface syntax like brackets, semicolons, and whitespace. Its macro system compresses boilerplate to save context tokens, and REPL-based development lets a model redefine functions and inspect live state without restarting the program, unlike compiled mainstream languages. Developers weighing language choices for AI-assisted coding can track emerging vibe coding practices on daily.dev."}},{"@type":"Question","name":"How does developing in a Lisp REPL change the debugging workflow when AI writes buggy code?","acceptedAnswer":{"@type":"Answer","text":"Errors are caught by the condition system instead of causing a hard crash, so the model can analyze the stack trace and debug interactively at the point of failure. There's no need to restart the program from scratch (ab initio); a single function can be redefined and tested immediately while the rest of the application's state stays intact. Anyone iterating on AI-generated code follows workflow tricks like these through daily.dev."}}]} ```