The SBCL download page shows version 1.0.14 released today, and it's already in Portage (masked). The gentoo-lisp list says we got a new Lisp project lead recently. Looks like there's plenty of Lisp going on in the Gentoo world. Personally I am very pleased with the state of Lisp in Gentoo.
Sometimes I wonder what purpose this blog serves. One purpose I found for it today was looking back through my old entries, to see how things have changed over the past couple years. I very strongly believe in introspection for the purpose of refining beliefs to make them more accurately reflect reality. In other words, I know I'm probably wrong about a lot of crap and I really don't like the thought. It bugs me. So I'm always looking for ways to change my perspective on things, if it needs changing.
I first tried Lisp in August 2006, it seems. Some of what I said was somewhat amusing, and wrong. Quoth myself:
My prediction is that Ruby will end up being mostly a superset of Lisp except for a few areas Lisp is specifically targetted at.
Oops! In fact just the opposite is true. Common Lisp is easily a superset of Ruby in all the ways that matter, specifically meta-programming and the flexibility of the object system, to name a few.
Lisp is sadly just a subset of Ruby in terms of the amount of libraries available. Ruby has tons of people writing tons of code for it. But I am finding that Common Lisp actually has a LOT more libraries than you'd guess from a quick glance. The problem is that Common Lisp is so much less "mainstream" than most languages that you have to do some digging to find the libraries you need. Once you do find them, they tend to be of high quality and great utility, from my brief experience.
Then again, Ruby itself is a subset of Perl in this regard. There's a critical mass where you probably have "enough" libraries to get the job done. Perl+CPAN is probably over the top in this regard. Ruby is there. Common Lisp is pretty close.
I must admit, properly formatting Lisp seems confusing.
Yeah, I do remember indentation of Lisp code to be pretty confusing back then. In PCL Seibel talks about how "experienced Lispers" use indentation to tell them if something funky is going on with their parens. I realized today I actually do this too now (though I am not an "experienced Lisper").
LET forms look a certain way,
IF forms look a certain way, standard function calls look a certain way. You can tell immediately if something fishy is going on if the indentation is being screwy.
Actually I think people probably do this in most languages. If you've written any amount of Ruby, you know that eventually you often end up with 87
end's in a row, some closing if-then statements, some closing iterator blocks, some closing method definitions, some closing class definitions. If you type an
end in Vim and it launches all the way to column 1, but you weren't expecting it there, that can tell you that you have something wrong (an extra
But it's much more necessary in Lisp. It seems to me that it would be extremely difficult to write good Lisp code without an editor's help. There are way too many parens for a human to keep track of. That's not to say that Lisp requires a full-blown IDE just to make the language usable (*cough*Java*cough*). Lisp syntax is regular enough that it's REALLY EASY for an editor to very consistently help you keep your parens balanced. The rules are highly logical, simple, and surprisingly standard across the Lisp community (compared to the tabs vs. whitespace, 2 vs. 4 vs. 8 spaces, curly-braces-on-newlines-or-not sorts of wars you'll find in some other languages' communities). If you use paredit or something similar, keeping your parens balanced and indented nicely is a no-brainer.