Huh, I wonder why they made their own IDE instead of integrating with Sly/SLIME. Not trying to knock the project, just genuinely curious. Writing a whole editor sounds like a lot of work.
I like the choice of Iosevka as a font, though.
Edit:
One value I do see myself getting from Mine is as an example Coalton project. Last time I tried Coalton I couldn't figure out how to get ASDF to load standalone Coalton files. Now I have a working example to copy.
Coalton is also a full-featured sub-language of Lisp that is sufficiently paradigmatically different than run-of-the-mill Lisp code you'd see in a Common Lisp textbook, since it has a complete, Haskell-like static type system and Lisp-1 naming. (While managing to be embedded in Common Lisp itself...) Coalton also sees active development because aspects of the language continue to evolve.
The consequence is that an integration with SLIME would have to be a very extensive contrib [1] that is shipped with the Coalton version the user is using, and updated whenever Coalton is updated. No doubt the contrib would have to be very elaborate—it would have to hook in to basically every aspect of SLIME and SWANK if it should be "Coalton-native", from the display of type errors to how auto-complete is handled. Unless the contrib author is very meticulous about backward compatibility, then version mismatches would make everyone involved unhappy. The contrib author would get annoyed at constant bug reports about things not working (even if there's a nice "your Coalton or contrib are out-of-date" error), and users would get annoyed they have to keep a Lisp library in sync with an Emacs add-on.
None of this gets to the matter that Emacs simply isn't a popular text editor, and it's not really the one people are rushing to learn, even if it has substantial merit. I don't know how trustworthy this source is [2], but it claims that Emacs represents a fraction of a percent of the developer community. Even if it's off by 10x, it's still 1-in-50 developers at best.
> However, the above is a tall order for someone just wanting to dip their toes in, to see if they have any interest in Coalton or Common Lisp. A couple hours on the weekend is easily sunk into getting configurations right, and the right subsystems installed, and the right paths setup, just so the first line of code can be executed.
> mine is not Emacs. It aims to eliminate all of that, and be a Coalton/Lisp-first development environment, whose only job is to be a Coalton/Lisp-first development environment. But more than that, it needs to be accessible. A non-programmer should find it easy to download, install, and run mine with nothing more than a download link.
Iosevka is the king of scalable terminal/programming fonts. I'm not sure why, maybe it's because the glyphs have lines and angles that look "terminal-y" in the same pleasing way Terminus and the 3270 font do whilst avoiding the problems that accompany trying to scale a pixel font.
Interesting! Looks like the IDE itself is written in Coalton (https://github.com/coalton-lang/coalton/tree/main/mine) and you can either bring your own terminal or use the standalone version which uses Tauri and Xterm.js.
I live in Emacs, but I will give Mine a try when get a free hour. I read about Coalton in X and follow the author but I haven't invested time yet to try out.
If you're a power user, the sooner you learn Emacs the better as the synergies with any Lisp language (particularly Common Lisp) are simply too strong to be ignored and there is no contemporary alternative that rivals it.
For new users, this looks like a welcome alternative to messy things like Lem that never really worked very well for me.
Emacs on native Windows has to go through the Win32 API for everything - file I/O, process spawning, subprocesses. Packages that shell out constantly (lsp-mode, magit, etc) will feel sluggish because spawning processes on Windows is genuinely slow compared to Unix. The more shell-heavy your config, the worse it gets. This isn't really Emacs' fault.
I really don't understand devs still insisting on running Emacs on Windows natively. Come on, guys, WSL2 been around like forever. You get real fork/exec speeds, proper shell integration, the full Unix toolchain, etc. Why choose inflicting pain instead of a trodden, well-known, existing path?
Lem did used to advertise itself as specifically a Common Lisp development tool, but that has changed relatively (past year?) recently. From my distant vantage point, it looks like general interest in it grew, and Lem itself further developed in general-purpose directions, and so they eventually pivoted the messaging to be able it being a general-purpose editor instead of specifically a Common Lisp one.
I keep hoping the Common Lisp community will step up and deliver better Visual Studio Code support. Asking new devs to learn Emacs, alongside all of Lisp's idiosyncrasies, is too tall an order. I bro'd through it in the 90s but today's new devs have been spoiled by modern UIs (and that's a good thing) and shouldn't have to cope with Emacs and its stubborn retroness.
Seeing something like this is a step in the right direction.
> will step up and deliver better Visual Studio Code support.
In order to understand what it means to have true Lisp support in an editor/IDE, you have to understand what Lisp is about. Lisp is not just a syntax - it is a live, interactive, self-modifying computational environment. VSCode, like most editors, treats code as text files and execution as a subprocess you invoke. That model is fundamentally at odds with how Lisp development works.
Yes, there are some extensions like Calva and Joyride that attempt some serious work - but the host editor's mental model is always pushing back. So really it ain't about syntax highlighting, bracket matching, and a REPL pane you can type into.
That is something that "new devs" don't understand about Emacs. It's not about the features, nor about its looks - it's about what fundamentally it is - the Lisp REPL - a live, interactive, self-modifying computational environment. Something that VSCode could never truly become. I could never write some code in some scratch buffer, eval it and change some aspect of my editor - in Emacs, I can. And I wouldn't even have to save that code anywhere. In order for VSCode to become like that, you'd have to break its fundamental model, which causes it to become something else - not VSCode.
Therefore, if someone has no interest in Lisp just because VSCode doesn't support it nicely, well, honestly - it's their loss. You know, just because a megacorporation threw billions at developing it, it doesn't mean it's objectively better - there are still other, more pragmatic alternatives. F-35s that cost $1.7 trillion may look shiny and intimidating, but when it comes to the "real deal" - much cheaper, ugly, purpose-built, A-10 Warthog proves its worth, and does it so well that the Pentagon just can't seem to be able to retire it.
Yeah, I mean there is some support for various editors (https://lispcookbook.github.io/cl-cookbook/editor-support.ht...) including VS Code (https://lispcookbook.github.io/cl-cookbook/vscode-alive.html), but it's kind of rough (https://blog.djhaskin.com/blog/experience-report-using-vs-co...) and not exactly feature-complete with the emacs experience, plus you're still left having to figure out how to install and setup a Lisp implementation and quicklisp. I like that mine solves those for a newcomer, especially on Windows. (I myself use vim + slimv, but even that isn't quite at parity in some respects with emacs. The biggest weaknesses are around debugging, especially in the presence of multiple threads. But the essentials do work (stepping, eval-in-frame, continuing-from-a-stack-frame, selecting the various types of restarts, compiling changes before selecting restarts) so I'm still fairly productive and don't feel like I'm lacking anything sorely needed for professional work. I've hacked together some automatic refactoring bits as well, which emacs doesn't have either, and I'm eventually going to make a separated GUI test runner.)
I've been kicking the tires with mine a little bit yesterday and today, I think it's quite good for the beginner experience. But I'm constantly of two minds about reporting some feature requests. The project's primary goal seems to be existing as a stepping stone to even see what Lisp (and especially Coalton) is really all about before "graduating" to something like emacs, it feels like a secondary goal (though it is mentioned as a goal) to be usable by professionals as well, but there's inherent tension there. That's also been a weakness with the other editors: anyone already comfortable with Lisp development, professional or not, in emacs or not, isn't very likely to give the time of day to some new thing that's almost certainly not going to be as good as what they're used to. And so the new thing doesn't get the attention and feedback from experienced developers and the gap never closes.
> today's new devs have been spoiled by modern UIs (and that's a good thing) and shouldn't have to cope with Emacs and its stubborn retroness.
Two words: Programmable editor.
One of the best advantages of Lisp is the ability to metaprogram. After solving a problem, you find that your code can fit other cases and then you you write a program that will produce the relevant code for those cases. In most other PL you would have to write the slightly different code again or use a template language.
Once you get accustomed to that, you will start to decompose other parts of your workflow in smaller building blocks and realize that only a few parts differ, but they all fits the same workflow. And one of the main realization 99% of them are text, act on text, and produce text. So what you really need is a framework around text, not a bespoke assemblage of tools.
With Unix, you have the text processing tools and vi (some would say ed). All centered around the terminal, the shell and files. Emacs is another version with a lisp vm, a collection of functions and the buffer as the interface. A third version is acme with buffers and mouse clicks as commands. The idea here is to be able to build small tools that can take care of the misc. things we need to do while writing programs. From navigation to analyzing, from formatting to building, and the myriads things in between.
Modern UIs are good for beginner and light usage. Or if you're lucky, they have your specific workflow neatly packaged in some plugins. But when you get tired of having another helpful "update" messing your muscle memory, or want to establish an efficient workflow with some external program (A CL lisp runtime in your case), that's when the weakness appears.
I'm talking about beginners, not seasoned Lisp hands, most of whom—until the great boomer dieoff occurs at least—are already comfortable in Emacs. If you're still just finding your feet in Lisp, you're not aware enough of its tremendous power to miss it from your IDE. You're just wondering why you have to Escape Meta Alt Control Shift to get anything done instead of, you know, just using the menu and mouse commands and keyboard shortcuts that literally everyone else uses.
As a programmer for over 2 decades, I permanently stopped using IDEs and text editors this year. It’s really cool to see projects support legacy concepts and ideas though. Love this!
Two decades professionally here too (and nearly three in terms of programming as a whole), and I still use ‘em. Reviewing and adjusting, they make for quite a good experience even in agent-first development with the various nice extensions.
Also I still have to write code by hand, because there’s a whole bunch of edits and adjustments that I’m far faster at shrug
>Also I still have to write code by hand, because there’s a whole bunch of edits and adjustments that I’m far faster at shrug
I'm faster too, in general. The thing is now with AI I'm working on at least 3 to 4 projects in parallel. I tell the AI to do an edit and I context switch to something else.
IMHO, It's a better time than ever to develop a new IDE. Just make one that cares deeply about performance (i.e loads instantly, and always has a snappy response). Make features easy to control. Allow me to turn on only the things I care about and to shut the rest off.
I can't even remember the last time I was impressed by the speed of an IDE, though we have more computing power now than ever. I'd love to see someone new come in and wipe the floor with all of the current contenders.
It’s not awkward at all. It’s a fun project and neat. I support these types of projects. I guess I’m being voted down because people hate IDEs and text editors now.
I think it’s wrong to trash this project just because it’s an older concept.
Then you are probably not interested in this work at all. It is meant to develop Lisp—a language whose primary advantage in 2026 is ergonomics to humans, particularly a certain kind of human. If you're doing 100% agentic development, that advantage disappears and you might as well use something popular and statically typed, like Rust or TypeScript.
> If you're doing 100% agentic development, that advantage disappears
I beg to differ. Turns out, Lisp REPL - an actual, "true" REPL, not something like Python's (which is not the same), is an enormous multiplier for agentic workflows.
a) Lisp code can be very terse yet retain its readability - it never becomes cryptic like APL. Therefore, it's more token efficient. It was actually proven that Clojure is one of the most token-efficient "mainstreamish" PLs. https://martinalderson.com/posts/which-programming-languages...
b) When you give an LLM a closed loop system where it can evaluate code in a live REPL and observe the results, it stops guessing and starts reasoning empirically. Instead of predicting what code will do, it can run it, read the output, adjust, and iterate - the same way a skilled human developer works. Incremental evaluation of forms maps naturally to how an LLM generates tokens.
This isn't some theoretical hand-waving - I experience it every day - my WM on Mac is yabai that gets controlled via Hammerspoon, which uses Lua, which means I can use Fennel, which means I can use Lisp REPL. I would give the LLM a task, something to do with my app windows - it connects to the live REPL and starts analyzing, prototyping and poking into things interactively.
All my custom MCPs are written in babashka (Clojure) https://github.com/agzam/death-contraptions - whenever there's a problem or I need to improve my AI harness, LLM just does it from "inside out" and it takes less time and fewer tokens.
My main editor is Emacs - LLM can fully control it. I can make it change virtually any aspect of it. To load-test the MCP that does that, I made it play Tetris in Emacs. And not just to run it, but to play it for real - without losing. It was insane.
And of course, day-to-day I have to deal with non-Lispy, non-homoiconic languages more. And to be honest (even though of course I'm biased in this) static type systems is the exact thing in practice where their advantages feel like stop making any big difference. While Lisp REPL feels far more useful.
Technically, I think this is meant to develop Coalton, which is also statically typed and incredibly effective as a language for agents. All those ergonomic benefits that humans enjoy also allow AIs to develop lisp systems quite rapidly and robustly.
Not true. Are people not interested in archeology or history or museums? Denying such things as invalid is offensive. There are projects to reproduce things from ancient history like the Lycurgus cup.
Huh, I wonder why they made their own IDE instead of integrating with Sly/SLIME. Not trying to knock the project, just genuinely curious. Writing a whole editor sounds like a lot of work.
I like the choice of Iosevka as a font, though.
Edit: One value I do see myself getting from Mine is as an example Coalton project. Last time I tried Coalton I couldn't figure out how to get ASDF to load standalone Coalton files. Now I have a working example to copy.
Coalton is also a full-featured sub-language of Lisp that is sufficiently paradigmatically different than run-of-the-mill Lisp code you'd see in a Common Lisp textbook, since it has a complete, Haskell-like static type system and Lisp-1 naming. (While managing to be embedded in Common Lisp itself...) Coalton also sees active development because aspects of the language continue to evolve.
The consequence is that an integration with SLIME would have to be a very extensive contrib [1] that is shipped with the Coalton version the user is using, and updated whenever Coalton is updated. No doubt the contrib would have to be very elaborate—it would have to hook in to basically every aspect of SLIME and SWANK if it should be "Coalton-native", from the display of type errors to how auto-complete is handled. Unless the contrib author is very meticulous about backward compatibility, then version mismatches would make everyone involved unhappy. The contrib author would get annoyed at constant bug reports about things not working (even if there's a nice "your Coalton or contrib are out-of-date" error), and users would get annoyed they have to keep a Lisp library in sync with an Emacs add-on.
None of this gets to the matter that Emacs simply isn't a popular text editor, and it's not really the one people are rushing to learn, even if it has substantial merit. I don't know how trustworthy this source is [2], but it claims that Emacs represents a fraction of a percent of the developer community. Even if it's off by 10x, it's still 1-in-50 developers at best.
[1] There's a basic one already that shows Coalton type hints: https://github.com/slime/slime/blob/master/contrib/slime-coa...
[2] https://pypl.github.io/IDE.html
There is an explanation in the blog: https://coalton-lang.github.io/20260424-mine/
> However, the above is a tall order for someone just wanting to dip their toes in, to see if they have any interest in Coalton or Common Lisp. A couple hours on the weekend is easily sunk into getting configurations right, and the right subsystems installed, and the right paths setup, just so the first line of code can be executed.
> mine is not Emacs. It aims to eliminate all of that, and be a Coalton/Lisp-first development environment, whose only job is to be a Coalton/Lisp-first development environment. But more than that, it needs to be accessible. A non-programmer should find it easy to download, install, and run mine with nothing more than a download link.
Why would a non-programmer want to download, install and run a CL IDE?
1 reply →
> mine is not Emacs.
Ah… yes, okay, I see what they did there… chuckle, sigh. Well, it's arguably in the same grand cultural tradition as EINE and ZWEI at least!
Iosevka is the king of scalable terminal/programming fonts. I'm not sure why, maybe it's because the glyphs have lines and angles that look "terminal-y" in the same pleasing way Terminus and the 3270 font do whilst avoiding the problems that accompany trying to scale a pixel font.
I love Iosevka. I use it as my monospace, serif and sans-serif fonts and it's gorgeous, in its own unique way.
Interesting! Looks like the IDE itself is written in Coalton (https://github.com/coalton-lang/coalton/tree/main/mine) and you can either bring your own terminal or use the standalone version which uses Tauri and Xterm.js.
I live in Emacs, but I will give Mine a try when get a free hour. I read about Coalton in X and follow the author but I haven't invested time yet to try out.
Very cool project and welcome edition to the CL community!
If you're a power user, the sooner you learn Emacs the better as the synergies with any Lisp language (particularly Common Lisp) are simply too strong to be ignored and there is no contemporary alternative that rivals it.
For new users, this looks like a welcome alternative to messy things like Lem that never really worked very well for me.
Problem is, Emacs is really slow on Windows. If I can get a reasonably fast Lisp IDE on Windows, I'm all for it.
> Emacs is really slow on Windows
Emacs on native Windows has to go through the Win32 API for everything - file I/O, process spawning, subprocesses. Packages that shell out constantly (lsp-mode, magit, etc) will feel sluggish because spawning processes on Windows is genuinely slow compared to Unix. The more shell-heavy your config, the worse it gets. This isn't really Emacs' fault.
I really don't understand devs still insisting on running Emacs on Windows natively. Come on, guys, WSL2 been around like forever. You get real fork/exec speeds, proper shell integration, the full Unix toolchain, etc. Why choose inflicting pain instead of a trodden, well-known, existing path?
Lem doesn't claim to be a Lisp development environment or IDE. It describes itself as
General-purpose editor/IDE with high expansibility in Common Lisp
Lem did used to advertise itself as specifically a Common Lisp development tool, but that has changed relatively (past year?) recently. From my distant vantage point, it looks like general interest in it grew, and Lem itself further developed in general-purpose directions, and so they eventually pivoted the messaging to be able it being a general-purpose editor instead of specifically a Common Lisp one.
I keep hoping the Common Lisp community will step up and deliver better Visual Studio Code support. Asking new devs to learn Emacs, alongside all of Lisp's idiosyncrasies, is too tall an order. I bro'd through it in the 90s but today's new devs have been spoiled by modern UIs (and that's a good thing) and shouldn't have to cope with Emacs and its stubborn retroness.
Seeing something like this is a step in the right direction.
> will step up and deliver better Visual Studio Code support.
In order to understand what it means to have true Lisp support in an editor/IDE, you have to understand what Lisp is about. Lisp is not just a syntax - it is a live, interactive, self-modifying computational environment. VSCode, like most editors, treats code as text files and execution as a subprocess you invoke. That model is fundamentally at odds with how Lisp development works.
Yes, there are some extensions like Calva and Joyride that attempt some serious work - but the host editor's mental model is always pushing back. So really it ain't about syntax highlighting, bracket matching, and a REPL pane you can type into.
That is something that "new devs" don't understand about Emacs. It's not about the features, nor about its looks - it's about what fundamentally it is - the Lisp REPL - a live, interactive, self-modifying computational environment. Something that VSCode could never truly become. I could never write some code in some scratch buffer, eval it and change some aspect of my editor - in Emacs, I can. And I wouldn't even have to save that code anywhere. In order for VSCode to become like that, you'd have to break its fundamental model, which causes it to become something else - not VSCode.
Therefore, if someone has no interest in Lisp just because VSCode doesn't support it nicely, well, honestly - it's their loss. You know, just because a megacorporation threw billions at developing it, it doesn't mean it's objectively better - there are still other, more pragmatic alternatives. F-35s that cost $1.7 trillion may look shiny and intimidating, but when it comes to the "real deal" - much cheaper, ugly, purpose-built, A-10 Warthog proves its worth, and does it so well that the Pentagon just can't seem to be able to retire it.
Yeah, I mean there is some support for various editors (https://lispcookbook.github.io/cl-cookbook/editor-support.ht...) including VS Code (https://lispcookbook.github.io/cl-cookbook/vscode-alive.html), but it's kind of rough (https://blog.djhaskin.com/blog/experience-report-using-vs-co...) and not exactly feature-complete with the emacs experience, plus you're still left having to figure out how to install and setup a Lisp implementation and quicklisp. I like that mine solves those for a newcomer, especially on Windows. (I myself use vim + slimv, but even that isn't quite at parity in some respects with emacs. The biggest weaknesses are around debugging, especially in the presence of multiple threads. But the essentials do work (stepping, eval-in-frame, continuing-from-a-stack-frame, selecting the various types of restarts, compiling changes before selecting restarts) so I'm still fairly productive and don't feel like I'm lacking anything sorely needed for professional work. I've hacked together some automatic refactoring bits as well, which emacs doesn't have either, and I'm eventually going to make a separated GUI test runner.)
I've been kicking the tires with mine a little bit yesterday and today, I think it's quite good for the beginner experience. But I'm constantly of two minds about reporting some feature requests. The project's primary goal seems to be existing as a stepping stone to even see what Lisp (and especially Coalton) is really all about before "graduating" to something like emacs, it feels like a secondary goal (though it is mentioned as a goal) to be usable by professionals as well, but there's inherent tension there. That's also been a weakness with the other editors: anyone already comfortable with Lisp development, professional or not, in emacs or not, isn't very likely to give the time of day to some new thing that's almost certainly not going to be as good as what they're used to. And so the new thing doesn't get the attention and feedback from experienced developers and the gap never closes.
> today's new devs have been spoiled by modern UIs (and that's a good thing) and shouldn't have to cope with Emacs and its stubborn retroness.
Two words: Programmable editor.
One of the best advantages of Lisp is the ability to metaprogram. After solving a problem, you find that your code can fit other cases and then you you write a program that will produce the relevant code for those cases. In most other PL you would have to write the slightly different code again or use a template language.
Once you get accustomed to that, you will start to decompose other parts of your workflow in smaller building blocks and realize that only a few parts differ, but they all fits the same workflow. And one of the main realization 99% of them are text, act on text, and produce text. So what you really need is a framework around text, not a bespoke assemblage of tools.
With Unix, you have the text processing tools and vi (some would say ed). All centered around the terminal, the shell and files. Emacs is another version with a lisp vm, a collection of functions and the buffer as the interface. A third version is acme with buffers and mouse clicks as commands. The idea here is to be able to build small tools that can take care of the misc. things we need to do while writing programs. From navigation to analyzing, from formatting to building, and the myriads things in between.
Modern UIs are good for beginner and light usage. Or if you're lucky, they have your specific workflow neatly packaged in some plugins. But when you get tired of having another helpful "update" messing your muscle memory, or want to establish an efficient workflow with some external program (A CL lisp runtime in your case), that's when the weakness appears.
If Lisp developers want a better editor and IDE they can support Lem.
VS Code doesn't provide the liveness and extensibility Emacs and Lisp developers enjoy in their environments.
Lem is still too Emacs-like.
I'm talking about beginners, not seasoned Lisp hands, most of whom—until the great boomer dieoff occurs at least—are already comfortable in Emacs. If you're still just finding your feet in Lisp, you're not aware enough of its tremendous power to miss it from your IDE. You're just wondering why you have to Escape Meta Alt Control Shift to get anything done instead of, you know, just using the menu and mouse commands and keyboard shortcuts that literally everyone else uses.
3 replies →
As a programmer for over 2 decades, I permanently stopped using IDEs and text editors this year. It’s really cool to see projects support legacy concepts and ideas though. Love this!
Two decades professionally here too (and nearly three in terms of programming as a whole), and I still use ‘em. Reviewing and adjusting, they make for quite a good experience even in agent-first development with the various nice extensions.
Also I still have to write code by hand, because there’s a whole bunch of edits and adjustments that I’m far faster at shrug
>Also I still have to write code by hand, because there’s a whole bunch of edits and adjustments that I’m far faster at shrug
I'm faster too, in general. The thing is now with AI I'm working on at least 3 to 4 projects in parallel. I tell the AI to do an edit and I context switch to something else.
shrug
1 reply →
Same. It's an awkward time to develop a new IDE.
nothing awkward about it.
IMHO, It's a better time than ever to develop a new IDE. Just make one that cares deeply about performance (i.e loads instantly, and always has a snappy response). Make features easy to control. Allow me to turn on only the things I care about and to shut the rest off.
I can't even remember the last time I was impressed by the speed of an IDE, though we have more computing power now than ever. I'd love to see someone new come in and wipe the floor with all of the current contenders.
It’s not awkward at all. It’s a fun project and neat. I support these types of projects. I guess I’m being voted down because people hate IDEs and text editors now.
I think it’s wrong to trash this project just because it’s an older concept.
2 replies →
Then you are probably not interested in this work at all. It is meant to develop Lisp—a language whose primary advantage in 2026 is ergonomics to humans, particularly a certain kind of human. If you're doing 100% agentic development, that advantage disappears and you might as well use something popular and statically typed, like Rust or TypeScript.
> If you're doing 100% agentic development, that advantage disappears
I beg to differ. Turns out, Lisp REPL - an actual, "true" REPL, not something like Python's (which is not the same), is an enormous multiplier for agentic workflows.
a) Lisp code can be very terse yet retain its readability - it never becomes cryptic like APL. Therefore, it's more token efficient. It was actually proven that Clojure is one of the most token-efficient "mainstreamish" PLs. https://martinalderson.com/posts/which-programming-languages...
b) When you give an LLM a closed loop system where it can evaluate code in a live REPL and observe the results, it stops guessing and starts reasoning empirically. Instead of predicting what code will do, it can run it, read the output, adjust, and iterate - the same way a skilled human developer works. Incremental evaluation of forms maps naturally to how an LLM generates tokens.
This isn't some theoretical hand-waving - I experience it every day - my WM on Mac is yabai that gets controlled via Hammerspoon, which uses Lua, which means I can use Fennel, which means I can use Lisp REPL. I would give the LLM a task, something to do with my app windows - it connects to the live REPL and starts analyzing, prototyping and poking into things interactively.
All my custom MCPs are written in babashka (Clojure) https://github.com/agzam/death-contraptions - whenever there's a problem or I need to improve my AI harness, LLM just does it from "inside out" and it takes less time and fewer tokens.
My main editor is Emacs - LLM can fully control it. I can make it change virtually any aspect of it. To load-test the MCP that does that, I made it play Tetris in Emacs. And not just to run it, but to play it for real - without losing. It was insane.
And of course, day-to-day I have to deal with non-Lispy, non-homoiconic languages more. And to be honest (even though of course I'm biased in this) static type systems is the exact thing in practice where their advantages feel like stop making any big difference. While Lisp REPL feels far more useful.
Technically, I think this is meant to develop Coalton, which is also statically typed and incredibly effective as a language for agents. All those ergonomic benefits that humans enjoy also allow AIs to develop lisp systems quite rapidly and robustly.
Not true. Are people not interested in archeology or history or museums? Denying such things as invalid is offensive. There are projects to reproduce things from ancient history like the Lycurgus cup.