[HN Gopher] Mine, an IDE for Coalton and Common Lisp
___________________________________________________________________
Mine, an IDE for Coalton and Common Lisp
Author : varjag
Score : 83 points
Date : 2026-04-25 17:47 UTC (11 hours ago)
HTML web link (coalton-lang.github.io)
TEXT w3m dump (coalton-lang.github.io)
| sctb wrote:
| 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.
| MarsIronPI wrote:
| 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.
| mepian wrote:
| 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.
| dajt wrote:
| Why would a non-programmer want to download, install and run
| a CL IDE?
| aidenn0 wrote:
| 1. It is a potential first step on the way from non-
| programmer to programmer.
|
| 2. "Easy enough for a non-programmer" may also say
| something about how easy it is for a programmer.
| dasyatidprime wrote:
| > 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!
| bitwize wrote:
| 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.
| MarsIronPI wrote:
| I love Iosevka. I use it as my monospace, serif and sans-
| serif fonts and it's gorgeous, in its own unique way.
| reikonomusha wrote:
| 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 type system with Lisp-1 naming. Coalton
| itself 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 "you're 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
| armitron wrote:
| 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.
| vfclists wrote:
| 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
| Pay08 wrote:
| Problem is, Emacs is really slow on Windows. If I can get a
| reasonably fast Lisp IDE on Windows, I'm all for it.
| iLemming wrote:
| > 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?
| threethirtytwo wrote:
| 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!
| greggroth wrote:
| Same. It's an awkward time to develop a new IDE.
| threethirtytwo wrote:
| 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.
| eikenberry wrote:
| You are being downvoted for calling IDEs and text editors
| legacy, which is seen as signalling and not contributing to
| the conversation.
| threethirtytwo wrote:
| Oh one Adjective "legacy"? And that threw people off? Ok
| replace that with "cool" and I wouldn't get downvotes?
| Geeze
| nocman wrote:
| 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.
| girvo wrote:
| 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_
| threethirtytwo wrote:
| >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_
| girvo wrote:
| 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)
| bitwize wrote:
| 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.
| wild_egg wrote:
| 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.
| threethirtytwo wrote:
| 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.
| iLemming wrote:
| > 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.
| mark_l_watson wrote:
| 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.
| bitwize wrote:
| 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.
| vfclists wrote:
| 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.
| bitwize wrote:
| 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_.
| skydhash wrote:
| You can always start the REPL on its own and start playing
| that way.
|
| Or use something like: sbcl --load
| <filename>
|
| 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.
| skydhash wrote:
| > _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.
| Jach wrote:
| 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.
| iLemming wrote:
| > 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.
| arikrahman wrote:
| Very cool project and welcome edition to the CL community!
___________________________________________________________________
(page generated 2026-04-26 05:00 UTC)