After spending a week and a half studying both the PDF version of Seibel’s Practical Common Lisp and my copy of Graham’s ANSI Common Lisp (comparison coming soon), I coded up some algorithms for the next Project X prototype in the language yesterday.
I have to admit, as I get more used to it, I’m quickly falling in love with the language. There are a lot of little things that make it nicer to work in than C++. The ability to test something as quickly as you can type a command to do so, for instance — I haven’t had that since I played with BASIC interpreters in my childhood, and didn’t realize that I’d missed the instant feedback so much. Not having to declare functions in shared header file and define them in a different source code file, and keep both copies in sync as your understanding of the problem changes and evolves, is another minor but important difference.
And above all, having a language that works with you, instead of forcing you to do things its way. Just as a very minor example: there’s a function called intersection
that takes two parameters and does a set-intersection on them. I needed one that would take an arbitrary number of parameters, and do a set-intersection between the first set and each of the subsequent ones in turn. And Lisp allowed me to easily create one:
(defun intersection* (lst &rest more)
(loop for lst2 in more
until (null lst)
finally (return lst)
do (setf lst (intersection lst lst2))))
(There’s an even easier way, using a function called reduce
and passing it the intersection
function as a parameter, but I didn’t realize that until later. It also wouldn’t stop early if lst
was empty, like this one does.)
This kind of power allows you to express your ideas as simply and elegantly as you can see them in your mind’s eye, instead of twisting them to satisfy someone else’s notions of computer-science propriety. If you haven’t used Lisp, you probably have no idea how liberating that can be.
My prototype code is currently only 170 lines (one class and nineteen functions), but they easily do the work of twice that number in C++ — and that’s not counting the lines with nothing but a closing brace that accepted C++ style requires. I estimate I wrote them at about half the speed that I could have written the equivalent code in C++, but I’ll improve that as I get more comfortable with the language. I expect to surpass my C++ coding speed within the next couple weeks.
Ah, the bliss of finding a nearly-perfect tool after decades of working with much less than perfect ones. 🙂
Ah, “nicer”, “nearly-perfect”, are you sure that’s a “better” term or isn’t there a “better” one? 😉 😉
And not only did you use imprecise terminology again, you used the loop macro!!
I’ll stand by my choice of terms. 🙂
And yes, I used the loop macro. Paul Graham seems to dislike it, and other people apparently complain that it’s not “Lispy” enough, but it’s powerful, highly readable, and a useful abstraction, so I see nothing wrong with using it.
Well, that fits in with your appreciation of the more free-form elements of Lisp programming. I like loop OK too, I was only teasing, like the rest of my message. 🙂 (re: some redditors attack of your use of the term “better”.)