November 15, 2005
SLIME Screencast Review
Scott Reynan on the SLIME screencast:
After watching a screencast demonstrating SLIME, or Superior Lisp Interaction Mode for Emacs, I have a much clearer idea of how much I want to use this technology: not at all.
Granted, I skimmed a lot of the fifty-five minute video on creating a morse code translator (and they say Lisp isn't useful). But when the narrator says, fifty minutes in, "this example is so simple that I can just look at it, and I know exactly what is going on," I think it comes very close to a perfect definition of irony. And then at the end, when he tries to quit and everything goes haywire, it's just pure comedy.
Dude. You should have seen ILISP.
SLIME, despite being kind of complicated and somewhat brittle (when a project recommends you use the version from CVS, that's definitely a smell of some kind, code or otherwise), is pretty good and without a doubt the best thing the free Lisps have. I do think the GUI environments provided by some of the commercial implementations remain superior in some ways, but even when using those implementations there are still times that it's nice to have a rich emacs interface.
Posted by jjwiseman at November 15, 2005 11:11 AM
I had to give up on that slime tutorial as well, and that was after really, really WANTING to set up the same sort of thing he had going there. The reason I had to quit? My workstation runs Windows.
I was all psyched up to set up a remote IDE like the Slime tutorial demonstrates, running SBCL on a friend's Linux server and editing locally. Only when I was about three straight hours into trying to get this configured did I discover, the hard way, that the remote file editing feature built into emacs (which a remote Slime relies on) completely fails to work in native-compiled Windows emacs.
I still intend to plug away at Lisp in the future, but trying to get a reasonable Slime environment running on my OS was a ridiculous waste of time. (The free Allegro trial with Lispbox was great for a while, until I tried loading a regexp library and immediately hit the memory limit.) I'm giving up on Slime, at the very least until I have a spare PC to run Linux on at home.
josh g.: do you have an ssh client in your path? that's the main dependency TRAMP has on the outside world.
Running emacs under the cygwin environment works for me...and you get ssh w/cygwin too. Maybe I'm missing something, but I don't see any reason to use the native windows version of emacs instead of the cygwin version.
I didn't at the time. The only TRAMP documentation I could find at the time wasn't very optimistic about making it work in Windows at all.
Googling now does look a bit more promising - looks like I could've used plink.
I still feel like there's some pattern to my frustrations, like everything the Lisp community promotes would magically work if a) I ran Linux and b) I was an emacs wiz. I intend to do a) in the future, and I'm working on b), but it still seems to be shortsighted to expect that of all new Lispers.
Craig: You're probably right, but the problem was that I had no way of knowing that choosing native emacs would turn out to be a bad thing.
"I was all psyched up to set up a remote IDE like the Slime tutorial demonstrates, running SBCL on a friend's Linux server and editing locally. Only when I was about three straight hours into trying to get this configured did I discover, the hard way, that the remote file editing feature built into emacs (which a remote Slime relies on) completely fails to work in native-compiled Windows emacs."
For what it is worth, I got the remote file editing to work in native xemacs for windows, using the putty tools. Sadly, I cannot find any of my config files, nor remember the name of the package for remote file editing... but it goes into detail on how to set it up in windows using the putty tools.
I gave up on the slime movie myself, simply because it was putting me to sleep. I think the most interesting parts were the emacs s-expr editing, which I later stole from Marco's emacs files.
Completely off-topic: I followed the link from the nice warning picture to the Japanese earphones and they look like a B&O knock-off to me. They should sue them... :)
Well, even I am not going to watch a 55 minute video on SLIME. 5 or 10 minutes would be a reasonable upper limit, I think.
Maybe someone can remix the video.
But yeah, using Lisp is harder than people let on. This is why I tend to discourage people somewhat, pointing out to them that advocates tend not to offer a good picture of gotchas.
Tayssir John Gabbour - Indeed, the initial stages of getting Lisp to work with regular things (such as OpenGL) is sometimes quite difficult (especially on Win32, since the Lisp community isn't focused much on it). I think this fact might explain why Lisp advocates are very ... let's say, "overzealous". ;-)
Anyone without a kind of zealous fervour for Lisp would have climbed out of the pool long ago.
I wouldn't say "very overzealous." Just compare them to the average big tech company unwilling to admit defects, except in ways which serve them most. The kind running commercials showing you that Intel CPUs make it seem like Seal's sitting on your couch singing to you.
EnigmaJerk: I used Lisp in a Box, then LispBox 0.6 from Peter Seibel, to work through most of his book. But when I hit the chapter on writing a spam filter, my Lisp choice (Allegro 6.2 free version) broke down as I mentioned above.
I will be very happy when someone writes a solid SBCL port for Windows. Allegro and Lispworks both look great, if you can afford them, but the free versions get annoying. And everything I've heard and read leads me to believe that CLISP is, well, lacking.
I thought the video was very informative. I had been using Slime for a short while, but you never really pick up on some of the useful features simply by reading the documentation.
Also, as far as the general criticism of Slime, I'm a noob, but what out there even compares (for free, of course.) Slime seems incredible to me.
I have had all sorts of fits getting Lisp working under Windows. I hate cygwin, having been bitten by it many times -- it doesn't uninstall! Since a large percentage of the world uses Windows, supporting it might be a good idea. I'd work on porting SBCL myself, but it's mainly implemented in Lisp... You see the circular problem. The gotchas in the Lisp world seem to be in the implementations, not in the language. Implementation work just needs more people, but people aren't going to join up until they can work in an environment that works for them. Yet another circular problem...
If "real" Lispers want to make Lisp take over the world, they need to get a free Windows Lisp environment working. Then they can go back to their Linux/Emacs world and be happy whilst Windows programmers take over the Windows work. Until then, Lisp will remain a sidelight in the the world of mainstream development.
Out of curiosity are there similar screencasts for Java/Eclipse, C#, etc?
Porting SBCL (which is indeed mainly implemented in Lisp) is not difficult because of the "implemented in Lisp" part: the vast majority of that Lisp is portable, ANSI Common Lisp. The difficult bit in a port to Windows is in the Operating System interface, which is mostly written in C and assembler.
(As for "take over the world", why should I care about that? Unless the extra people working on SBCL that a Windows port brings in have a greater effect than the number of people desiring free support, a Windows port is utterly useless, if not worse, from my point of view; judging from the dynamics of the existing, functional Windows port of SBCL, the number of people willing to put in any effort to work towards their own goal is minimal at best.)
josh g., et al.,
Here's how I make SLIME work over an SSH tunnel in Windows.
You still need a unix box somewhere running some Lisp; I mainly use this to connect to our development (or production, on occasion) server from my Windows box at home, so I include bonus instructions on getting Tramp to tunnel through firewalls.