[Misc] Clojure & Clojure Book Review

It looks like we are living in a fantastic time concerning programming languages. Creating a new language has never been easier then before. With the two great platforms Java and .Net it's not extremely difficult any more to generate intermediate code from the language you are dreaming of. And even the pragmatic bookshelf has a book in writing on "language patterns" to cover this topic.

Thus I assume that nearly every developer is looking out to bet on A) the best horse or to see B) a language from where you can learn the most. Unfortunately the whole world seems to bet on Scala from the sea of hot languages. And indeed Scala is quite cool and might win the race with good reason. Scala is hot stuff for reason. Nevertheless I never got really warm with Scala and it's hard for me to describe why. It's something in the syntax I really can not explain. My dream language must have a code that looks quite perfect. Years ago I had that feeling coding Ruby (and I love Ruby) because the code simply looked great (although I don't like other things in ruby as e.g the clumsy class definitions (there was a project on rubyforge to fix it. Does someone know the name?)).

So I am still constantly looking out for new languages and of course the pragmatic programmers have brought this book into my view:

Stuart Halloway, "Programming Clojure", 2009

So I might share my thoughts on this book and on the language.

For me still Clojure is more attractive then Scala because:

1. It's the toughest edge for your brain.

Perhaps you belong to the same generation as me: I never really used Lisp, Scheme or the dialects alike. But as I am a Java, D and Ruby Coder => Lisp and thus Clojure ("Lisp Reloaded") is the hardest challenge to learn. And according to the last two book reviews you should always go the hard way to learn the most. This might be even true for you.?! For me it turns out that the amount of round brackets is not the problem.

2. Clojure enforces the use of no variables but immutable data structures (as the successful Erlang does!). The code / structures itself mostly is the container for variables you would define use normally. This has two really strong advantages:

1. No variables mean less errors and less to debug
2. No variables and immutable data means no side effects
Hence it's not so easy to write Clojure code with much side effects.

3. Clojure has the strong concurrency concepts - if you really need mutable data - using STM (Software Transactional Memory) / MVCC, Agents, Atoms, giving you ACID Transactions without the "D" (which is only valid for databases).

4. The Java integration is really smart. Have a look:

(new java.util.Random)

simply generates an object you can easily use to work with.

Java and Clojure can call themselves easily vice versa. This might be a really good argument for you to save investments. Clojure doesn't really try to build up all the java libs from scratch; it reuses them in a clever way.

5. Clojure is indeed fast because it generates pure Java byte code.

And of course all the other stuff that a hot language must have:

• Closures (I still can not believe that they are still discussion this hot feature for Java... it's a shame)
• List Comprehensions
• a workaround for tail recursion and currying and other weird stuff as
• very lazy sequences, trampolining, etc.
  

What also challenged my mind is that Clojure has only three constructs for flow control (as we learned from Oz a simple and nevertheless powerful language doesn't really need much):

• An "if" See an example (if (> num 100) "yes" "no"))
• A "do" which is an iteration of statements - introducing side effects - and thus discouraged in clojure
• And a "loop/recure" that can be used to build everything you need in flow control (Stuart Halloway calls it the Swiss army knife).
  

So before I discuss the downside of the language and the book, let me bring up the two points that I loved most in clojure (even if it takes a lifetime to understand them 100%):

1. It has Metadata incorporated in the language right from the start! So you can tie pre- and post-conditions, tests, doc, arbitrary macros to any kind of data or functions. Whow! Do you remember how long it took Java to introduce Annotations? And to me they are still not 100% part of the language but an add on.

2. Clojure has powerful macros and multimethods. This means DSLs are incorporated. So if you loved the way Ruby can build DLSs (and the pragmatic programmers will bring up a nice book on this Ruby DSL topic!) you will get a step further in Clojure.

The book itself uses all hot Clojure features to create a build system called lancelet (every language since Rubys Rake seems to do this a little bit cooler then Ant does).

What I disliked in the book is that it's still difficult for beginners although it is very well written with beginners in mind. One example: I still havn't found the page where I can read a string from the console. And this is a key feature for beginners to test something. The interactive REPL is not enough here. What I mean is that the book has a thousand brilliant examples like fibonnaci. But fib is a two edged example. It just calculates. It creates no emotions in the reader. A better example is the snake game the book creates on a few pages later (here we get input from a keyListener...).

The language itself has two downsides for me:

1. If you are used to the huge Java Collection Lib you are astonished that Ruby boils down all data structure to just a super powerful Array and Hash (and the others are rarely used). That's cool. So you get the impression that Clojure get's on step further in stating that everything is a set (like Lisp stated that everything is a list). But when working with Clojure you are suddenly confronted with not only sets but vectors, lists, maps and trees. Now the book tells you that you always use the set abstraction to work with this. To me this doesn't really help if e.g. the vector notation differs significantly from a set and list definition. I still don't get used to this. but it must be surely my personal inability.

2. The most important drawback is the key feature at the same time: Clojure has an extreme steep learning curve! To become a true expert in Clojure, i.e. to think and dream in Clojure you need to stress every neuron in your brain. So it all boils down to the question: Is it really worth investing half a year in a hot language like Clojure to be able to produce code that is 3 times more accurate imperative Code?

What do you think?

Regards
Stefan Edlich

Links:

• http://clojure.org
• http://www.pragprog.com/titles/shcloj/programming-clojure
• http://ociweb.com/jnb/jnbMar2009.html
• http://en.wikibooks.org/wiki/Clojure_Programming

And finally have a look at this nice language comparison: Java.next
Make a list. For every topic give points from 0 to 3. What is the most elegant for you?

[Misc] Two Pragprog Books Reviewed

Book Review: The passionate programmer and Pragmatic Thinking & Learning

Recently I am getting more and more attracted by the books from "The Pragmatic Programmers / Bookshelf" (link). So I share my thoughts with a review of three books for you. Here I review:

1. Chad Fowler, "The Passionate Programmer", 2009
2. Andy Hunt, "Pragmatic Thinking and Learning", 2008
   

So let's start:

1) Chad Fowler is well known in the Ruby and Rails scene. So he he shares his visions using 53 chapters. Each with a message for you and explained. These messages look a little like the XP programming message. And sometimes they really read like these XP rules:

• "29. Learn how to fail" (testing)
• "18. Automate yourself into into a Job" (daily integration builds)
• "28. Eight hour burn" (no overtime)
• ...
  

But indeed his stories are nice to read and they go far beyond XP rules. They bind personal experience together with passion and and a possible new perspective for you. So his main point is to step out of daily routine, step back, get better and build up new goals for you.

Chad is quite strong in selling his point and most of the points are really fun to read (for example "20. Mind Reader" or "45 You've already lost your job"). So this book is not for experts who have already found their mission in doing independent consultant work for an apache product of which they are a top committer. It's a book for the employee wishing to get motivated and possible building up new perspectives in his career. And of course for beginners that might be reading an XP book at the same time. Chad includes nice actions for each point so that each point can be validated for yourself.

What distracted me a little is the analogy to other jobs. Many writers today cite that they have played (jazz) music in a band. And the challenges in a jazz band are quite the same to a software developer. Chad elaborates a lot on this topic. Even Andy Hunt (see the next review) draws this analogy and many other books (e.g. Presentation Zen by Garr Reynolds) can not leave this point - e.g. be the worst guy in your team - untouched.

Nevertheless it's a fun read if you want to break out and the book should also be recommended in software engineering / programming lectures.

2) Andy Hunt also wrote a remarkable book in combining cognitive sciences with software development. And indeed this is neither a neuroscience book nore a software development book. It is a wonderful walk through topics like:

• Journey from Novice to Expert
• This is your Brain
• Get in your right mind
• Debug your mind (how your mind works)
• Learn deliberately
• Gain Experience
• Manage Focus
• Beyond Expertise
  

This book could also be named "Your brain - The missing manual for software developers". So it's a wonderful guide to understand your brain and how to improve. The book is full of nice graphics, anecdotes and actions the reader should do. Through the book Andy collects Tips which are grouped together at the end of the book in a nice reference card.

If you read this book you will find some topics not new for you as mind maps or wikis. But Andy puts this in a context, gives many advices and he touches a lot points which will be new for you. For example the intense description or the L- and R-Mode helps a lot on how to reflect and use this modes in daily life. And there are a lot of other great new topics you can experience (as morning notes, SQ3R, etc.).

There were really just a few pages that were uninteresting to meas his elaboration on "expect the unexpected" or his way of categorizing generations.

Nevertheless it's a very practical book covering wide ranges of topics as drawing (there are some drawing exercises for you inside) up to yoga techniques. And everything could be applied for your daily life, job or your software development. So this book is a clear buy recommendation and even better a good present for your hacking friend or partner.

[Misc] Two new interesting SE books out

Recently two fresh books fell into my hands:

1. The Productive Programmer, Neal Ford, 978-0596519780
2. Clean Code, Robert C. Martin, 978-0132350884
   

The first book is a very ambivalent one.

Pros: It covers a wide range of areas how to be more productive. And so you can find topics like ACCERLERATION, FOCUS, AUTOMATION, Test-Diven Design, Code Analyse, up to very philosophical points. The real strong point of this book is that it has several dozen important points most programmers really forget about in their daily work. Each point might be trivial when analyzed in isolation. But to gather all productive points is a worthy issue. And even some principles as SLAP (already covered by Beck) can not be explained often enough.

Cons: The content really leaves a very diced impression. You can find the same information at several places in the book (like the "magic" unix find) and some points of uninteresting information like his words to Reflection, Exceptions, Array Indices and some flame about EJB 2 (really 2!). And thus it's not astonishing that this book gets only two stars on amazon.de.

But nevertheless: even if the book is a mixed work, if you adhere to 80% of the good rules, you will be a massively better programmer.

2. The Clean Code (subtitle: handbook of agile craftsmanship) is more a real work of craftsmanship itself. The idea is the same as for the book beautiful code I recently reviewed here. Martin has found smart authors for each chapters. And the chapters are:

• Meaningful Names (! which is a horror in big companies with developers from different cultural and technical backgrounds to my opinion...)
• Functions
• Comments (you think you can not learn here?)
• Formatting (sounds boring but is not) and
• Error Handling, Boundaries, Unit Tests, Classes, Systems, Emergence, Concurrency, Successive Refinement, JUnit Internals, and more...
  

It closes with a catalog of smells and heuristics which is a little like the one we had in the Fowler refactoring book but nevertheless of great use.

Robert C. Martins Clean Code Book differs from the rest because there is a lot code in it. And a lot code that migrates from bad to good. You really feel while reading that the authors have invested in strong code examples. This makes it a really valuable resource to read. So it has my strong recommendation.

To conclude: These two books, combined with all the Fowlers and Becks (not the beer...) lead me to create a catalog of all the useful points they have written. It is still small and in beta state. But you are invited to use, contribute or link to this growing list of best practices.

So God bless all (most of?) the software developers!
(who read these books ;-)

[Arch] OpenSource ESBs

The last couple of years major Open Source ESBs, including MuleSource and ServiceMix, have been expanded and are used in critical business solutions. Tijs Rademakers and Jos Dirksen offer a book which gives an overview about Open Source ESBs and which combination of Open Source technologies with ESBs are used. The main open source solutions covered in this book are Mule and ServiceMix. Therefore most of the examples in the book are based on these two technologies. Other Open Source ESBs that will be covered are Apache Synapse, Open ESB and the new integration framework from Spring, called Spring Integration.

In the TechBrief the authors mentioned that all Open Source ESBs focus on Enterprise Integration Pattersn. If you understand these patterns its very easy to understand the implementation and handling of ESBs.

The book is divided into three parts. The first part concentrates on reader which are not familiar with an ESB:

• Overview about ESB functionality and what Open Source ESBs are available in the Open Source market
• Taking a deep look into the Mule and ServiceMix architecture
• Installation of Mule and ServiceMix and how to run them

The second part focus on ESB core functioanlity which covers some of the Enterprise Integration Patterns. Here the reader becomes some connector examples, like JMS, JDBC, POP3 and Web Services.

The third part covers case studies and also illustrates integration scenarios with BPM engines, like jBPM and Apache ODE.

In the tech brief there was also a short comparison between Mule and Service Mix. When to use which one, is hard to say, it depends on your requirements. But in this interview on of the authors said that in a web service based architecture the JBI approach is often the better choice, but Mule is very often used, because you can also transfer Java objects, which is often very comfortable and faster. They also talk about integration of legacy systems, which is sometimes easier with Mule, because when you use Service Mix all messages must be transformed in XML.

You can download chapter 1 and chapter 4 for the book homepage.

[Tech] Update on "Maven: The Definitive Guide"

I am happy that the guys from Sonatype are continuously improving their free book on the "de facto standard" Apache Maven build-automation framework: "Maven: The Definitive Guide". The book covers most topics typical Maven users will encounter, including generation of documentation (site) and writing Maven plugins (mojos).

I think this book is very useful for the newbie as well as for more experienced Java developers. The book is frequently updated and available for online reading and as PDF download; in the recent update they put their book under a Creative Commons license.

[Arch] Book Review: Kent Beck "Implementation Patterns"

As promised 10th Dec here is the second book review. Recently we discussed beautiful code, and now we have: Kent Beck, "Implementation Patterns", Addison-Wesley, ISBN-13: 978-0321413093

Of course Kent Beck is well known in the software-engineering and development space. He wrote books about

• Better Smalltalk
• Patterns
• Eclipse
• JUnit Pocket Guide
• Refactoring
• Test Driven Development,
  

and of course he might be best known for XP and his XP books.

Thus it's more then important to listen if he brings out a new book. And in fact this book is a wonderful and easy reading - in contrast to beautiful code - and a good reference for every ambitious developer.

Let's first have a look at the books chapters:
2 - Patterns
3 - A Theory of Programming
4 - Motivation
5 - Class
6 - State
7 - Behavior
8 - Methods
9 - Collections
10 - Evolving Frameworks
App A - Performance Measurement

So the first impression is, that something like state or behaviors sounds like the classic pattern categorization. But it is more from a different perspective: The developers perspective. For example the last three chapters - and even more performance measurement - can rarely be found in developer books. Unfortunately such important chapters like performance is just a small appendix. Most examples are written in Java which is especially important for the collection chapter that also shows lots of performance comparisons.

The interesting surprise in this book is that Beck writes about issues like "Classes" from scratch. Many of us might think they know everything about classes and can not be surprised. But Becks writing always forces you to look from another perspective. And this is the books strength. When Beck writes of Code "Communication" and e.g. naming Classes or Variables he pulls you up from a developer to an advanced developer in the complete context.

In fact Becks book is a great reference book that cover lots of issues. Some examples: Classes, Superclasses, Interfaces, Abstract Classes, Versioned Classes, Value Objects, Specialization, Subclasses, Implementors, Conditionals, Delegation, Pluggable Selector, (Anonymous) InnerClasses, all kind of Access Strategies, Variables & Fields, Parameters, Constants, Names initialization Modes, and so an on the Behavior and Methods Chapter.

So what might be criticized?

In fact some things can be found elsewhere in other books like Bruce Tates "Better, Faster, Lighter Java" or Bruce Eckels "Thinking in Java". And Kent Beck even reuses parts from his older books. Sections as the "Pluggable Selector" can be found in his TDD book and in Implementation Patterns even if Kent has invented complete new code examples for this pattern. And rarely some examples are a little elusive (e.g. when missing code symmetry looks more like missing intentional/implementation definitions from the start). But don't get me wrong: it's super worth reading and should lay next to nearly every developer!

To summarize

If you are an advanced developer guru who has reflected for years about your own code you will not find the book a complete new revelation. But for developers who still love to reflect about code and like to have a developers reference at hand, this book is a wonderful meta-best-practices extract with lots of issues that TatesEckels* are missing.

Need a post Christmas Gift?
Happy Chistmas!

[Arch] Two important new books: two reviews

Recently two interesting books have been published:

1. Andy Oram & Greg Wilson, "Beautiful Code",

OReilly, ISBN-13 978-0596510046

2. Kent Beck, "Implementation Patterns",

Addison-Wesley, ISBN-13: 978-0321413093

Let's have a look at the first one. The second one will be looked at in the next review posting here.

There have been a lot of rumors before "Beautiful Code" has been published. Perhaps because there are not really that much book that cover something like "the art" of coding. So whenever I listen around, all the Gurus I know seem to read that book. So it must be important...?!

What primary stucks is that the book is edited by Oram / Wilson. What they have done is: they have called for chapters. In this way they have been able to attract 33 chapters from famous coders. This means that the book has no golden thread. The chapters are not build upon another. They simply cover the "Beautiful Code" view of the author. This in turn means that the chapters differ entirely and are not connected. So you have chapter that sound more like beautiful design, beautiful architecture or chapters that discuss what beautiful code might look like or what beautiful language design might be.

Let's have some random examples:

• Brain Kernighan shows us a regular expression and it's power using C code stuffed with lots of pointers.
• Karl Fogel shows the delta editor that is the basis of subversion. This includes C Code with lots of comments.
• Jon Bentley is the first who uses 'higher level' languages, compares some quicksorts and even shows a little mathematical background.
• Alberto Savola introduces JUnit and shows how beautiful tests can cover a binary search algorithm.
• Image processing code by Charles Petzold.
• Bryan Cantrill discusses threads in connection with beautiful code.
• Jeffrey Dean and Janjay Gemawath show you evolving code leading to the map-reduce solution.
• Andreas Zeller write about beautiful debugging. He doesn't show too much code, but some insights could rarely be found elsewhere.
• Yukihiro Matsumoto (the brilliant author of ruby) only shows 13 lines of code but is getting into a short philosophical discussion, how a programming language should look like that 'offers' the ability to write even more beautiful code.
  

There are a lot more topics like:

finding code, XML Verifiers, beautiful frameworks, operator precedence, secure communication, DNA sequencing and gene sorting, beautiful code at CERN or in LINUX, a reliable Enterprise System for NASA's Mars Rover Mission, software transactional memory, audio& emacs and even Logging, REST, are covered.

Most readers might think at first glance that some areas might not be of interest: LINUX code, Bioinformatics or the Architecture of an Enterprise Ressource planning System might not be every ones first choice to read.

But nevertheless: in my opinion, nearly every of this 33 chapters in this book is a wonderful insight into beautiful XXX from different viewpoints where XXX is code or software-engineering, design, problem-solving or whatever.

But one should not get the weight of this book wrong. It is not possible to read the 550 pages like a novel and finish it in a few evenings. The book challenges you to invest hard work in each of the 33 chapters. The problem / challenge is to understand each code and each problem. To my opinion this need 1 hours per chapter and a some sheets of white paper to get the complete insights.

So to summarize, there might be two readers for this great book:

A) Just read the pages and you might have heard about 'map-reduce' or cool 'testing or debugging'. This might work faster.

B) You would like to understand each area covered in the book. This might cost you 33 hours but you will improve your IT knowledge dramatically.

So what type of reader are you?

[Arch] Domain Driven Design - Presentation

In this presentation Eric (specialist in domain driven design and autor of the book domain driven design ) steps through a Cargo sample, where he give an example how to identify objects and put them in a relation. When dealing with domain driven design you will realize that complexity is in the domain and this complexity will be also found in the model.

Eric point to a very important thing in domain driven design: The language and naming of objects. The complexity of implementation can be reduced through good domain design. This fact is represented in his sample by using Leg-Based and Stop-Based models. Depending on the used model there is a major impact on the implementation details. While designing the domain model it is necessary to validate the model by playing different scenarios (use cases) with the model. The language of the model depends on the context in which the model is used.

The presentation gives a really good introduction in Domain Driven Design (DDD).

[Tech] Maven: The Definitive Guide

Ok, today is the day of micro-postings, however, this might be interesting and good news for some developers. Apache Maven got a new online-book. Maven is a great tool for build-automation, a deployment tool, a dependency management tool, a documentation generator and reporting framework and is implementing build-lifecyle-best-practices and propagates the convention over configuration idea and so forth. A lot of features, a lot to know and learn. However since version 2 Maven is definitly taking off and apparently replacing Ant in many projects.

So, for all who need more information than there is provided on the Maven website, check out the two free Maven books:

• Maven, the definitive guide (html-online, html-download)
• Mergere, Better builds with Maven

I think both books are useful; up to now I mostly used the Mergere book, but it is lacking some important information, e.g., the documentation generation (site) is practically non-existent in this book, but well described in the "definitive guide." It should however be mentioned, that the "definitive guide" is apparently not completly finished yet. For example the "Mojo" chapter lacks description of mojos in Ant (which is a pity from my point of view), also Beanshell and Ruby are only available as heading. So some "TODOs" are still in the text, but it is still worth a look!

So let's hope the author(s) have enough motivation to continue the work on the book. (btw: it is funny, that I found nowhere a reference who the authors of this book would be? any ideas?!)