I’m starting a series of posts highlighting useful functions in Emacs/SLIME. The idea is to take one function (or a set of related functions) per post. This post is mostly here for reference in future episodes and will explain what SLIME is and why it’s interesting.
What SLIME is
If you’re a Lisp programmer, chances are you’ve seen at least some mentions of SLIME or you’re already using it. If you’re not, you’re probably not familiar with it at all.
Basically, SLIME is an interactive Emacs mode for Lisp programming, “interactive” meaning it interacts with a running program (also called an “image” in Lisp jargon) while you’re building/modifying it. There are similar modes for other programming languages (Perl, for example has at least two) but as far as I know, the concept of real “interactive” programming seems to be mostly confined to Lisp and Smalltalk and people think you’re eccentric if you use it in any other language.
Why interactive modes are cool, or: where I confuse the issue on static vs dynamic. Again.
The static status quo
You’re probably familiar with grand IDEs for “static” languages such as Java and C++ (and if not, you’re either a hardcore “dynamic” language nerd (good for you!) or you’re reading the wrong blog). With typical static languages, the idea is that the compiler will have enough information just from the source text to check variable and argument types, function or method calls, operator application, all available classes etc without running the program. This implies that a sufficiently smart program that isn’t the compiler can do the same. What that means (especially for typical Java code) is that the development system will always know the ins and outs of every function call and type you’re writing and can almost instantly alert you if you’re misspelling a name or using the wrong argument type for a method.
Good IDEs will also use this information to let you rename or restructure functions or classes in your project with automatic updates to all the calls, for example.
The issue with dynamics
All of the above sounds cool. And it is. It just comes at the cost (typically) of having to specify all your variable and argument types, and explicitly importing those types (and the types of each element in a container type, etc) for each source file, which usually means quite a lot of your source text is just made up of type names (classes, for Java). It must be that way, because otherwise the compiler/IDE won’t know what you’re talking about.
This means that for languages that play loose with typing and just allow you to assign any type to any variable, or worse, redefine whatever you like (including method signatures) while the program is running you can’t have any of the goodness that is the “modern IDE”.
Or is it? – The revenge of dynamic languages, or: it was there all along! – sort of
The way interactive modes resolve the problem is actually quite straight forward: instead of parsing all the source text, and then making inferences about it, you can keep the program you’re modifying running and then ask it what’s going on. It’s a technically flawed approach, for many reasons, but (“big but” joke removed) it gets the job done most of the time, and more importantly, it lets the programmer (that’s you) get on with it.
Basically, what you’re doing in this kind of environment is edit one or two functions in the source text, insert the new definitions into the running program and see if it works. Rinse, repeat. While you’re doing that, the editor is keeping track of all the available types and functions/methods. That means you get auto-completion, source navigation etc just like a “real IDE”, but without much of the hassle.
Some pointers as to what you get and with how much hassle are going to be the topics of this series.
All kinds of Lisps
Although I’ve used a bunch of different Common Lisp versions in the past that work with SLIME (mostly SBCL), at the moment I’m pretty much exclusively using Clojure, which is not a Common Lisp, but a fairly new addition to the Lisp language family that you can think of as a streamlined “practical” Lisp-1 if you have to. Any source/screen dumps you see on this this topic will be Clojure code unless notes indicate otherwise.
“Meta” (Emacs jargon)
If you’re running Emacs on Windows or Linux, Meta is most likely the key that’s typically designated “Alt” on your keyboard. On a Mac, it depends on the Emacs build, but it’s probably either [alt/option/⌥] or [command/⌘]. Mainly it’s just a source of confusion, but since the Emacs documentation refers to it throughout as the “Meta” key and I want to keep the actual episodes a lot shorter than this one, I will do so too in this series.
If you’re still curious, the reason it’s called “Meta” is that the original Lisp machines had that key. See the glorious “Space Cadet” keyboard! Marvel at its amazing modifier keys!
Using SLIME with Clojure
http://www.assembla.com/wiki/show/clojure/Getting_Started_with_Emacs should get you started if you want to use Emacs/SLIME for the Clojure language. Note that you should install swank-clojure as well if you want to use the nice SLIME stuff discussed in this series (see the 2nd to last paragraph on that page).
If you’re stubborn, don’t like pre-built packages and/or have your own intricate Emacs configuration like me, figure it out yourself, maybe taking some hints from my personal config.
I don’t like Emacs, but I want to have a decent editor for Clojure code
See the Clojure “Getting Started” page at assembla.
Anyway, hope you find this interesting.
Joost.