ANSI Common Lisp review, chapter 1

Lisp was born in 1958, when the now called father of Artificial Intelligence [AI] - John McCarthy - began the language implementation, working with his own students.

Today, Lisp remains @ the pole position for AI programming, despite some people going for Prolog instead. The truth is that Lisp remains unique in many ways, and still is the most powerful language to capture very high level concepts.

Lisp allows you to code in any fashion [bottom-up or top-down approachs], but makes it easier than in any other tool, to go for the bottom-up design. While bottom-up thinking might not seem very natural, since we spend our life planning ahead, ie dividing the expected complexity in smaller problems, it is the only possible way to express the most sophisticated events.

Take the example of designing an ant with Artificial Life [AL]. You want to code an ant, that will behave exactly like its biological equivalent. In a top-down approach, you would begin to identify sub-problems in your daunting task: how does an ant walk?, how does an ant eat?, and so on... and you could only expect to solve such problems, by observing a true ant.

Now, as you can probably see, the most probable thing to happen is you failing on observing some detail, or thinking that you observed every detail, while you did not... The human being is so limited and so prone to error, that everything that is written top-down is only as good, as the programmer coded it, meaning that it can be very wrong...

Top-down approach is also more time consuming and harder, since there can be so many details to work on!

Bottom-up is the contrary. You start from the most basic stuff you can identify, and then re-use those elements to build higher level things. For example, you would start from an ant cell, then re-using the cell object, you would build a tissue, and so on... NOTICE that this is exactly what Mother Nature does: it goes from the atom to the molecule, from the root to the leaves, from small to big... Bottom line is: bottom-up is natural! :)

And Lisp does make it easier to go bottom-up. It is an interactive language, in the sense that you are always entering new concepts, that are immediately processed, and can be re-used from then on. As Paul Graham - the author of ANSI Common Lisp - says, Lisp incentives exploration.

Paul Graham writes the 1st chapter of ANSI Common Lisp, calling your attention to what he thinks are positive aspects of the language. For example, you can read that in a "traditional" programming language, you are very much advised to plan before you code: "think about the problem, then code it"... In Lisp you still should think before coding, BUT the price of a coding error is lower, than in, for example, C.

What Paul Graham means is that if you make a semantic mistake in C, you must re-code, re-compile and re-execute your program, while in Lisp you just re-code it, since the interactivity of any Lisp environment works just like that.

I don't agree that the interpreted environment is such a big advantage, and that it cuts developing time at all, but I can see the point...

The only thing that I really think that shouldn't be in the 1st chapter is a reference to a piece of code that writes a function, that returns a function that adds n to its argument:

(defun addn (n) #'(lambda (x) (+ x n)))

The Lisp code to such function is as above, but the part that makes me not wanting these lines @ the 1st chapter, is that they might suggest that Lisp as a strange syntax - which has not - and then, Paul argues that you CANNOT do such a function in ANY OTHER language. Well, I don't know all the languages, so I can't really tell if that is true, or not, but I know at least one language where you can code not exactly the same thing, but something that is very equivalent to it...

In C, you can't have functions directly returning functions, but you can have functions indirectly returning functions, via a pointer. For example, the following lines code a function fxpto that receives a function and a number, and returns a call to it:

typedef int (*pointer_to_a_function)(int);

pointer_to_a_function fxpto (pointer_to_a_function f, int n){ return f(n);}

But oh, yes, that is NOT exactly the same thing... and Paul Graham must be right! Check that the example Paul gives, is not what it might read the first time :)

Overall, the 1st chapter does make you want to learn Lisp... stay tuned, because I'll be reviewing the next chapters.

Tomorrow, you'll be able to buy this book with a great discount, from these pages, plus I am preparing a lot of amazon.co.uk deals on AI and Lisp. I hope you take advantage of such deals. There is nothing better than learning.