I’ve been learning LISP from LISP, and solving problems from Project Euler in LISP. Once you solve a problem, you gain access to the forum thread about that problem. After I solved Project Euler 10, I read someone else’s LISP solution; it was quite different to mine, and contained some LISP constructs I hadn’t seen before, e.g.
(defun seq-list (min max) (loop for i from min to max collect i) )
I’d have written that like so:
(defun seq-list (lower-bound upper-bound) (let ( (current-number lower-bound) (result '()) ) (loop (when (> current-number upper-bound) (return result) ) (setf result (append result (list current-number))) (setf current-number (1+ current-number)) ) ) )
That’s 16 lines of code versus 3 lines of code. OK, I could knock at least 6 lines off mine by squishing closing parentheses onto earlier lines, but that’s ignoring the real problem: his code is simple and clear, whereas my code is all tangled up in the mechanics of declaring local variables, looping, and updating the list. A programmer who didn’t know LISP would probably understand his code, but wouldn’t have a clue what mine is doing.
I didn’t remember seeing syntax like that when reading the section on
in my book, so I checked it out: it has nothing like that. There’s also nothing
(collect) in the index. I need to learn from a book that covers all of
LISP, so that I can reasonably expect to understand other people’s code. I know
that I’m writing baby-LISP (cute and helpless) at the moment, but I want to
progress on to child-LISP (enthusiastic and energetic), teenage-LISP (angsty and
rebellious), and finally adult-LISP (uh, serious and . . . my analogy has run
out of steam). I don’t think there’s any point in learning from an incomplete
textbook, because later I’ll need to start at the beginning of another textbook
anyway. I’m putting Project Euler on hold until I find a better book; I might
even redo some of the problems I’ve already solved.