In my last post I mentioned reading Practical Common Lisp. I went on through several more chapters since I wrote that (quite a few more) and one practically made me stop. The first “practical” exercise is writing a library that makes it less horrifically painful to use Common Lisp to deal with reading directories.
It was a pretty quick little library and I’m sure effective, but at that time, I was kind of tired of hearing explanations of how “this has a meaningless name, for historical reasons,” or “this is completely contrary to how you’d expect it to be considering other parts of the language” or whatever. There’s a lot to just get used to in Common Lisp. Seeing an entire “practical” chapter devoted to creating a library to fix kludgy implementation problems stemming from Common Lisp’s advanced age was offputting.
But then I realized that a little ahead were the chapters on CLOS, the Common Lisp Object System, something I had always wanted to understand and never quite got. I didn’t really understand how Object-Oriented systems based on multi-method dispatch worked.
It was a really good explanation. I think I understand it now. One point that was made was that it is not a “message-passing” type of OO, the way Smalltalk and Ruby are. I realized that while CLOS is pretty cool, I really like the message-passing style of OO. It made me wistful for Ruby.
But CLOS is way powerful, and the book had a great explanation of it. Now if I take a look at other multi-method-dispatch systems I’ll have a better context from which to understand them.
The chapter on LOOP-fu was interesting. LOOP is a mini-language implemented with macros within common lisp that lets you write Python-like loop constructs (probably more powerful than Python’s loops) in a not-very-Lispy notation. It made me think Python might have been influenced by Common Lisp LOOPs.
I also wanted to check out the chapter on packages, because that was a big part of Common Lisp I didn’t previously understand. Turns out they’re a lot like Perl, but that it’s easier to shoot yourself in the foot using them than with Perl.
I still haven’t read most of the “practical” chapters yet. (I skipped forward to get to some of what I considered the good stuff.) But overall it didn’t make me want like crazy to program in Common Lisp. It made me feel like I could if I wanted to for some reason. It cleared up a lot of what was mysterious to me about Common Lisp. The only thing that Common Lisp has that I really desperately wish I had in other languages is its glorious macro system. I have a feeling that in terms of the “defining new syntax structures by being able to take unevaluated code chunks” aspect of macros, you can get a lot of mileage out of Ruby’s blocks for doing macro-like things. However, macros can do a lot more than that.
Overall it made me think fondly of Ruby, because Ruby uses a style of object orientation that seems more natural/intuitive to me, and can do a lot of (though by no means all) the spiff stuff Lisp can do.
It also made me think fondly of Scheme, because Scheme is a lot less ass-ugly than Common Lisp, and can do a lot of the same good stuff, though it doesn’t have even a tiny fraction of the built-in cool stuff in the standard.
It definitely made me open to using Common Lisp if I ever think of a project where it would come in really handy. And I do plan to finish the book when I get a chance.
Fun Fact about Common Lisp: standard Common Lisp has no networking libraries at all, but it does have a built in function to print integers as Roman numerals — using either the new style (14=XIV) or the old-style (14=XIIII) Roman numerals. Huh.