08 May, 2007

Thinking in Lisp (with respect to Bruce Eckel)

It isn't what you might think based solely on the title of this post.  Bruce Eckel of www.mindview.net isn't coming out with yet another book prefixed with "Thinking in"...  or maybe he is.  As far as I know though, he has yet to, nor is he expected to write one on Lisp.   


On a quasi-regular basis I make the effort to learn something new in the realm of computing whether a concept, paradigm, and/or language.  I decided that given my past experience and interest (since I was considerably younger) in artificial intelligence programming concepts coupled to early leanings towards Prolog, a French born AI/logic language created around the same time as I was back in the early seventies, that it was time to return to my roots.  This time around I decided that after being an emacs junkie for so long, that the obviously choice for me this time around would be the Lisp functional programming language.  


Now the point of this post is not to go into the semantics of the Lisp language but to stress a more important point which I feel would be of greater value to any and all who might stumble across these pages.  Learning to think in Lisp changes the way you think about code logic.  I'm a fairly big proponent of OO design and programming, though I ultimately believe in using the right tool for any given job/project.  Lisp has a wonderful simplicity about it, a simplicity with a considerable amount of power behind it.  


The concept is not unlike Unix methodologies.  Simple, small programs which do one thing, but do it exceedingly well, which can then be piped to one another to do larger tasks.  Mind you this is slightly different but not by much.  Lisp works dealing with functions (and lots of parentheses).  You string together multiple simplistic functions together to produce more complex functionality.  A simple example might be finding the average of two numbers.


(defun AVERAGE (x y) (/ (+ x y) 2.0))


defun is used to define the function with the given name "AVERAGE", followed by its parameter requirements.  The actual body of said function consists of doing a division operation (/) by 2, against the results of an addition function (+) of the two provided parameter.


I feel that this example while a little simplistic does at least point out the basic mindset of Lisp programming, which still hold consistent with my above statement on its likeness to Unix shell mannerisms.  While I don't see myself coding entire systems (on a regular basis at least) in Lisp, I do have admit that I'm going to continue my studies on this language as I have been finding that my perspective has shifted thanks to learning this new and different programming paradigm, which ironically isn't new when it comes down to it.  It was just pushed aside to make way for the 'next great thing™.'


I heavily recommend some of the freely available books and information on learning Lisp and its concepts as listed below (Note: All items are PDF formatted for convenience):


Practical Common Lisp

Common Lisp: The Language

Common Lisp: A Gentle Introduction to Symbolic Computation