For some time now I’ve been intrigued by the claims of its proponents that Lisp is the language that exemplifies elegance and expressiveness. Those are bold claims, and I’ve finally decided to take the plunge and to see what all the fuss is about. So, this is my step down the road; only time will tell if I’ll ever truly "get it".
I find that I learn best by doing, so with the first few chapters of Peter Seibel’s Practical Common Lisp as an introduction, I wanted to get my hands dirty and started putting together a development environment. The Superior Lisp Interaction Mode for Emacs (SLIME) is by far the most popular (free) Lisp IDE, and it is indeed excellent; I have, however, long been more comfortable with Vim and found Larry Clapp’s VIlisp a functional alternative for interfacing with a Lisp interpreter. My search for a (free) Lisp implementation eventually ended with ECL.
My decision to use ECL was based mainly on the fact that it is designed to be used as an embedded library, and can translate Lisp to C to produce a native executable. I see this as a benefit, because unlike Java (which has a rigid JVM and class format specification), Lisp does not require that fasls be portable between implementations, so there doesn’t appear to be a consistent way to distribute Lisp applications in binary form. The binary produced by ECL’s compilation is linked to the ECL library, which means that users don’t need to download an additional package (a Lisp interpreter) to run one’s application. Thanks to Java this is less of an issue now than it once was, but I for one still like to be able to download and use an application without having to hunt down its required framework.
I will, however, be revisiting CLISP and SBCL, which seem to be more user- (read: developer-) friendly Lisp implementations.
But I digress… With a development environment now set up, I embarked on my first Lisp project: an implementation of John Conway’s Game of Life. The source code is available; SDL is needed for the display.
Initially I, like many others, found the proliferation of parentheses a visual distration that hid the actual code. It required a good deal of effort to focus on the code and ignore the parentheses. In a surprisingly short time, however, I began to appreciate the parentheses as visual cues that delimit forms. They started to function as a kind of scope (in the sniper sense) for widening and narrowing my visual focus, allowing me to always concentrate on a specific context. I think the brain tends to focus on what it doesn’t recognise, and the more Lisp code one writes, the less the parentheses will stand out, and the more they will be interpreted as an appropriate visual cue. From my humble and limited experience, if the parentheses are the only thing stopping you from learning Lisp, try to stick with it … It may get better.
In addition to the REPL, I found Lisp’s lambda functions and closures to be an very useful debugging aid. By wrapping a portion of a function in a lambda function, and assigning it to a global variable, that portion of code is made accessible. Using funcall one can execute the lambda function to ensure that the fragment it wraps is behaving correctly. Because the fragment uses the bindings that have been captured by the closure, there’s no need to write test code that injects appropriate test values. Its not a replacement for proper test cases, but its great for ad-hoc verification of a particular piece of code.
I must say again that I’ve barely (if at all) scratched the surface of what Lisp has to offer. However, the little that I’ve seen has whet my appetite and I’m eager to learn more. I’ve only caught glimpses of the after-images left by the lightning bolts cast by Lisp wizards, but there appears to be a great deal of magic out there … and I’m eager to learn more.