Practical Clojure

There are many different kind of technology books. Some books introduce the reader to a specific technology or to a concept. Some books are references, some teach the basics of programming (or some other elementary concept). Some books do more things at once.

Some books last. When a book does not teach a specific technology (that is transient, by its own nature, and changes) but a broad concept, they are more likely to last (perhaps with minor modifications). The books I love most are part of the second category.

A particular category of technology books are the ones teaching new programming languages. If the programming language is a good one, the books tend to lean towards the second category, the one of books teaching broader concepts, even though perhaps they need more frequent updates, as languages evolve.

Perlis said that: "A language that doesn't affect the way you think about programming, is not worth knowing." And I could not agree more. Some languages improve your programming in every other language. Lisp is one of such languages. Nice dynamic OO languages don't do that automatically, but in the hands of a careful programmer, they have the same effect.

So, if the language is good and the book teaches you how to actually think in the language, how to use its proper abstractions, then it is teaching you something noteworthy. Unfortunately, sometimes there is so much language to teach, that there is no more space for anything else (C++?). Moreover, some languages just teach programmers to thing the wrong way (C++, Basic).

But this does not really concern us, as we are going to talk about Clojure. Clojure is a wonderful language (even though I actually favour Common Lisp).

Right at the moment, there are two book on Clojure. I already reviewed Programming Clojure in a previous post. The "other" book about clojure is "Practical Clojure".

From a typographical point of view, Practical Clojure sucks. I just hate the way APress books are typeset. I hate the fonts. I hate the spacings. It looks to me as it was paged with word. On the other hand, I rather like the Practical Bookshelf paging, indeed. Still, I find I prefer more the typesetting of some more traditional editors (e.g. On Lisp, most stuff from MIT Press, or even some newer stuff such as NoStarch Press Land of Lisp). But of course it is content that matters.

Practical Clojure uses a newer version of clojure and that is an advantage, of course. A part from this, it is another introductory book on clojure. There is a wide intersection area on the subjects, but the two books have some differences.

Practical Clojure introduces Java interoperability at the end of the book and that means that most examples are "pure clojure" and some central chapters can be used as a reference. Consequently I sometimes read through Practical Clojure even now. I also find some explanations more thorough.

On the minus side, there are fewer long length examples. Consequently, it is harder to figure out Clojure pragmatics. I believe that we really need a different breed of books. Practical and Programming Clojure basically show us the basic Clojure constructs and how to use them. They are introductory books on Clojure (and we need these books as well).

I believe that we need books that build on those two to go deeper. Some books on Lisp are old, but still teach the abstract principles of Lisp programming. Consider for example Graham's books, or PAIP. We need something like that for Clojure. In fact, I'm looking forward to read Joy of Clojure.

Amazon Associates Link

Technorati Tags: Clojure, Lisp, Programming

Programming Clojure (opinions)

It was the end of 2009, when I bought "Programming Clojure". In the same order, I had Effective Java and Java Puzzles. The idea was looking for an alternative language to use on the JVM. Scala had already been ruled out... it was either Clojure or JRuby/Jython. In those days, I was a lot into scheme.

I had to admit that I found Clojure extremely unimpressive. On the other hand, when I started working with it more recently, I just felt the opposite. Not the sheer sense of wonder and magic I have when working in Common Lisp (or even Python) but still a peaceful easy feeling. Most of the problems I have is that:

1. Clojure library is too different from the one of scheme or common lisp to be used without looking at the docs
2. The official doc does not use examples, which would make it very easy to grasp the syntax of stuff

It took me some time to figure out that in clojure cond does not take "enough" parentheses. I will discuss on this lack of parentheses another time. I felt that the book I had, did not help me at all. Let me explain, this is the book index:

1. Getting Started
2. Exploring Clojure
3. Working with Java
4. Unifying data with sequences
5. Functional Programming
6. Concurrency
7. Macros
8. Multimethods
9. Clojure in the Wild

What I did not like

Chapter 2 is a rather introductive chapter, but it is all in the wrong order. It starts with basic data, and it is ok. Then basic reader macros (quote) and functions are introduced. First, to my understanding, conditionals should have been dealt with before functions, so that when explaining functions recursion can be explained as well. Without conditionals, it is quite hard to write most recursive functions. ;)
But after functions and before conditionals are explained bindings and namespaces. Destructuring, for example, is a terrific feature. I completely missed it out (my fault) because the first time I read it it was too advanced (it is not what you look for when just starting to write the early test programs one writes when learning a new programming language). On the other hand when looking for such features, I did not imagine it was so early in the book.
Then it comes the discussion on namespaces. We do not even have been presented if at this point. The discussion is too terse (in my opinion) and is utterly permature. The rest of the chapter makes sense, still is somewhat too short.
Although clojure is not as small as scheme, it is still possible to do a very short introductive chapter where the "core" language is presented. This is not what happened. On the other hand, Chapter 2 should have been more detailed, in my opinion.

Then it comes to Chapter 3. Which is about Java. I feel that this is a terrible mistake. The impression I got (and as far as I could see from the comments on the web I was not alone) is that, in fact, Clojure cannot be used without Java.
Let me explain: you have been just taught the core language, more or less. At this point you expect either some example program putting together the notions you have, or a chapter on some more advanced features.
You get Java. I understand that clojure relies on Java for many basic features and part of its strength is in reliably and easily calling Java, but if it was just this, I would plainly use Java alone. You have to make me love the language on its own, and then using Java is "why you can use it in the enterprise".

I know I have not been very informative: the point is that clojure is more than (.calling (Java.)); Clojure is a wonderful language on its own. I wanted to see the clojure way. You don't have to sell me clojure as an interop language (yet). I totally agree with Practical Clojure choice on this point (which is placing it at the end of the book). I do want to hack with clojure, not with Java (it is a rather safe assumption, as I bought a book about Clojure -- well I also bought books on Java, but that is another story, isn't it?). This choice somewhat gave me the impression that clojure couldn't stand on its own without Java (which is not true, even though the main strengths over Common Lisp would be gone, Clojure would be a nice language anyway).

What I did like

Is it Programming Clojure a bad book? No. It is not. I quite liked all the code examples. To be sincere, I did skip them the first time I read the book (because some where somewhat too long to figure out without really paying attention to what is happening -- and I did not have a computer around --). However, they are really useful, and perhaps the greatest strength of the book. I suppose that the example (and especially the long lancet example) required the Java chapter at that point. The snake example is simply lovely.

Moreover, there is plenty of information in the book. It is just difficult (for me) to find. Which is essentially my problem, not the book's.

The last chapters are very well done, in my opinion. Chapter 6 easily explains a rather difficult subject in a way which should be comprehensible to most people. Clojure STM and agents are basically some of the more important features of clojure. People could even want to switch to clojure just for them. My only objection is about moving clojure on the clound (compare with concurrency features of Erlang), but that is an entirely different story (and mine is just a general objection, not a motivated claim).

Chapter 7 is a nice introduction to macros. I think that it could be a real breakthrough for most Java programmers, which probably did not even know that stuff could be done. I quite like clojure macro system (kind of ... # is so weird!). In fact it improved my grasp of scheme macros as well (e.g., in The Scheme Programming Language there is not a lot of emphasis on quasiquotes).

Chapter 8 is well done. I have yet to understand if it is true that multi-methods are still not very much used in clojure. As far as I can't tell, it is a very useful feature (and one I used quite a lot in common lisp, even without using defclass). From the author point of view, it seems that they are not widely used (and he provides some statistics). Regardless, the introduction to multi-methods is very nice.

Conclusions

I liked this book. The layout is nice, the book has been thoroughly reviewed. Would I buy it again? Don't know: I also have Practical Clojure and I'm not sure if I need them both. The general opinion on amazon is that both books are not needed. I always find different perspectives interesting. Perhaps I would buy them both in any case.

To me, it seems that the book speaks more to the Java programmers than to the functional programmers. But this may be my impression.

Good book, anyway.

Clojure, Programming