Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mine, an IDE for Coalton and Common Lisp

coalton-lang.github.io

Post reply on HN
Print view View original

21–30 of 58 posts

Re: Mine, an IDE for Coalton and Common Lisp

#21

Post by skydhash »

bitwize wrote: post #18
vfclists wrote: post #16

Earlier quoted context omitted.

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…

You can always start the REPL on its own and start playing that way.

Or use something like:

  sbcl --load
Sly/Slime is not essential to play around with Lisp. Emacs just has the right architecture for an REPL workflow. You can do REPL development with Sql and various other programs in Emacs.

Re: Mine, an IDE for Coalton and Common Lisp

#22

Post by wild_egg »

bitwize wrote: post #17
threethirtytwo wrote: post #6

[flagged]

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.

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.

Re: Mine, an IDE for Coalton and Common Lisp

#23

Post by Jach »

bitwize wrote: post #12

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 d…

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.

Re: Mine, an IDE for Coalton and Common Lisp

#24

Post by threethirtytwo »

bitwize wrote: post #17
threethirtytwo wrote: post #6

[flagged]

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.

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.

Re: Mine, an IDE for Coalton and Common Lisp

#25

Post by threethirtytwo »

eikenberry wrote: post #11
threethirtytwo wrote: post #8

Earlier quoted context omitted.

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.

You are being downvoted for calling IDEs and text editors legacy, which is seen as signalling and not contributing to the conversation.

Oh one Adjective "legacy"? And that threw people off? Ok replace that with "cool" and I wouldn't get downvotes? Geeze

Re: Mine, an IDE for Coalton and Common Lisp

#26

Post by threethirtytwo »

girvo wrote: post #13
threethirtytwo wrote: post #6

[flagged]

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

Re: Mine, an IDE for Coalton and Common Lisp

#27

Post by dajt »

mepian wrote: post #5
MarsIronPI wrote: post #3

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. No…

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. >…

Why would a non-programmer want to download, install and run a CL IDE?

Re: Mine, an IDE for Coalton and Common Lisp

#28

Post by girvo »

threethirtytwo wrote: post #26
girvo wrote: post #13

Earlier quoted context omitted.

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

I do the same, but 3-4 is simply too many. I would guess you’re smarter than me, because more than 2 and I’m already at a fixed bottleneck of reviewing it (and reviewing my teams output on top)

Re: Mine, an IDE for Coalton and Common Lisp

#29

Post by dasyatidprime »

mepian wrote: post #5
MarsIronPI wrote: post #3

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. No…

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.

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!

Re: Mine, an IDE for Coalton and Common Lisp

#30

Post by iLemming »

bitwize wrote: post #17
threethirtytwo wrote: post #6

[flagged]

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.

Post reply on HN