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:
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).
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.
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.
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:
- Clojure library is too different from the one of scheme or common lisp to be used without looking at the docs
- The official doc does not use examples, which would make it very easy to grasp the syntax of stuff
- Getting Started
- Exploring Clojure
- Working with Java
- Unifying data with sequences
- Functional Programming
- Concurrency
- Macros
- Multimethods
- 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.
No comments:
Post a Comment