I’ve used all of these semi-extensively (slightly less so LW). The environments you get with FL and LW are useful if you aren’t an experienced Emacs user, and each of the pro ones comes with a lot of useful support (and FL’s amazing but expensive gdb), but these days, if all you want to do is get programming done, and don’t need, or don’t want to pay for a highly supported world-class engineering platform, you can do pretty much everything you want at a lot less cost and weight with sbcl, emacs, amd some calling to python. Libraries. If some multi-millionaire wanted to do the world a solid, they’d buy and open source (and pay for continuing support) for FL.
I'm inclined to try to learn a Lisp, but the tight integration with Emacs is putting me off. I spent a lot of time and effort to learn vim and I'm wondering why a family of languages should be this dependent on a specific editor...
> I'm wondering why a family of languages should be this dependent on a specific editor...
As mentioned by others, its not. But Emacs is also a Lisp runtime. People who are attracted to Emacs eventually learn some Lisp (Emacs Lisp, closer to CL than Racket et al) or were attracted because of Lisp in the first place. As a result, the overlap between CL devs and Emacs users is naturally higher than that for other editors. This translates into people developing more and better tools for their editor, and higher popularity usually translated into more and better tools (with obvious exceptions).
As mentioned by other commenters, SLIME can be used with Vim too, if that's your thing. But just like SBCL, Emacs is kinda of de-facto editor of choice, not by force, but by love of its users :)
I've done the vast bulk of my CL work using just vi. Specifically, I was doing the typical "reload the lisp file" life cycle, rather than the interactive "just redefine this defun" style of development. Even when I used Lispworks, it was "save file, reload it" style of development.
I used CLISP because it had GNU readline. (e) to edit my file, (l) to reload it, and off to the races (I wrote those trivial defuns). No packages, no imports, no asdf. Everything in CL-USER.
I did switch to emacs for one simple reason: tab to reindent. Other than that it was the most basic of emacs use (load file, save file, ^s to search, cmd-XCV for cut and paste, pgup, pgdn). No Sexpr navigation, no buffer juggling, none of that, no lisp integration whatsoever outside of paren matching and the tab to indent.
> why a family of languages should be this dependent on a specific editor...
The language isn't, but SLIME is because emacs isn't just an editor, it's a platform and system that people develop applications on top of. And the community was already there, using emacs, to continue with that option.
It’s not. You can use any editor. Emacs just happens to have a package called slime that helps - I’m told. I’ve been using just lisp+emacs w/o slime for decades. To be clear, except for slime, which as above is optional, any editor will do just fine.
SLIME is a third–party tool that integrates with Common Lisp; it isn’t part of the language. With most Common Lisp implementations you can just use the repl to call (inspect foo) to see what slots foo has and their values. It will probably be a little clunky since drilling down into the details might require you to type numbers at a prompt. Meanwhile SLIME presents the same information in a UI, so you can click on things (or type the numbers if you prefer).
It just happens that SLIME is a pretty well designed UI (the acronym stands for Superior Lisp Interaction Mode for Emacs, so I guess that was the goal). It’s miles ahead of what you get from most other languages, even C++, but most of what makes it so great comes from features that were already present in the language implementations. It also combines very well with other advanced Emacs packages such as Paredit.
Interestingly, SLIME is implemented as a network protocol to allow for remote debugging, so you can implement a new UI for it any way you want. I’ve never used it, but you might check out SLIMV instead. https://www.vim.org/scripts/script.php?script_id=2531
I have an article I wrote about how I did this, but may have lost it to time.
The short version is I have SLIME running inside Emacs, and my text files open in vim. I would just reload the changed file(s) when needed (originally with cl:load-file, then later with asdf, which is roughly "make" for lisp). I used slime similarly to how I would use gdb. It was a big improvement over using vim with the clisp[1] REPL both because SLIME was more powerful than the clisp repl, and because it worked with other implementations like CMU CL (which sbcl now is a fork of).
I mostly just used the menus for interacting with emacs, but since the shortcuts are listed beside commands, I did learn the more commonly used ones.
I continued like this for years until I discoveredevil-mode[2], which was the first thing close enough to vim to be usable for me (and even then I had to add a few keybindings that it was missing).
1: clisp is a specific implementation of common lisp, not an abbreviation
To provide a bit more context, most of SLIME is just Common Lisp code (https://github.com/slime/slime), with a bunch of Emacs Lisp code alongside to support interfacing with Emacs. But you don't need that Emacs Lisp code to take advantage of almost all of the functionality SLIME provides. For instance, if you want to know who-calls a function, there's some command in emacs to do it, but all that command is doing is just a bit of elisp code which sends a message to Swank (a server running inside Common Lisp) and Swank invokes some native CL code to figure that out and return the results, then finally a bit of elisp code presents the results in some way. Vim can do the same thing just fine with vimscript/python (what the Slimv plugin uses) or otherwise, the bulk of the work in figuring out the list of callers of some function is done by the CL code (and CL implementation itself).
This does not look like SLIME. It seems to be just copying the text from one text buffer and pasting it to another Vim buffer which is running a REPL. That is not what SLIME is really! I can't even call this a poor imitation of SLIME because it is not SLIME in any sense of what SLIME is. There is no Swank server this connects to. There is no understanding of Lisp's s-expressions. It would happily copy any random text into any random REPL and call it job done! It is weird that they have chosen the name "SLIME" for vim-slime project when it is not SLIME in any way.
Def didn’t mean that. I use sbcl+emacs all the time. It’s my go to platform. I’ve used FL and LW but don’t need them. SBCL+emacs is all you really need. (I started lisping before slime so never really got into it. If it’s half as good as folks claim then maybe square all of the above. But someone else will have to chime in on that.)
Although Franz Inc supported Franz Lisp and developed Allegro Common Lisp, it is my impression they are distinct implementations. I can't find any hard evidence one way or another. Do you know?
A think FL just morphed into ACL by renaming, and probably some code changes, but not reimplementation, but not having been there, I’m not 100% sure. Since then, of course, it’s essentially a different implementation bvo many revs.
Unfortunately I’ve rolled my own ugly python ffi just to use python libraries. It’s slow as frozen honey bcs it gets to the great python libraries by slogging through python itself to do the data (de)muxing. That millionaire I mentioned should figure out how to get sbcl to call to python packages directly.
