6 ms·

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 edit

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 6mo ago
There is an explanation in the blog: https://coalton-lang.github.io/20260424-mine/ 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 6mo ago
  Why would a non-programmer want to download, install and run a CL IDE?
  - aidenn0 6mo ago
    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.
    - dajt 5mo ago
      I think the number of non-programmers who think 'I want to learn to program; I'll start with common lisp but emacs is too difficult!' is so small it is not a group worth considering. It's probably MIT & Stanford undergrads? It's their IDE and they can design it how they want, but that's a weird goal for a CL IDE.
      - mepian 5mo ago
        You haven't seen the Lisp subreddit then, there is a post complaining about having to learn Emacs at least once every week or so.
        aidenn0 5mo ago
        I personally suspect that the overwhelming majority of those complaining would find a different reason to not learn lisp if the Emacs barrier were removed, but I very much might be wrong.
        chiffaa 5mo ago
        I wanted to avoid Emacs so I discovered Lem (so now I live in a different Emacs when writing CL), so it's not always this way
      - reikonomusha 5mo ago
        "It should be easy enough for" sets a UX bar, not a target audience. Kind of like the English phrase "X is so easy that even a toddler could do it," regardless of whether such a statement is figurative or literal.
- dasyatidprime 6mo ago
  > 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!
  - Oreb 5mo ago
    I vaguely remember that there was also TRES. EINE = Eine Is Not Emacs ZWEI = Zwei Was Eine Initially TRES = Tres Replaces Eine’s Successor
    - v9v 5mo ago
      DREI = DREI Replaces EINE's Inheritor https://mcclim.common-lisp.dev/static/documents/drei.pdf https://mcclim.common-lisp.dev/static/documents/drei.pdf
bitwize 6mo ago
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 6mo ago
  I love Iosevka. I use it as my monospace, serif and sans-serif fonts and it's gorgeous, in its own unique way.
reikonomusha 5mo ago
Coalton is also a full-featured embedded 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. 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 that shows Coalton type hints, but not much more: https://github.com/slime/slime/blob/master/contrib/slime-coalton.el https://github.com/slime/slime/blob/master/contrib/slime-coa... [2] https://pypl.github.io/IDE.html https://pypl.github.io/IDE.html
Marcello222 5mo ago
Everybody has its own preferences. I have tried it out (linux, command line version) and I can report: Mine is really fast and responsive compared to other Lisp IDEs like emacs which appears to be slow like a snail in comparison.

mepian 6mo ago

There is an explanation in the blog: https://coalton-lang.github.io/20260424-mine/ 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 6mo ago
Why would a non-programmer want to download, install and run a CL IDE?
- aidenn0 6mo ago
  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.
  - dajt 5mo ago
    I think the number of non-programmers who think 'I want to learn to program; I'll start with common lisp but emacs is too difficult!' is so small it is not a group worth considering. It's probably MIT & Stanford undergrads? It's their IDE and they can design it how they want, but that's a weird goal for a CL IDE.
    - mepian 5mo ago
      You haven't seen the Lisp subreddit then, there is a post complaining about having to learn Emacs at least once every week or so.
      - aidenn0 5mo ago
        I personally suspect that the overwhelming majority of those complaining would find a different reason to not learn lisp if the Emacs barrier were removed, but I very much might be wrong.
        chiffaa 5mo ago
        I wanted to avoid Emacs so I discovered Lem (so now I live in a different Emacs when writing CL), so it's not always this way
    - reikonomusha 5mo ago
      "It should be easy enough for" sets a UX bar, not a target audience. Kind of like the English phrase "X is so easy that even a toddler could do it," regardless of whether such a statement is figurative or literal.
dasyatidprime 6mo ago
> 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!
- Oreb 5mo ago
  I vaguely remember that there was also TRES. EINE = Eine Is Not Emacs ZWEI = Zwei Was Eine Initially TRES = Tres Replaces Eine’s Successor
  - v9v 5mo ago
    DREI = DREI Replaces EINE's Inheritor https://mcclim.common-lisp.dev/static/documents/drei.pdf https://mcclim.common-lisp.dev/static/documents/drei.pdf

bitwize 6mo ago

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 6mo ago
I love Iosevka. I use it as my monospace, serif and sans-serif fonts and it's gorgeous, in its own unique way.

reikonomusha 5mo ago

Coalton is also a full-featured embedded 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. 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 that shows Coalton type hints, but not much more: https://github.com/slime/slime/blob/master/contrib/slime-coalton.el https://github.com/slime/slime/blob/master/contrib/slime-coa... [2] https://pypl.github.io/IDE.html https://pypl.github.io/IDE.html

Marcello222 5mo ago

Everybody has its own preferences. I have tried it out (linux, command line version) and I can report: Mine is really fast and responsive compared to other Lisp IDEs like emacs which appears to be slow like a snail in comparison.