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

31–40 of 58 posts

Re: Mine, an IDE for Coalton and Common Lisp

#31

Post by MarsIronPI »

bitwize wrote: post #20
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…

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.

Re: Mine, an IDE for Coalton and Common Lisp

#32

Post by iLemming »

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…

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

Re: Mine, an IDE for Coalton and Common Lisp

#33

Post by aidenn0 »

dajt wrote: post #27
mepian wrote: post #5

Earlier quoted context omitted.

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?

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.

Re: Mine, an IDE for Coalton and Common Lisp

#34

Post by Pay08 »

armitron wrote: post #4

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.

Re: Mine, an IDE for Coalton and Common Lisp

#35

Post by reikonomusha »

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…

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

[2] https://pypl.github.io/IDE.html

Re: Mine, an IDE for Coalton and Common Lisp

#36

Post by iLemming »

Pay08 wrote: post #34
armitron wrote: post #4

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?

Re: Mine, an IDE for Coalton and Common Lisp

#37

Post by reikonomusha »

skydhash wrote: post #21
bitwize wrote: post #18

Earlier quoted context omitted.

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.

Something like SLIME isn't essential to execute Lisp code, you're right, but it is essential in order to understand the efficiencies afforded by interactive development, which may as well be one of the pillars of the language, since "garbage collection" and "an object system" aren't in and of themselves differentiators anymore*. Using something like SLIME also takes a lot of the pains that people have with Lisp away, namely balancing parens and indenting code correctly. People who do the "I'll use my own editor" approach to beginning Lisp usually write things that look like:

    (defun myfun(x)
        (let (x)
             (setq x 5)
              (when (eq x 6)
                  (print "6")
             )
         )
     )
Which is absolutely not what Lisp code should look like. Emacs-and-kin don't outright stop that, but the defaults are such that it's less likely.

____

* Of course, technically, CLOS is something to behold. But you won't sell someone on Lisp because it can do "OOP".

Re: Mine, an IDE for Coalton and Common Lisp

#38

Post by iLemming »

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…

> I'm talking about beginners

If the beginners are curious about Lisp and insist on using VSCode, they can install Calva and try Clojure. It takes less than a minute and it has a really good "quick start" guide. There's no rule that says you have to get into Lisp specifically via SBCL. Once you grok structural editing and REPL-driven workflow, jumping between different Lisp dialects is not that hard.

And if a programmer refuses to learn a new language, technique or paradigm just because their favorite editor doesn't support it... well, that is sad, but also - not everyone has to be passionate about their work, huge sectors of the economy are driven by mediocre players and that is just fine. Passionate programmers sooner or later find their way to Lisp.

Re: Mine, an IDE for Coalton and Common Lisp

#39

Post by reikonomusha »

vfclists wrote: post #10
armitron wrote: post #4

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.

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

For historical interest, Lem did used to advertise itself as a Common Lisp development tool specifically, but that has changed relatively recently (past year?). From my distant vantage point, it looks like general interest in it grew, and Lem itself evolved in general-purpose directions, so they pivoted the messaging to be about it serving as a general-purpose editor instead of one just for Common Lisp.

Re: Mine, an IDE for Coalton and Common Lisp

#40

Post by satiric »

threethirtytwo wrote: post #25
eikenberry wrote: post #11

Earlier quoted context omitted.

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

Yes, you can expect people here to read your comments and judge them by their content. Were you expecting otherwise?
Post reply on HN