I feel like everyone has some sort of justification for why their pet language is now the best because LLMs can work in it better for a bunch of reasons.

Javascript/Python is the best because there's so much code out there that the LLMs can train on, and LLMs can write lots of tests to make sure everything is correct. There's nothing to compile, so the LLM can iterate quickly.

Rust is the best because the LLM gets great feedback from the compiler because of its strong type system, and it can deal with the borrow checker for you.

Go is the best because it's a simpler language with a decent type system, and the LLM can reason about that well, and will never forget to check an `err` return. The compiler is fast, so the LLM can iterate quickly.

I could write similar praise for C, C++, Java...

At this point I don't think any language is the best "because LLMs". I think there are quite a few languages that LLMs are probably not good at, but you have lots of choices if you want something they are good at.

I have similar experiences in Clojure. I use Pi and created an extension which teaches the LLM how to start a JVM with a Clojure nREPL listening in it. Added a tool which lets the agent evaluate any Clojure form inside the JVM. Sprinkled the setup with clj-reload and now the agent is using the nREPL as if it were its second nature.

What I like most is how fast testing goes: it modifies test code on disk, asks clj-reload to reload all affected namespaces, then reruns the tests. It's also fun to see how it verifies its assumptions by evaluating short programs through the nREPL.

I asked it to organize the various subsystems inside my playground repo into Integrant systems and make it possible for me to say things like "restart the http subsystem".

It also understands shadow-cljs: I replicated the necessary parts of the shadow CLI tooling in Clojure; now I can compile, watch and serve any number of CLJS apps located in various namespaces from inside the same JVM. There is no need to touch the command line any more: I just instruct the agent to start a particular CLJS app and it's there.

I don't think the conclusions of the article are actually supported by the arguments and evidence, and several of the technical claims seem pretty questionable (e.g. fast redefinition is not fast verification, entering a debugger is not guaranteed recovery, generated code is not automatically a validated library). With the same argumentation, Smalltalk (particularly Pharo), Racket, Julia, Elixir or even Forth would be equally credible candidates for "best programming language".

I keep wanting to use LISP, which is kind of why https://github.com/rcarmo/gi uses https://github.com/rcarmo/go-joker, my IR-accelerated Clojure interpreter (which can also do WASM, and thus isolates).

I end up using Go for mostly everything, though, because a) Python is too slow and b) Rust will regularly fill up the hard disk of _every single one of my sandboxes_ with just... too much stuff, and takes around four times as much to compile (I can build, link, profile and fuzz Go in the same time I get a plain Rust build).

Still, I hope that one day I will be able to do just LISP :)

I think half the article talks about why CL is good because it can resume from an exception, and half the article talks about why DSLs are good.

I think others have pointed out that most modern scripting languages can halt at exceptions without unwinding the stack. Python & Node both support this with core tooling.

As for DSLs, they constrain the LLM which generally helps with code quality. However why implement your DSL in the unconstrained chaos of CL? You can write DSLs in Rust which gives you static typing, a borrow checker, and clippy.

> because writing code used to be the slow part

I don't understand how people have that stated as a fact. Coding was never the slow part. Neither pre-llm, nor now. How it needs to be done is software engineering. And that corresponds now to the "thinking" part of llms, so unless you are making the llm "think in lisp" its not useful. How would that even work. training data to be completely in lisp ?

> Lisp programs are often much more concise because macros let you abstract away recurring patterns and make them part of the language itself

functions ?

> So the bigger the program gets, the bigger the difference. In my own experience the apps I've built in Common Lisp end up about six to seven times shorter than the Python versions

By that logic writing code in this concept language made up completely of symbols would take you even further ( https://github.com/artpar/guage ) but in practice it doesnt because llms arent trained to that extent on this.

Lots of comments praising LLM's understanding of Common Lisp macros. I've seen them break badly at the macros-writing-macros level. I saw a current frontier model get so disoriented by one (a simple one!), it created something that expanded into a "(let (((".

(That's an impossible count (3) of parentheses on the RHS—like a six-fingered hand).

I've had some of the same ideas, I would love a full macro system on a dependently typed language. My stab at it earlier in January was not quite the right thing, but I do think this is the way. Weirdly enough concision is even more important in LLM context than in regular human context.

For LLMs, less code means fewer tokens, and tokens are what you pay for so you spend less on development.

I don't think that's strictly true.

What you need is for your LLM to be able to understand enough context to be able to make a change with as few token as possible, so if your code isn't expressive enough or if it has a tendrils calling lots of different functions/methods all over the place, then you'll have to give it much more code (context) than if you've got nice encapsulated modules that don't depend on other parts.

The design of your architecture (probably?) has a greater impact on token use in a large app than the language it's written in. Although, obviously, languages lend themselves to particular architectures so it's correlated.

> Lisp programs are often much more concise because macros let you abstract away recurring patterns and make them part of the language itself

This is why Lisp never catches on. Each programmer invents their own ad-hoc, undocumented, barely working language in the form of those macros. The same thing happens in other languages with macros (like C and assembler).

I think LLM coding has changed the criteria from which language is best to which language has the best organizational/institutional support for the long-term.

Autolith is great with LLMs exactly because it's written in Common Lisp.

https://autolith.rocks

Even though I am of the opinion "Always has been.", this article, this thread, and even the code of the article, are demonstrations of why I am so disappointed with almost all of you and will not share my work until the situation improves, which seems unlikely to happen before death reaps this strange stalk.

related: https://opusmodus.com/forums/blogs/entry/4-connecting-an-ai-...

Give the same agent the same tasks across Common Lisp, Rust, Go, Python, Typescript, etc. Measure tokens, retries, failures, time to working solution, and human corrections.

To those who lament the lack of strong types in Common Lisp: Surprise, you can define them.

I remember this guy back in the dotcom boom days, more than 25 years ago, who made an app that got acquired by Yahoo.

He claimed that Common Lisp was the best programming language for web apps, and that it gave him a massive advantage in creating his app.

What was his name again? Paul something? Oh yeah, Paul Graham.

”Would you agree that some programming languages are better than others? If so then one of them must be the best.”

False. A partial ordering doesn’t guarantee a maximum element!

I keep bouncing the idea around of building a core in C or Rust then writing everything atop it using Janet. I love how readable lisps are (with macros, you can really move up the abstraction ladder quickly) and working on a live image should make iteration a breeze in an LLM.

Assuming that for an llm all languages are ≈ equal, the developer factor matters most, and thus the language you know best is the best one, given your ability to correct, direct and orchestra the llm symphony. That been said, obviously this should be examined per task, as some aren’t capable of performing tasks other can.

> You can just point your LLM at the debugger, and it’ll make its fix and resume the program.

I'd rather my language surface problems at compile time (via type errors) for all possible code paths rather than a particular codepath at runtime.

That said, nothing prevents an LLM from controlling gdb/lldb either.

Also this is actually not such a big win: resuming the program after making the change aka hot reload is often a very hard problem even in highly dynamic languages like erlang and common lisp. What if the schema changes etc. ?

> To my knowledge Common Lisp is the only mainstream language that does all of this.

You should also mention racket, chicken scheme, guile scheme, MIT scheme, erlang/elixir, even Python via the repl and so on ...

> This is what makes macros possible. A macro is a function that takes your code and returns new code in its place, that means you can add new constructs to the language itself.

Macros + untyped code means the code cannot scale beyond a few thousand lines easily. Only a few programmers may understand the program fully and it’s often in their head rather than documented. Types implicitly document the code and allow hundreds of programmers to work on it. Lack of typing hinders code refactors too.

> Common Lisp is an ANSI standard and it hasn't been updated since 1994. I like this feature.

I like stable languages but not ossified languages. The internet was in its primitive infancy in 1994. This means Common Lisp may not be as web friendly as, say, golang without external libraries. Moreover, there has been a lot of progress in programming languages since 1994. OCaml/Haskell/Rust/Python/Ruby etc. incorporate some of that.

> But I don't think that's a problem anymore. Most programs today depend on millions of lines of code from packages that keep getting compromised. You don’t want that in yours. Also, with an LLM you could just write the part you need yourself or port the whole library — and LLMs seem to be really good at porting code.

You claimed earlier in the article that since Common Lisp was very concise you needed to spend fewer tokens via LLMs. But now that libraries for common tasks are not available you need to spend extra money on tokens to generate that functionality from scratch ! There goes your token budget !

Which is better ? A from-scratch LLM implementation of something with security holes or a library downloaded from the internet ? If you can restrict your dependencies to stable and popular packages from npm/cargo/pip you will probably be better off.

as a lisp enjoyer i also recommend clojure! a phenomenal little language

An ERP system in...LISP? None of the reasons given as to why that would be a good idea are really very convincing or specific to LISP?

The main things you want for ERP are just to simplify database interactions as far as possible and to give you as many and as customizable options as possible for data visualization and curating information for a non techie user. I dont really get why LISP?

This post reads like it was written by a Common Lisp fan who is looking for a reasons to say that Common Lisp is good for AI agents, rather than an AI agent user evaluating what languages are really best.

I've heard fans of both statically typed and dynamically typed languages advocate for their language. The static type fans say that the rigorous compilation process gives the LLM a fast iteration loop with clear messages from the compiler on what invariants aren't being upheld. The dynamically typed languages advocates talk about fewer tokens, the popularity of the language in the training data, and so forth. Guess what, these are the exact same arguments these communities made for human developers.

Personally, I don't know the answer. The industry has swung back and forth on this over the decades. Before AI code-gen static languages were on the upswing for a variety of reasons, including runtime efficiency and much better ergonomics thanks to modern type inference engines. I suspect those reasons are still valid, and also that statically typed languages give LLMs a leg up because it is easier to reason about them locally thanks to declared types and information hiding.

Typesystems prevents hallucination errors and also ads an extra guardrail for the AI to adjust to. Its sometimes hard for the AI and humans to know what types are expected. The compiler holds the AI:s hand

guess a much stronger argument applies to Clojure / clojurescript as well.

I use agents heavily on Common Lisp in some parts of production projects. Typically Codex on whatever is the current top model with vibe-patched Tron MCP. REPL-based agent development via MCP does feel faster but I haven't ever bothered to benchmark it.

A language not optimized for reading code cannot be the best in the age of LLMs.

Soon, hopefully, we will have evidence based analysis of those programming languages best suited for LLM authoring. Fwiw I doubt that CL will make the cut - but happy to be proven wrong. Obviously a large factor remains the facility of the human driver for a particular language.

Until then, I subscribe to the view that strong types fit LLM coding well since LLMs are prone to make silly mistakes when they patch together code examples in dynamic languages.

[Disclosure, my new language https://bil-lang.org aims to add “strong typing” around parallel programming to help weed out deadlock conditions.]

It seems like an assumption here is that any language will be equally performant at runtime, for a given number of tokens burned to produce the code. I have never used any functional language for anything real (except maybe Mathematica). Is that true?

Are you saying this based on the fact that no-one will read or understand the code manually? That might be the case but on some areas, having a product understanding and knowing what to build, why to build matters a lot and sometimes the LLMs will write code that is not correct, doesn't make sense and they will continue down that path without explaining it.

I still believe that other languages which are understood by developers are and will be required and LLMs are trained on the same dataset so it can write the code.

I have been experimenting with agents inside the application itself as it's being developed. The application has a harness and then that harness can self-evolve and evolve/introspect the application.

Lisp may not have the ecosystem to compete with Python or JS. On a tangent though, I am in the middle of a mini experiment with Codex that stemmed from trying to understand the beauty of SectorLISP and is now headed towards: "What would it take to build a toy OS for RISC V using successively richer evaluators?".

I have a similar experience with Julia. Very fast iteration, down to native code when required.

I don't really agree with this. Having strong types and guardrails like in Haskell, Rust or OCaml helps _massively_ with LLMs because they get very clear messages back, and can express their logic using semantic types they can easily follow. Conversely, I've noticed that AIs (just like humans) tend to kind of lose the thread with very dynamic code

cant you do most of this with smalltalk too, or erlang?

I dont really understand what macros get you when llms exist since a llm doesnt really need to create dsls to get work done

You can point an LLM to a debugger in any language. You should measure token efficiency across different workflows to see if there is a programming language that is handled better by a LLM.

> LLMs write code really fast

I'm amazed how slow they are.

I ask ChatGPT to change <title> on a 1000-line HTML file. It completes in 32s.

I ask for line count. It takes >20s. And the bot claims "1-2s".

A very big claim backed with poor arguments and easily disputed evidence.

Fools! There is no best, only better.

High level programming exists on a spectrum between C and Lisp. Your Go or Python is just a DSL.

Won’t you have to write entire stacks of code from scratch for lack of prior art in CL?

Zscaler (a corporate network security tool) is blocking my access to this website because it contains "Adult Material".

AI needs a new Lisp Machine (like but not equal), the future computing principal part should be AI rather than human, env should be abstracted to AI.

This link is fishy. It appears to host TBLOP (The big list of porn) as some sort of invisible div before the actual article you guys read starts. Seems to be a weird form of SEO. Verify? Open the link with lynx, which does NOT honor CSS.

Astronaut 1: So... now Lisp is the best programming language?

Astronaut 2: Always has been...

I am not an expert, just an engineer with years of experience. I switched to Rust a couple years ago. I was still learning before LLM generated Rust was good enough that I stopped coding by hand.

Again, not a language expert, but: if you can describe your domain or business logic as clearly as a strongly typed language with a rich type system, most of your issues are gone. Enum and Struct with all the other core types plus the match expressions does most of my mental heavy lifting. I do not even track any of the recent language changes.

What I really care about is the shape of what I am describing - does it translate to code? How much do I lose in the translation? I want to try other languages, particularly Lisp but Rust is at this moment my choice. I have my own UI framework (1), my own provenance based business domain generator and a few simple language parsers.

I am building apps where you can, for example, throw a CSV file (2), ask questions in English and get answers - without using an LLM. Parser. Rust is no doubt a great language to express - not as a programmer, but as a prompter. I do not write the code. I ask LLMs to generate it using only basic knowledge of Rust and its type system. This will be the key to work with LLMs for majority of people.

1. https://github.com/brainless/akar

2. https://github.com/brainless/baho

I recently wrote a comment on another thread that I think fits even better here:

In my circles I've noticed it's very easy for us to rationalize why our previous favorite language is also the perfect language for the agent era.

If your favorite language before was Python, why, LLMs are fluent in it! So much training data! So many libraries! Home of machine learning! None of that pesky compile time, agents don't need compile time safety anyway, they write such good test coverage! It's The Perfect Agentic Coding Language.

If it was Rust, by jove, an agent can easily handle the headache of satisfying the borrow checker, and now you get the best of all worlds! Safety! Near-C runtime performance! Abstractions! The only reason people didn't use Rust before was it was Too Hard and there were Too Many Furries and now it's not hard and you don't have to interact with them, so get on board. It's The Perfect Agentic Coding Language.

If it was Golang, oh my goodness, what a choice. Pretty fast compile time and pretty fast runtime. Agents get a tight feedback loop with build->run->test->edit. Not very complicated, code has to be written in a straightforward banging-rocks-together way. Good stable ecosystem! Rob Pike designed the language for people he said were "not capable of understanding a brilliant language but we want to use them to build good software." That's an arrogant, demeaning way to describe your colleagues but if they're LLM agents it's dead on! It's The Perfect Agentic Coding Language.

I could go on and on. I'm not immune either! My own favorite language is F# and when I feel like self-justifying, I play the same game:

It has access to the .NET ecosystem like C#, but I don't have to constantly remind the agents to prefer a style with immutable data and pure functions, they idiomatically do that in F#. Files have to be in order and can only refer to symbols defined "earlier" in order, if you want mutually-referential types or functions they have to be declared as such in a joint statement, so spaghetti is hard to create: each project's codebase naturally ends up in a layered bottom-to-top architecture. The language is terse enough to be token efficient, without being symbol soup. FSX scripts can be generated during agentic code reviews to demonstrate repros for discovered issues. If there's any type of code that still warrants me jumping in and writing some myself, that code would be data type definitions/domain modelling, and F# is a joy to write those in. It's The Perfect Agentic Coding Language.

Happy to discuss

I mean its cool but what about all of the extra infra I need to write because support for the lang is not as extensive and so more code I need to maintain?

Seems to be written by somebody who has never worked within a team, never published a commercial piece of software (with the said team), and never used an LLM to write code. How is that possible? I love Common List and Racket. Love them to bits. I'd use them all day every day if it weren’t for that pesky LISP curse and the fact that nobody would want to work with me. LLMs, until recently were consistently forgetting parens, couldn't close functions properly. Somehow LLMs can't really count in their head, so it makes for a really... fun time with LISPs.

This is written by a person who never used LLMs.

LLMs need a language that:

- has opinions about how to write standard code

- has opinions about one way of formatting and codestyle

- has opinions about linting and integrated debugging

- has predictable strong types

- has opinions about integrated unit testing and a standard way to write them

- has an integrated toolchain

- has a strong stdlib and an upstreamed way to unify libraries

- (recommended) has a standard project layout _where_ to put its code (types, structs, helpers, utils, etc)

Go and Rust fit all these checkmarks except the last one. That's why those languages don't need kilometer long prompts to tell the LLM how to write code. Most of the prompting in those languages focuses around architecture and design, and not about style, tooling, or other artificially vague decisions.

Lisp is the most unopinionated language there is, therefore it is the worst in terms of lack of decisions encoded in its tooling.

And I'm not writing that as an opponent of the language, I've written scheme bindings for a couple of years in (academic) robotics.

The point that I am making here is that you _need_ an opinionated language for an LLM to make sense. Write linters and tools before code [1].

[1] https://cookie.engineer/weblog/articles/write-linters-and-to...

don't think software companies will user change their software

Zero visible experience with CL on top of a project list where half of the links give a 404. Others are unmaintained slop output. Sprinkled with Paul Graham references and the Harvard badge.

Sorry, I'm not impressed. How did that /run/ to the top of HN? [pun intended]

"Vorschusslorbeeren"? A clique of voters?

Boring.

Yep. Or at least broadly the family of S-exp based languages. I've developed a (still closed source) Lisp dialect that has grown to what I believe to be the most(?) expressive and powerful programming language available today. As in, there is zero reason to ever pull out C/C++/Rust. It's fully compiled, with a system Fω typesystem, inductive types, and most importantly as of recently full whole program reflection. As in Lisps macro system extended to the further possible development. You can, quite literally in the language itself, define full compiler passes, manipulate the SSA, add/remove/analyze nodes.

   (module reflection_symbolic)

   (comptime
     (fn sx-kind (x k) (sym= (syntax-kind x) k))
     (fn sx-zero (x) (equal x '0.0))
     (fn sx-one (x) (equal x '1.0))
     (fn sx-add (a b)
       (cond ((sx-zero a) b) ((sx-zero b) a) (otherwise `(f+ ,a ,b))))
     (fn sx-neg (a) (if (sx-zero a) a `(fneg ,a)))
     (fn sx-sub (a b)
       (cond ((sx-zero b) a) ((equal a b) (syntax 0.0)) (otherwise `(f- ,a ,b))))
     (fn sx-mul (a b)
       (cond ((or (sx-zero a) (sx-zero b)) (syntax 0.0))
             ((sx-one a) b) ((sx-one b) a) (otherwise `(f* ,a ,b))))
     (fn sx-div (a b)
       (cond ((sx-zero a) (syntax 0.0)) ((sx-one b) a) (otherwise `(f/ ,a ,b))))
     (fn sx-id (a b)
       (if (and (syntax-binding a) (syntax-binding b))
         (= (syntax-binding a) (syntax-binding b)) (sym= a b)))
     (fn sx-lookup (x names vals)
       (if (= (len names) 0) x
         (if (sx-id x (head names)) (head vals) (sx-lookup x (tail names) (tail vals)))))
     (fn sx-map (xs names vals depth)
       (if (= (len xs) 0) (list)
         (const (sx-expand (head xs) names vals depth) (sx-map (tail xs) names vals depth))))
     (fn sx-expand (e names vals depth)
       (if (> depth 32) (syntax-error "symbolic expansion exceeds 32 nested helper calls" e)
         (cond
           ((sx-kind e 'symbol) (sx-lookup e names vals))
           ((not (sx-kind e 'list)) e)
           (otherwise
             (let ((xs (syntax-children e)))
               (let ((op (head xs)))
                 (cond
                   ((or (sym= op 'let) (sym= op 'let*))
                     (let ((ns names) (vs vals) (bs (syntax-children (nth xs 1))))
                       (declare (mutable ns vs))
                       (dotimes (i (len bs))
                         (let ((b (syntax-children (nth bs i))))
                           (let ((v (sx-expand (nth b 1) (if (sym= op 'let*) ns names)
                                             (if (sym= op 'let*) vs vals) depth)))
                             (set ns (const (head b) ns)) (set vs (const v vs)))))
                       (if (/= (len xs) 3) (syntax-error "symbolic let requires one pure body expression" e)
                         (sx-expand (nth xs 2) ns vs depth))))
                   ((sym= op 'the) (sx-expand (nth xs 2) names vals depth))
                   ((or (sym= op 'f+) (sym= op 'f-) (sym= op 'f*) (sym= op 'f/)
                        (sym= op 'fneg) (sym= op 'fsin) (sym= op 'fcos) (sym= op 'fsqrt)
                        (sym= op 'tuple) (sym= op 'vec3))
                     `(,op ,@(sx-map (tail xs) names vals depth)))
                   (otherwise
                     (let ((f (fn-ref op)))
                       (if (/= (len (fn-params f)) (- (len xs) 1))
                         (syntax-error "symbolic helper call has wrong arity" e)
                         (sx-expand (fn-body f) (syntax-children (fn-params f))
                           (sx-map (tail xs) names vals depth) (+ depth 1))))))))))))
     (fn sx-diff (e x)
       (cond
         ((or (sx-kind e 'float) (sx-kind e 'integer)) (syntax 0.0))
         ((sx-kind e 'symbol) (if (sx-id e x) (syntax 1.0) (syntax 0.0)))
         ((sx-kind e 'list)
           (let ((cs (syntax-children e)))
             (let ((op (head cs)) (a (nth cs 1)))
               (let ((da (sx-diff a x)))
                 (cond
                   ((sym= op 'fneg) (sx-neg da))
                   ((sym= op 'fsin) (sx-mul `(fcos ,a) da))
                   ((sym= op 'fcos) (sx-neg (sx-mul `(fsin ,a) da)))
                   ((sym= op 'fsqrt) (sx-div da (sx-mul (syntax 2.0) `(fsqrt ,a))))
                   ((= (len cs) 3)
                     (let ((b (nth cs 2)))
                       (let ((db (sx-diff b x)))
                         (cond ((sym= op 'f+) (sx-add da db))
                               ((sym= op 'f-) (sx-sub da db))
                               ((sym= op 'f*) (sx-add (sx-mul da b) (sx-mul a db)))
                               ((sym= op 'f/) (sx-div (sx-sub (sx-mul da b) (sx-mul a db)) (sx-mul b b)))
                               (otherwise (syntax-error "cannot differentiate this operator" op))))))
                   (otherwise (syntax-error "cannot differentiate this expression" e)))))))
         (otherwise (syntax-error "cannot differentiate this syntax" e))))
     (fn sx-partial (f index)
       (let ((e (sx-expand (fn-body f) (list) (list) 0)))
         (fn-with f 'body (sx-diff e (nth (fn-params f) index))))))

   (macro derive-partial
     (syntax-rules ()
       ((_ result source index)
         (fnderive result source (transform (lambda (f) (sx-partial f index)))))))

That's a lot of power to mess things up that I wouldn't be putting into the hands of an LLM I don't trust.

In my experience, LLMs instantly find the reason for the crash and fix. They don't even need to go through the debugging phase anymore. It doesn't matter if you're generating c++ lisp or cobol.

Yawn. Use the best tools for the job not because it's "sexy".

> how long your feedback loop takes is what decides how fast you can build.

It's so disappointing to see this repeated everywhere.

Lots of bad reasoning in this article.

So long as your feedback loop isn't slow enough to be taking you out of flow, it's fast enough. Having it be a few seconds vs a few hundred milliseconds mostly doesn't matter for a human, and will matter even less for an LLM.

On macros and DSLs, yes they're cool and even useful sometimes, but most of the software industry is working quite happily without them. And LLMs aren't going to change that because they are best when there's a lot of relevant patterns in their training data. That ends up being a far more important factor in their effectiveness than whether the language itself is token-efficient. It's much easier for an LLM to reason through how to do XYZ in Python where it already knows all the semantics and syntax than it is for it to do it in your DSL it's never seen before. To be clear, it can probably do both but will make mistakes an order of magnitude more in the DSL, and that's what will matter most for the LLM iteration time.

This is one of the most inane, fluff articles I’ve seen dumped in this site in a while. Nothing original, just a simplistic regurgitation of known stuff. Reads like lame, lazy LLM slop :(

> In Common Lisp your program won’t crash, it’ll stop and open a debugger with the whole stack and all the variables. You can just point your LLM at the debugger, and it’ll make its fix and resume the program.

> To my knowledge Common Lisp is the only mainstream language that does all of this.

Sounds like someone who has never used C# and Visual Studio? Even JavaScript is capable of doing this, honestly JavaScript might be the one language with the richest developer tooling of all time (possibly?), sad to say because there's nicer to work with languages out there.

Now X is best because LLM Era.

Endless article generator.

In the benchmarks though here it is slow and consumes too much memory

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

But I find ideas like Carp very attractive.

Still common lisp is designed very good.

Now as ever, there is no “best programming language”.

There’s the right tool for the job, there’s compliance with requirements, there’s personal preference.

Don’t let anyone ever tell you you are programming wrong.

Lisp is a terrible language, for me at least.

Yeah... no. I don't think there is a best programming language, but I do think dynamically typed languages are worse for AI to code in compared to statically typed ones.

"Would you agree that some programming languages are better than others? If so then one of them must be the best."

Unless of course there are multiple dimensions of "Good". I in my opinion this is exactly the case. There are best languages per dimension, but not absolutely best.

Common Lisp isn't even a good programming language. There's nothing in CL that isn't in a ton of other languages now. When it was being designed it was way ahead, but now it's just way behind.

Maybe you could take CL as a foundation, introduce modern features and uniformity to the language, remove some of the insane complexity, tame the unhygienic macros, and come up with a pretty good language. Since about 7392 different flavors of scheme have tried to do this and mostly failed, I think this is very unlikely.

Lisp allows for some really, really complex and spaghetti code bases. I have seen the ultimate macro-hell from top to bottom. I know syntax does not matter, but i just cant honestly say i read lisp code as clear as something like Go. I guess it boils down to style. I have seen 100 lisp styles, and only one Go style.

Nah with llms the most used lang prolly has the best output

Lisp has existed more than 50 years, more than most programming languages.

If it were a good programming language people would be using it more at this point.