[vindarel]

Common Lisp can compete with Python no problem, that's what matters to me. You get:

- truly interactive development (never wait for something to restart, resume bugs from any stack frame after you fixed them),

- self-contained binaries (easy deployment, my web app with all the dependencies, HTML and CSS is ±35MB)

- useful compile-time warnings and errors, a keystroke away, for Haskell levels see Coalton (so better than Python),

- fast programs compiled to machine code,

- no GIL

- connect to, inspect or update running programs (Slime/Swank),

- good debugging tools (interactive debugger, trace, stepper, watcher (on some impls)…)

- stable language and libraries (although the implementations improve),

- CLOS and MOP,

- etc

- good editor support: Emacs, Vim, Atom/Pulsar (SLIMA), VScode (ALIVE), Jetbrains (SLT), Jupyter kernel, Lem, and more: https://lispcookbook.github.io/cl-cookbook/editor-support.ht...

What we might not get:

- advanced refactoring tools -also because we need them less, thanks to the REPL and language features (macros, multiple return values…).

---

For a lisp machine of yesterday running on Ubuntu or the browser: https://interlisp.org/

[Capricorn2481]

> self-contained binaries

But Lispworks is the only one that makes actual tree-shaken binaries, whereas SBCL just throws everything in a pot and makes it executable, right?

> good editor support: Emacs, Vim, Atom/Pulsar (SLIMA), VScode (ALIVE)

I can't speak for those other editors, but my experience with Alive has been pretty bad. I can't imagine anyone recommending it has used it. It doesn't do what slime does, and because of that, you're forced to use Emacs.

Calva for Clojure, however, is very good. I don't know why it can't be this way for CL.

[vindarel]

Maybe you tried some time ago? This experience report concludes by "all in all, a great rig": https://blog.djhaskin.com/blog/experience-report-using-vs-co...

> The usage experience was very ergonomic, much more ergonomic than I'm used to with my personal CL set-up. Still, the inability to inspect stack frame variables would bother me, personally.

I don't use them, but I'd recommend Pulsar's SLIMA over the VSCode plugin, because it's older and based on Slime, where ALIVE is based on LSP.

> But Lispworks is the only one that makes actual tree-shaken binaries, whereas SBCL just throws everything in a pot and makes it executable, right?

right. SBCL has core compression, so as I said a web app with dozens of dependencies and all static assets is ±35MB, that includes the compiler and debugger (that allow to connect and update a running image, whereas this wouldn't be possible with LispWorks' stripped down binary). 35MB for a non-trivial app is good IMO (and in the ballparks of a growing Go app right?)

There's also ECL, if you rely on libecl you can get very small binaries (I didn't explore this yet, see example in https://github.com/fosskers/vend)

[Capricorn2481]

I will check out your courses to see if I can learn something from you.

> Maybe you tried some time ago? This experience report concludes by "all in all, a great rig"

No, I've read that article before. Not being able to inspect variables in the stack frame kills a lot of the point of a REPL, or even a debugger, so I wouldn't use Alive (and most people don't). But the article represents this as a footnote for a reason.

Listen, I like Lisp. But Lisp has this weird effect where people, I think in an effort to boost the community, want to present every tool as a viable answer to their problems, no matter how unfinished or difficult to use.

In Clojure, if people ask what platforms it can reach, people will often say "anywhere." They will tell you to use Flutter through Clojure Dart (unfinished) or Babashka (lots of caveats to using this if all you want is small binaries in your app). Instead of talking about these things as tools with drawbacks, they will lump them all together in a deluge to give the impression the ecosystem is thriving. You did a similar thing in listing every editor under the sun. I doubt you have tried all of these extensively, but I could be wrong.

Same with ECL. Maybe you want the advantages of LISP with smaller binaries. But ECL is slower, supports fewer libraries, and cannot save/dump an image. You're giving up things that you don't normally have to give up in other ecosystems.

But this evangelism works against LISP. People come in from languages with very good tooling and are confused to find half the things they said would work does not.

[vindarel]

> I will check out your courses to see if I can learn something from you.

Thanks. Don't hesitate to reach out and give feedback. If you're into web, you might find my newer (opinionated) resource helpful: https://web-apps-in-lisp.github.io/

> Listen, I like Lisp. But Lisp has this weird effect where people, I think in an effort to boost the community, want to present every tool as a viable answer to their problems, no matter how unfinished or difficult to use.

I see. On social media comments, that's kinda true: I'm so used to hear "there is no CL editor besides Emacs" (which is literally plain false and has been for years, even if you exclude VSCode), and other timeless FUD. Articles or pages on community resources (Cookbook) should be better measured.

> listing every editor under the sun.

there's an Eclipse plugin (simple), a Geany one (simple), a Sublime one (using Slynk, can be decent?), Allegro (proprietary, tried the web version without color highlighting, surprising), Portacle and plain-common-lisp are easy to install Emacs + CL + Quicklisp bundles…

some would add CLOG as a CL editor.

BTW the Intellij plugin is also based on Slime. Not a great development activity though. But a revolution for the Lisp world if you think about it. Enough to make me want mention it twice or thrice on HN.

> tried them extensively

emphasis on "extensively", so no. SLIMA for Atom/Pulsar was decent.

> ECL… slower…

true and for this I've been measured, but looking at how vend is doing would be very interesting, as it ships a very small binary, based on libecl.