The Reasoned Schemer

Just the other day I was reading Johan Lindberg's blog and I found this entry, talking about The Reasoned Schemer book. I confess I haven't heard about this book before, but the abstract of the book was so good that I had to buy it right away.

The book arrived last Thursday and I started to read it immediately. What I can say is:

• I haven't used functional programming in the last 10 years, since my graduation when I had a class about it in 1997. I almost forgot how fun it is to use it! I'm eager to skip to later chapters were it talks about relation programming, but I don't dare to do it... I'm really enjoying remembering all the stuff I learned in the past, plus learning new things I didn't know were possible.
• The book is written in a singular way, I haven't seen before. The whole book is a sequence of small questions, like small exercises, where the left column contains the question with eventual examples and the right column contains the answer. Each question intents to explain a new concept or improve the understanding of the previous concept/question. It means the book is slower to read, because it is dense! There is a lot of information to learn in each page and it makes you think while reading... it is not a mechanical reading process, it is almost an interactive learning. Very cool!
• The concepts of functional programming I am re-learning (or remembering) are making me think about some cool things it would be nice to have in Drools. Real unification is probably the top one, but I know the interest is more academical than corporate. Look at the following example (consider it pseudo syntax) from the book. It is a really really simple example in functional programming, but shows a simple trick you can do with unification. Imagine it leveraged for real inference problems.

(run* (l)
 (fresh (d x y w s)
   (cons w (a n s) s)
   (cdr l s)
   (car l x)
   (== b x)
   (cdr l d)
   (car d y)
   (== e y)
 )
)

Bold letters are constants and italic letters are variables. What is the value of l, after running it? If you said

( b e a n s )

You got it. If I were to chose a single line of the above example to show something most programming languages do not allow, but it is common for functional programming languages is: (cdr l s). It is the same as saying to the computer: X + 3 = 5 and having the computer tell you back that X is 2, without having to code any imperative procedure to solve the equation. Simple, but powerful.

Thank you Johan for pointing that out. Thank you to the authors for the fun time reading it. I guess I must buy the previous book now.