Lisp

Tue, 05/25/2010 - 03:15

I now know enough to both like and dislike Lisp.

Lisp (Common Lisp, specifically) has a lot going for it.

The virtues that programmers usually espouse about a language are syntactic. Your Python guys will talk about the absence of unnecessary curly-braces. Your Perl guys will talk about its compactness and the irregular forms which the human brain loves. Your Ruby guys will talk about blocks and yields. And, yes, Lisp guys will talk about the elegance and power of recursion and S-Expressions.

But the virtues that ultimately matter have little to do with syntax - in fact, often they have little to do with the language itself:

  • Is there a good standard library of functions?
  • How portable is the code between different platforms?
  • Is there a standard, robust method of getting and managing dependencies?
  • How easy is the code to modularize?
  • Is there a good testing environment?
  • Is there a good community of developers and FOSS projects?

I want to point out here that Autotools/C++ (the Chevrolet of build environments), paired with a good dependency checker like MacPorts or Apt, has this stuff nailed down. Libraries? #include away. Portable? Most projects are easily portable. Dependencies? port install or apt-get install; autoconf is even pretty transparent as far as dependencies go. Modularization? #includes and header files. Community? You got it. The only case where it fails versus some more contemporary languages is in testing, but there are folks out there working on a Read-Eval-Print-Loop (REPL) for C++.

The reason this stuff exists in spades with traditional Autotools projects and not so much with other languages, I think, is a testament to Richard Stallman's vision (yes, I just used those words without a shred of irony) and the inherent selfishness of a lot of hackers.

When you are writing code, packaging it into a form that can be used by others is often an afterthought. Most code never sees the light of day - one-off tools, dirty hacks, internal scripts and the like comprise a great, silent majority of software. Releasing a binary is risky enough; releasing source code exposes you to public criticism, to be lambasted by a thousand armchair intellectuals and trolls.

But what keeps a project alive - indeed, what keeps a language alive - is communicating it to others and making it easy to include and reuse.

So, coming back to Lisp, almost every aspect of the "peripheral" language ecosystem is absent or kludgy.

First, I wanted to install Lisp. Scheme or Common Lisp? Scheme seemed very academic, and Common Lisp more pragmatic. But even then, there were a variety of implementations. Should I choose Clozure, SBCL, or CMUCL on the CL side? Mzscheme, MITScheme, or Guile on the Scheme side?

So I chose Mzscheme. It installed okay, but after a little hacking I discovered that entire programming constructs - loops, functions definitions, etc - varied between Scheme implementations. This was awful. I gave up almost immediately.

I talked to my buddy Indy, who recommended Common Lisp. It had a more standardized set of core functions and better extensibility. Great. And it had SLIME (Superior Lisp Interactive Mode for Emacs), which, I am convinced, is the best testing environment ever created for any language. And the s-expression syntax, which I initially thought would be insurmountable, turned out to be not that bad. For some things it was even good. And I think learning something about it made me a better programmer - better at recursion, definitely.

But, when I wanted to start using some regular expressions, it fell flat. I read about a regexp module, but with SBCL I had to use a module called cl-ppcre. Fine. But I couldn't just include it; I had to download, compile and install. That's fine. Oh, but then I had to use proprietary extensions to evaluate it if I wanted to use it. Again, awful.

So, I think, I'm going back to Python for most of my tools. As a language, it isn't perfect. It's often too verbose. But at least it's consistent, and at least it has a good standard library.

‹ previous 6 of 6