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