Why Common Lisp is now the best programming language
vivienhenz.com
vivienhenz.com
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 mean, it can still reason about it, but the code it (Claude and Gemini) frequently doesn't compile and it throws edits onto it until it does. When it then compiles this pretty much c# written in a functional HM-typed sexpr language that lacks classes.
AI has been great help in writing the compiler, though. I got stuck in codegen after having written a lexer, parser and type checker, and not only did it make a faster and better code generator than I ever could, it also made the type checker about 5x fater.
It also allows for coding at a higher level, meaning that code is closer to the prompts.
Is it actually true? OF COURSE IT IS!!!
So no idea, but after long dismissing that idea precisely because it looks like a "just so" explanation for my obvious favorite choice I am starting to come around to the idea that it might just be true in spite of the obvious bias...and definitely worth testing.
Silly example. Instead of:
Calculator number: 2
Calculator operator: #plus
Calculator number: 2
(Calculator answer) print
Calculator llm: “calculate the sum of 2 plus 2”
(Calculator answer) print
EDIT: fix the wonky syntax
Fight me. As a classical software engineer, I hate Go, but in this new era it wins so easily. For web, at least. The subjective stuff about how the language feels is all out the window now.
```
...
bla, err := doSomething(...);
if err != nil {
...
}
...
```
...
...
err = do_someting(&bla, ...);
if err != 0 {
...
}
...
It's not that different
There's no good way to resolve these kinds of debates. I don't think AI changes much. It thinks in the same sorts of ways we do, just faster, so things humans find hard or unproductive can also be hard and unproductive for AI too. There are a few exceptions where it's able to reason fast enough that things which would be dumb for humans (like reading raw assembly or bytecode) are no big deal for AI. But mostly it's the same.
The parent did mention:
> ...and is simple to deploy.
Also, my experience with Java programs is that the memory overhead is even higher than Go (where it's a ~2x of what the program holds as heap due to the GOGC=100 default).
./gradlew installDist # build the app for deployment
rsync -avz --delete build/install/my-app/ user@host:my-app/
But in reality most software isn't deployed by copying binaries around. You'd want it to be at minimum run by systemd or kubernetes, for example. And if you want a Docker container then it's pretty easy. Your framework probably configures it out of the box:
./gradlew dockerBuild
The reason it's not harder in the end is that the above takes cares of many annoying details that crop up in real deployment, like knowing what CPU and CPU extensions does the host have? Can you deploy incrementally without recopying the whole thing or does that not matter?
The above is for servers, but it's not really harder for CLI tools either. Fat JARs exist. If the user doesn't have a JVM, once again, they can install one easily from their package manager and then it's done - no need to create and distribute half a dozen binaries for all the different OS and CPU combinations that are out there.
But if you want to make AOT compiled binaries and get lower memory usage too, there is GraalVM which can do both. You've got the choice.
Note how the above debate isn't changed by AI in any way. Their weaknesses remain weaknesses, their strengths remain strengths. I wouldn't personally use Go because of its poor feature set and debugging support (errors don't reliably create stack traces). But the arrival of LLMs changes nothing about these preferences and choices. At most you can talk about token efficiency, in theory, but the attempts to measure the real world impact of that don't seem to have yielded decisive evidence.
And compared to Go, the production observability is very good.
I also use Clojure and can observe my running app with a full REPL.
This debate in particular is easy to resolve: there is no “best“ language for all use cases and I agree LLMs have not changed that. The best language for a scenario depends entirely on the scenario, so talking about best languages without a scenario in mind is completely the wrong discussion.
I've never written a general program in my life. I've written a bunch of specific ones, though. What I care about is which language is best for writing this specific program. Why do I care about which language is best at writing a program that I'm not trying to write?
No. I’m sick of flame wars, and I already was before LLMs turned everyone even more insufferable. You can fight yourself in your own corner, if you like. Never thought I’d miss emacs VS vim.
Use whatever language you want, I couldn’t give less of a shit. I have no desire to waste time on a dick-measuring competition, and that’s doubly true because people in these fights are measuring other people’s dicks.
> As a classical software engineer, (…) The subjective stuff about how the language feels is all out the window now.
Subjective stuff never mattered to people who take no pride in doing proper work. That hasn’t changed because of LLMs, it only shone a brighter light on those people.
I do agree the comment came off strong and for that I apologise to the person above. I meant to make a general criticism, not condemn any particular individual.
Even better don't throw away the frameworks, learn to use JIT caches and hot code reloading tools, and you can even debug, edit and continue from the comfort of an IDE, doing several useful actions.
I think Go's compile times are great for the AI age, but that "pretty fast runtime" is not.
Go is close enough on runtime for all reasonable purposes.
AI + smaller docker images made me look at it again.
The fact I can test/build concurrently and much faster than rust, off the same repo without messing with sccache and worktrees, make it easily the winner for many web/self-contained scenarios.
As a quite well seasoned software engineer working many years with Java, C#, PHP etc. both in complex calculation systems and webservices, go-lang just feels superior in so many aspects. While I might still fare better in say Java is purely a function of me spending much more time in it.
So I see your point in myself and agree and agree. (I just don't hate go, I think we need to give it a chance)
You also get very easy parallelism in Goroutines, excellent ecosystem, and one of the best performance profilers in any programming language, pprof.
I’ve done pretty low-level C++ and Fortran in the past, but these days I’m honestly mostly used Python with either NumPy or CuPy for calculations, so not very low-level at all. My code is pretty performance-sensitive though, so unless the main operations can be framed neatly in terms of NumPy or CuPy primitives, one had to drop down to low level.
Do you know how the Go library support is for typical scientific computing stuff, e.g. matrix diagonalization, sparse matrices, or handing off such calculations to CUDA (or other GPU frameworks)? Is there a strong numerics community in Go these days, or would you have to implement most of what you need yourself?
Is one I've heard...
(I like frameworks and libraries for LLM work. They keep the machine on the rails for longer, and the end product is more consistent).
I thought Rust was the best because it was moral.
My experience with Python is different. I noticed that my LLM (Claude) frequently gets stuck in cycles when coding larger features in Python. I'm also doing a lot of work in Scala, a language where much less code is on the Internet, yet Claude does way better, it hardly ever gets stuck at all.
My theory is, that while there is a lot of Python code on the Internet, a lot of that code is crap. This will trap LLM's into coding crappy solutions which will eventually bite them in the tail.
Also, I believe that, especially for larger codebases, a strong type system helps not just humans but LLM's as well.
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.
https://github.com/cellux/pi-extensions/tree/master/extensio...
Note that this may not work for you standalone as it relies on my other agent-sandbox extension (which ensures all agent operations happen inside a sandbox container).
But point an LLM to its source code and it will extract the gist of it.
https://github.com/DeadMeme5441/arrodes
It seems to be a bit more integrated than what you describe here because it's completely built around a Clojure REPL
Surely iPython (what powers Jupyter notebooks among other things) + maybe pdb could do it? And agents are definitely familiar with how those work.
For iPython that's totally possible because the model there is just some kind of dependency graph. Regular python programs, much more complex I'd bet unless the architecture takes it into account
The iPython shell has %autoreload 2 (autoreload on changes) which is incredibly helpful for debugging and iteration.
I do agree that Lisp is better, hooking an agent up to Emacs is a lot of fun (and I'm only getting started!).
I don't let the LLM write macros though, it creates too much opacity for me to easily reason about what they've done.
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.
Because, for them (and me!), it was. I never understood why people kept saying that typing speed wasn't a problem since coding was never the bottleneck. It always was for me.
> functions ?
Macros can condense code down a lot more since you're essentially writing a language within the language.
> but in practice it doesnt because llms arent trained to that extent on this.
Right, but it probably works with words instead of symbols.
At least for me, typing code (in a language I know) is as easy as typing English (which is not my native language, but something I’m reasonably fluent in). Thinking in terms of generic computing concepts is equally as easy. Most of my time is spent on not contradicting what has been written before, not on what I need to express. Because the software needs to be coherent.
So the speed of coding is slow, because of all the double checks I need to do. Not because I don’t know which statements to introduce next. And that thinking happens at a meta level (state and its alterations) not at the syntax level.
This is the trapdoor in this discussion. The degree to which a concept has been thought of in terms of generic computing (or just generically; modeled abstractly), before code is written, is different for every programmer. Not only is the degree different, but the deliberation and levels of awareness vary as well.
If your mental process explicitly models in the abstract, translating and typing out to code can absolutely feel like a bottleneck, and the specific language involved matters.
Unless you're talking about raw typing speed or using an unfamiliar language, I don't think that it is. Most languages have few tokens and syntax rules. The next layer is the symbols from the standard library and the dependencies. After came the conceptual models, which is where the abstract thinking happens (like how does an hashmap works or what writing to a file entails).
Speed at the level of the first two layers can be greatly improved by very basic completion (syntax and symbols), or by just copy pasting. Integration like vim's quickfix or emacs' compilation mode helps because that's where compilation errors happens.
My opinion (anecdotally verified) is that people that feel like coding is a bottleneck have no editor fluency.
My anecdata is the opposite of yours; the people that feel like the _actually coding_ is the bottleneck tend to be the people that have the _most_ editor fluency, as they are(were?) motivated to remove the bottleneck.
I don't think so unless you're talking about raw assembly. Even with C, you got structs (clump of data) and functions (which give us nice abstractions over pieces of logi) as well as syntactic sugar for branching and looping. OOP is a whole different model of design. And FP has a whole other basis of computation theory (evaluation and reduction from lambda calculus).
It's kinda like drawing in a sense. People think they know what something is and you ask them to draw a chair or a bike and they can't do it. So you ask someone to give you the specs of something like an attendance form, and they can't readily give it. Drafting the specs is the real cost, not implementing it.
> My anecdata is the opposite of yours; the people that feel like the _actually coding_ is the bottleneck tend to be the people that have the _most_ editor fluency, as they are(were?) motivated to remove the bottleneck.
If it were, we wouldn't have a drought of editor models. Vim and Emacs are decades old. Then VSCode is basically the same thing as sublime, kate, notepad++, and the various IDE out there. Coding isn't the bottleneck.
Some people do see typing English as a bottle neck, because they have so many thoughts running in their head so fast, they can't get them out on paper fast enough. The Typing is a bottle neck.
I've had that experience with programming also, where I know exactly what I want, and typing it all in takes extra time.
This is what I’ve always maintained as well. More honestly I think there were two broad cases. First when the task is “copy this feature” coding can be clearly slower. Example when marketing says add a wishlist to e-commerce site. And when asked for requirements they say “just copy competitor.com”.
The other is adding features that require real decisions from people up the chain. A lot of us have worked on simple projects that should have taken a month that stretched on many months, sometimes to even being cancelled with nothing shipped. These are the one llms won’t help with.
[0] which I only rarely encountered in practice — maybe because I never had to do marketing-driven work
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.
- Conditions[0]
- Evaluation and Compilation[1]
I use both extensively while developing, debugging and analysing. With SLIME (this is a standard and very very slimmed out development aid) you add a debugger hook that allows restart, return from, move down, move up and etc into your available RESTARTs.
[0] https://www.lispworks.com/documentation/HyperSpec/Body/09_.h...
[1] https://www.lispworks.com/documentation/HyperSpec/Body/03_.h...
(It’s also essentially pointless when your unit of deployment is a disposable container and not a long running lisp system, but it at least makes development a bit nicer)
This is like claiming that you don’t have type errors in Lisp because everything is a list in Lisp. In reality type errors will either manifest in different ways, or still explicitly occur [0].
[0] https://lisp-docs.github.io/cl-language-reference/chap-4/e-e...
This is where the functional programming model really shines - there typically isn't a bunch of hidden state floating around to break hot-reloading
So no, the magic sauce is not “functional”, it’s that CL stemming from the Lisp Machine paradigm is designed for that sort of experience whereas something like Python very much isn’t. And it shows (there’s no image based development in Python that doesn’t end up creating more problems than it solves but image based development is not only the norm in CL but also tremendously empowering).
Are you sure this isn't just doing functional programming, and not realizing it?
It works fine and was designed for this use case.
Web development supports hot reloading modules, but this is effectively just dynamic imports and relies on the app being written for a library/framework that encourages pure code; it doesn’t kill the old module.
It also makes your agent wait for the compiler to finish.
(That's an impossible count (3) of parentheses on the RHS—like a six-fingered hand).
[0] e.g. r_1 = (\(\))*, r_d+1 = (\(r_d*\))*
Assuming let isn't shadowed :)
I shouldn't have been surprised, because that part of macro writing is purely mechanical syntax transformation—just a "take these tokens and return those tokens" function that one should expect LLMs to be good at. But I was surprised, because for me that was always the hard part.
So now I can think up new macros to abstract over patterns in my code—the part of macro-writing that I enjoy—and then push a magic "implement this" button to make it work.
What I'm not sure of yet is whether this is an evolutionary dead end—a train stop on the way to "you'll never look at code again, so what does it matter what programming language you used to use". Yes, I still look at my code, and this is a pretty nice train stop, wherever the tracks lead to.
Can lean generate small static binaries the same way Go/Rust/C/C++ can?
How practical is rewriting, say, grep in Lean?
> Can lean generate small static binaries the same way Go/Rust/C/C++ can?
Lean compiles to C and the binaries aren't huge, though haven't benchmarked this part yet.
> How practical is rewriting, say, grep in Lean?
Very, you should probably try it.
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.
I do think this is an unrelated win of functional languages that hasn’t yet been “discovered” by the vibe coder crowd - FP’s whole premise was that it makes your code depend on much much less things so you can “fit it in your head and reason about”… that’s like the perfect sweet spot for agentic as well, we just haven’t seen tools utilize that in earnest.
If that would be possible, there would be no function signatures.
Why would you do that? Take common lisps, most of the functions has been standardized for ages. It’s like saying by slightly adjusting the rules of addition, you can break maths.
Something that is going to be used all over the codebase is basically axiomatic and needs to be written and modified carefully.
Are you really asking why someone would find themselves needing to tweak the edge case semantics of a widely used function in a large project?
> needs to be written and modified carefully.
But notably compile time static type checking greatly reduces the risks involved. That's all I was trying to say.
If you do this and breaks the assumptions of the interface, it’s just recklessness. You don’t go and tweak functions without fully understanding the rules it established and how those rules are treated as axioms somewhere else.
> But notably compile time static type checking greatly reduces the risks involved
This is usually an excuse to not fully check the assumptions in a given piece of code. Like tbe warnings will be enough to take care of any issues. Type checking is not software correctness. I’ve seen badly defined type, type erasures, and various other issues that negated any value brought by the type system.
Models aren't good at this by default, so you end up with spaghetti mess. But if you tell them that you want strong interfaces, isolation, and types, they can work that way.
Recently there's an article on language plasticity in the era of AI/LLM and why D language is very well suited for this era [1].
Perhaps we need a proper benchmark similar to Beaver but for AI assisted coding for different programming languages instead of Text-to-SQL [2].
[1] Language Plasticity is More Important Than Ever:
https://blog.dlang.org/2026/08/10/language-plasticity-is-mor...
[2] BEAVER: An Enterprise Benchmark for Text-to-SQL:
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).
>[…]The same thing happens in other languages with macros (like C and assembler).
Uh, C definitely caught on.
I say this as somebody that loves CL dearly. The difference between princ, prin1 and print; set, setf and setq; =, eq, eql, equal and equalp is more than most programmers can be bothered to memorize.
Any sufficiently complicated Common Lisp program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
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 :)
This is a bold assertion, and one I think undermines the merits of the argument.
"Change the product themselves" - I haven't seen any software company or discussion propose doing this. I'm not sure how it'll work. It sounds like it blurs the line between configuration (letting the user toggle certain classes of existing behaviour) and forking (the user now owns the contract with the product).
Perhaps the idea is something like an embedded scripting language as used in some games, where users can write custom snippets to glue together what they want. Or a relational language to generate custom visualizations from raw data. These are the only forerunners of the concept that have found actual market fit to date that I'm aware of.
It's hard to generalize where else this would be useful outside of these domains, and in any domain I can think of - UI interfaces, data analysis, procedural generation - there is already a dominant language runtime bound to the environment (Javascript in browsers, C# in Unity) exposed to customers. Would Common Lisp be able to displace them? If so, why and how would it improve?
Merits on the basis of the runtime itself are meaningful, but the runtime needs to be popular for the value of the PL to be seen.
But end users are using LLMs to write their own code.
It's more like the new Excel. End users used to get a data dump from SAP,ERP or something, and use Excel to manipulate. Now they use the LLM, and are also using LLM to build large cobbled together messes.
Excel is the bane of accuracy, any miss aligned row in a calc and suddenly a company is loosing billions. LLM's are this on steroids.
False. A partial ordering doesn’t guarantee a maximum element!
So Lisp is better than itself.
If the extension improves something without making anything else worse under the chosen criteria, that's a Pareto improvement. Otherwise, it's a tradeoff.
https://en.wikipedia.org/wiki/Pareto_efficiency#Pareto_order
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.
1. Common Lisp has a whole system for defining and declaring types, and implementations do actually use this information to produce safer and higher performing code, including some amount of static, compile-time verification (e.g., you can get "expected an INTEGER but got a STRING" styles of compile-time errors). Fast, competitive-with-C floating-point math is achieved this way. DEFTYPE/DECLARE work.
2. If you prefer a system that doesn't feel like a 1980s barebones type system (i.e., Common Lisp's), then you can use Coalton [1] which adds types to a Scheme-like DSL within Common Lisp, but has a type system like Haskell's (similar to stock GHC + common extensions). Multi-parameter type classes, monomorphization, functional dependencies, etc. Yet it's still fully interoperable with Lisp code, uses the same Lisp toolchain, same Lisp compilers, same Lisp editors, etc. so it really isn't just a language atop Lisp, but something that's integrated within it.
(+ 1 "hello") ;; SBCL should emit a warning, but will let this run and you'll get a runtime type error
(+ 1 "1") => "2" ;; hypothetical, doesn't happen in CLWebpages, zettelkasten, todo, workout, diet tracker. It's a web framework! Creating an endpoint is just like making a function in emacs.
Since lisp is homoiconic the AST is just raw JSON. I save the AST in JSON stores in Postgres. But you can clone the AST down and then eval against a local copy of the REPl. So you get local eval for free.
Of course you have to rebuild git to manage a branching REPL in this way.
Folks have found it useful to just point gippity at the page and ask questions
Janet for orchestration, C for the frame loop.
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.]
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.
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.
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?
I almost never read the code now so how well I know the language is pretty irrelevant.
What's most important is how well the language can give feedback to LLM while developing.
Second most important factor is how good technically is the final artifact.
Rust seems to be quite good for both.
Speed of iteration would be cool but LLM thinking takes the bulk of time anyways.
Live debug through something other than computer use would be cool as well but I don't know how well LLMs can use auch things for any given language. I just usually tell it to heavily instrument code and put in debug bridges in the app its building to inspect and ivoke stuff while the app is running.
The de facto open source implementation, SBCL, has a solid compiler and garbage collector. It produces fast code.
A couple of years back there was a paper doing the rounds about software execution efficiency, which a lot of people in my neck of the woods got interested by because of the potential for environmental impact at the sort of scale we operate at. SBCL ranked disturbingly highly for something that is culturally never going to happen for us.
I dont really understand what macros get you when llms exist since a llm doesnt really need to create dsls to get work done
I agree with your point
There is also a phenomenon I've named "brevity collapse." Often, when shrinking a codebase, you find you need less glue. Additionally, because it is smaller, you can hold more of it in your head and see more opportunities for shrinkage. Surprising things happen when the bones of your language get more efficient---it's more like going from elephant to flea than elephant to grizzly bear. The smaller scale means there's less "overhead" code, which means you can go smaller still.
Let's way you wanted to do a web application using LLMs. Using a web framework would cost less tokens than using the vanilla underlying language (Python, PHP, whatever..), which is again way less tokens than building up from assembly (an LLM should be able to do this given enough time and compute).
https://news.ycombinator.com/item?id=21232352 (Oct 2019)
https://news.ycombinator.com/item?id=4766191 (Nov 2012)
https://news.ycombinator.com/item?id=694700 (July 2009)
* in the older sense of "token", meaning that one measures a program in AST size rather than lines of code
---
Edit: ok, this is what I get for not reading the article:
> For LLMs, less code means fewer tokens, and tokens are what you pay for so you spend less on development
There's a "zen" moment felt by folks who've written lots of macros (experienced in Lisps and Forths) where, when designed properly, you really feel like you've "grown" a language and have really walked up the abstraction ladder. My thesis is that macro heavy code when the author designs the macros well are very readable. That an agent's output when stacked upon macros can be a lot simpler to read and understand than in languages where the syntax is less fungible. And if you leave a project for a while and come back, an agent is a perfect tool to help you read your macros and familiarize yourself with the abstraction surface again.
Just a theory though.
Pithiness. A human might need to be able to read and understand the code. If the code is much longer than it could have been, it will take much longer to read and understand 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.
https://github.com/vivienhenz24/vivien/commits?author=vivien...
Like your idea about SectorLISP, btw.
One could argue that this was a large benefit for human coding long before LLMs became useful.
It is why I always preferred strongly-typed languages.
And once we had practical strongly-typed languages with implicit type inference I really couldn't wrap my head around why anyone would prefer dynamic typing other than just inertia due to that being what they were used to.
The best dual path systems are when they use different technology. Hence, an error in one is highly unlikely to infect the other.
This is what static typing provides.
Previously studies into the benefits of static typing for humans were always a bit flawed because you can't do that with people. And tbh I don't know why but there are a surprising number of people that don't appreciate static typing. My guess is a combination of ego and laziness, which doesn't apply to LLMs.
I’m not sure if the Common Lisp compiler can be very helpful either, since it’s a dynamic language and A and B could be many different types (duck typing).
Strong types are the way to go, at least for now.
Type declarations are also optional and compilers can create compile-time warnings about them. Thus for many trivial cases, when using SBCL some obviously wrong types, or typos, or miscounted arguments, can be caught ahead of time without having to execute code. CL is also not duck typed. If abc-xyz is a generic function, selecting which method to call relies on the actual class hierarchies of the given A and B objects, there's no "duck shape" shenanigans.
For static types, well, CL is flexible enough to bolt such a system on top as a library, where you'll have a full ML/Haskell style type system. https://coalton-lang.github.io/ But it seems the relevance for LLMs is rather mixed, much like studies from the last few decades on static/dynamic typing in general: https://danluu.com/pl-tokens/
It's possible to write the whole system only by defining the types.
The "glue" can be sloppy but as long as it keeps on the edges the output is most often fine.
Recently I'm on the fence about Rust vs OCaml (but plan to write about it soon) because I have ~700k LoC in Rust but my workflow starts to get seriously dragged down by compilation/tests in isolated worktrees.
I recently also dab with Gluon (as embeddable type safe scripting) and rule-based-development for maximum code control/agents output leverage.
The dynamic features you get with a full blown REPL are, in some specific cases, worth the trade off you get by losing the guardrails (which I call Rubber Baby Buggy Bumpers).
You're right though - strong typing feels like a cheat code.
> C++
I'm a bit confused here.
Last I attempted to write some smaller ocaml project I used LLMs for support (but wrote myself). They generally weren’t excellent.
Honestly, types don’t help as much as people want them to. The LLM does best on popular languages, especially those whose use and feel is also mainstream.
That is to say, pick a niche language like Odin, and it may incorrectly start to over-apply Go’isms - knowledge from one language bleeds into how it approaches others.
Also if you really want Haskell types you can use Coalton, which is essentially Common Lisp with Haskell types, but lets you interop with Common Lisp seamlessly as Kotlin with Java.
The models learned to code, the actual language is just a tiny adapter on top.
the superfans make me not want to explore it ;-)
Astronaut 2: Always has been...
High level programming exists on a spectrum between C and Lisp. Your Go or Python is just a DSL.
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.
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.
Could be said that it was the path of least resistance, but the funny thing is that most of that resistance is you just being in your own way.
Use the language that you like (enjoy your favorites!) and that binds well with other tools you're using. I'm currently working on a project that's all C++ (wxWidgets frontend, plus C++ backend). I've used LLM tools with it, no issues. Would be the same with any other language, from what I can tell. I have another project in Go I'll probably try it on at some point soon.
I think Lisp and an ML are kind of the dynamic (static) duo. I still think MLs are the best for complex projects, but interpreted languages are pretty neat too. Python, Rust, and Golang are all great, also.
I think a tree calculus language might be the actual best - but it's too soon to say
Really, languages are great for LLMs.
This isn't the future I wanted, and is why I advocate for trade schools these days.
I miss the days I could listen to music and use my adhd/autism to its fullest potential reading documentation and figuring things out myself.
Of course, these are same people you'd want managing these AI agents in the first place, but reviewing code written by others always kind of sucks, especially when it's assumed the language model knows better than you do which isn't often the case!
Was the PRD perfected on the requirements? Only God knows, and I personally want to be there when it's written.
So picking languages for their compilation and especially runtime properties is key.
What I've learned, though, is that languages with reckless error handling produce more errors at runtime. My Rust programs just don't crash because I don't need it to be explicit about reaching a "total" approach.
If you're in a C# environment, I see a case for F#. And if you want fast but more solid than Python, why not Mojo? Although who reads code.
This article convinces me. But I suspect like my lack of domain knowledge of Lisp makes me spend time learning the runtime: how and when can I switch to JIT, what's the async story, how does the harness become part of the Lisp program, etc.
It's probably the best language for AI coding though. By far, as far as I can tell.
DSL presumes agreement on semantics, and that's often the most difficult part.
- economies of scale no longer work, and you end up doing a custom ERP for your business from scratch.
- your business changes might invalidate your model quickly. You sell through distributors, but open an online shop -- and suddenly your customer is not one of few dozen well-known businesses with a known address and tax number, but user2252 who bought something late at night last night. And you want to understand the needs and behaviors of both.
- for the economies of scale, you might develop your custom solution 20x faster now, but you're still in competition with the established provides with templates for most of the cases (who btw have the same LLM capability at their disposal)
- for the change in business -- you can ask an LLM which changes this induces, and it will give you most typical impacts. And then you're back at square deciding if it's better to roll your custom DSL and the custom system downstream, or just use off-the-shelf stuff that covers 95% of it from day one (well, maybe day two or three)
When it comes to back office business programming, there’s just a lot of code tasked with copying a litany of bits of data from one structure to another.
Whether it’s copying a web form into a database, or converting Their JSON to Your JSON, it’s a lot of detail that does not abstract well. It’s all shapes and sizes and formats, and it almost always has to be enumerated in excruciating detail and, typically, twice.
Sure, there’s logic and whatnot involved, but it, too, is specific to some subdomain of the larger system and it, too, does not abstract well. Not in the large context of the overall system.
Accounts Payable and Accounts Receivable, at 10,000 feet look almost identical. They’re almost literally the same thing with the sign flipped. But in practice, they don’t share code well. You end up with two similar systems, but not similar enough where sharing is actually worthwhile.
At best they can leverage a common API to the GL.
Turns out a lot of languages can manifest a decent level of abstraction. But even then, folks push back.
Consider the love/hate relationship with ORMs. Or the annotation driven markup in Java programs and the underlying “magic” that they enable. Like scribing mystic runes onto things.
Those are both very powerful, yet folks experience that and toss their hands in the air and throw out the baby with the bath water and jump into something “magic free” like Go.
Just because you can use something like CL to “make your own magic”, doesn’t mean it’s a good idea. Doesn’t mean it scales. Doesn’t mean it communicates well to others. AI or no.
It’s not the AIs world yet. We already know that if the AIs want a better language suited to AI efficiency, they’ll come up with their own. I’ve already seen crass examples of “code only an AI could love”. Completely impenetrable, at least to me. May as well have represented it as a color image and collection of RGB values. Opaque to me, but the AI could “read” it.
There is much more to programming and systems than token density, and AI is still getting cheaper by the day, so less reason to even pre-optimize for it anyway.
While I am extremely taken with Lisps and the lisp way of doing DSLs, I would probably go with an OCaml to make a DSL for a company specific ERP. It seems a better way to go about the problem.
Lisp, on the other hand, I have found to be extremely good at domains which seem the same but which are tremendously different. For example, a workout app is a surprisingly complex domain. Different exercises have different storage models and functions, as do different training sessions and different programs. Rather than try to build a monoprogram, one training app to rule them all, I find lisp wonderful for making "microprograms".
This bears resemblance to Accounts Payable and Accounts Receivable but I don't think Lisp would be a good fit for those. Perhaps a Lean or a Rocq, something with proofs.
> We already know that if the AIs want a better language suited to AI efficiency, they’ll come up with their own.
My agents seem to really like Tree Calculus and have bullied me into working on a language which uses it.
Also, in most languages an error will crash your program. So if you’re writing code with an LLM it will have to read your crash logs to make some changes and run your program again. 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.
Now, if your entire server is taken down because one connection threw an exception, that's bad design. But pretty much no major language works that way. All of them allow you to set things up so that an exception handling connection A won't affect connection B. And if you've done that in Common Lisp, then connection A halting and waiting for the debugger won't affect connection B either.
Anyway it sounds like this isn't really the target use case for the debugger since restarting a webserver is supposed to be easy. Maybe there's a different use case in mind?
Also of course the default is to not get the debugger but let the server thread crash and print the backtrace. With a user setting, you can choose to get the debugger, and have this request wait (the connection may time out, which isn't an issue during development). Another setting is to print the backtrace in the browser (= dev mode).
Python REPL and CL's are very different!
In CL: you can install new dependencies from the REPL. You can change a class definition, the existing objects will take the changes at the next invocation. You can control how this happens, etc. TLDR; CL is built around live programs. Buuut we can also do it the dumb (and safe) way following the industry's best practices.
Yes. I code Python in Emacs with the ancient Python support for running a REPL, loading buffers, editing a function and just hot reloading the modified function, etc.
I am an old man, and I like old man tools :-)
> can be useful in extreme situations
it's already useful in development, it's one of those things that shorten the dev loop and make development in CL a breeze. For production, you choose. Connect to the live image to inspect the state without modifying anything or debug while it's live.
> recorded nowhere
you can connect to a running program and have the source under VCS. The thing to do isn't to copy-paste new function definitions in the live image's REPL, but to connect to the image, make changes to the source files, and re-compile them (a C-c C-c in Slime) (sending changes to the running program).
> safer
yep, some things are safer. Advanced features are useful even for simple things (introspection, etc).
https://comp-348.github.io/lisp-debugging.html has an example of what it looks like. A toy example, to be sure, but the basics of a real example would still look the same. You're given a choice of several options, very reminiscent of the "Abort, Retry, Ignore?" choice that used to be oh-so-familiar in the days of DOS. Except this one is more useful, because it offers ways to specify how to resume. E.g., the toy project is halting on a `(print X)` call where the value of X is not defined. And the choices are:
0. Continue. (Retry using X).
In the toy example, this would fail, because nothing else has defined X. But in real code, the name might have been undefined because the data needed to define it hadn't arrived yet, from the database or the filesystem. In which case retrying the statement might work the second time.
1. Use-value. (Use specified value).
This one prompts you to enter a value for the undefined variable, and continues, but it does not modify the value of X in the program. The next time the program tries to use X, it will halt again with another "unbound variable" error.
2. Store-value. (Set specified value and use it).
This one, just like Use-value, will prompt you to enter a value to use... but then it will set X to that value and continue running the program. Next time the program tries to read the value of X, it will have one, and the program won't halt.
3. Abort. (Exit debugger, returning to top level).
This is what you would choose if there's no good way to fix the error, and you just have to quit the program and restart. Though note that choosing this option isn't going to exit the program you're debugging, just take you out of the debugger. You'll still need to kill-and-restart it some other way... or come back an hour later when the value is finally available, and then choose options 1 or 2.
Hopefully that gives you a taste for what the CL debugger is like to use in practice.
And it's not editing files on the server, it's actually reaching into the running code and tweaking its values.
That, I think, is the difference here. In many languages, the debugger can pause on the exception and let you inspect the code. But in every other language I've used, once you edit the code to fix the bug, you can't resume from where the debugger paused. You have to recompile the code and resume from the top. In CL, you can resume from exactly the state you were in when the debugger paused, only this time with the correct data in place. (Or even with a code fix having been applied, live, to the code).
Second, other languages can also do that, Java for example has facilities to recompile functions and then rewind the stack to run the function again from the beginning of it. Dart also does that even better and people use that extensively in Flutter with hot reloading. I do that in a debugger during tests though, never seen it done in prod.
So, in practice, it might look like you hit any kind of runtime failure, and then the LLM writes some code to fix it, and the user's request completes successfully with no errors.
1. Have you had much success w/moar macros in the age of the LLM? I've been impressed by the models' ability to write good ones, but I can tell my taste/judgement for macros isn't quite there. But they tend to be pretty good at writing gnarly ones, and I would love to work more macros into my workflow. Would love your thoughts. (Have I taken "Simple Made Easy" too far and left macro value on the table?)
2. Do your models ever get confused with image-based dev, and state? It's seemed dumb to me to have models keep running `sed` to change files, but it is nice to have a human-readable, filesystem-backed record of definitions. Would love to hear your experience here.
I've seen a big improvement in LLMs writing macros since Opus 5.5 came out. What really helps I think is that I've written skill files with my own examples and instructions.
Same thing for image-based dev. without an agent.md file with good instructions on how to work with a live image it will do dumb things. this sort of workflow is jsut so far off the training distribution.
I think what changed recently isn't that LLMs got better at CL, they just got way better at taking my skill/agent.md files and reasoning through them.
There shall be one minimal, ultra-hardened, tiny attack surface, "majority gate" picking the answers that most implementation agrees on.
This shall not only detect a great many implementation issues but also it'll help find security issues and platform defects (say the Common Lisp, Haskell, Rust and Python all agree but the Java one fails: in rare case it'll be due to a JVM bug and finding that out shall be simplified).
Code shall be generated from specs in n languages and ran on n stacks. The gate shall return the answer as soon as a quorum is met and, later on, any bogus answer arriving shall be cause for enquiry.
We'll have such systems, it's just a matter of time.
I'm the author and I share the same philosophy, hahaha, my users told me about this post
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...
Have you looked at adding Formal Specification/Verification to the above checklist?
Lisp isn't some language wild west lacking style and idioms—regardless of whether there's a "go fmt" for it or not. Most open source Lisp code is quite standard and "boring": functions and classes/structs following canonical indentation.
Partly, having to do my own pentesting and red team work instead of using someone else's work that has already been pentested.
From the parent's security standpoint I'm more sympathetic, there's been a lot fewer eyes on CL code, there's no central place to keep track of discovered security issues, and perhaps more vigilance is required against untrusted input compared to other languages. At the same time, every time I've exposed a CL-powered website I've noticed various attempts at e.g. wordpress endpoint discovery and I sleep soundly knowing a wordpress deployment is something I'll never have to worry about or take extra precautions against. Every time I hear about a supply chain attack I also am happy about the choice of CL. (Though in truth it's not to say that such attacks aren't possible, but for various reasons, one of them rather quite embarrassing to the overall ecosystem, pulling a big one off is going to be more difficult.)
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".
Sorry, I'm not impressed. How did that /run/ to the top of HN? [pun intended]
"Vorschusslorbeeren"? A clique of voters?
Boring.
(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)))))))> 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.
To be fair, I love Lisp, I dont do a lot with it, though I'm mostly a fan of Racket which is the most modern one outside of maybe Clojure.
But I'm not positive the juice is worth the squeeze, and this article was unconvincing. I mean if you want macros and terse code and a bigger ecosystem, wouldn't Clojure make more sense?
(not a CL expert here)
Visual Studio has done this since the 90s for C++ code (and C# code for a good while also, just most people have debugger exception catching turned off).
How I know? Back in 2000-2001 we were working on a Dreamcast game with a 3dfx/Glide PC renderer, that 3dfx driver on WinNT was unstable and crashed the machine every 3rd-5th start of the game so being able to edit-continue was a damn lifesaver since a lot of common tweaking of custom stuff outside of what connected to the scripting system could be done at runtime.
This is one thing I think so makes people loyal to MSVC despite it having been behind on standards (gonna be interesting to see if they get reflection up to speed for the 2027 release, GCC's there but not yet Clang).
The leave instruction is required to exit a try, catch, or a filter block. At least last time I read the spec (which is a while ago, but still).
See https://news.ycombinator.com/item?id=23844283 for examples on CL.
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.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
But I find ideas like Carp very attractive.
Still common lisp is designed very good.
CL is very competitive with popular managed languages like C#, Go, Java, etc despite those all getting tens to hundreds of millions in investment while SBCL gets basically nothing (imagine what it could do with serious investment).
Endless article generator.
It's so disappointing to see this repeated everywhere.
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.
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.
“a partial order on a set is an arrangement such that, for certain pairs of elements, one precedes the other. The word partial is used to indicate that not every pair of elements needs to be comparable; that is, there may be pairs for which neither element precedes the other”
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.
Culturally, I feel a place like Valve could make it work but you could turn around and ask why does an org need to be in service to and arrange itself around a tool.
If it were a good programming language people would be using it more at this point.
this applies even to programmers.