Book Review: Programming Groovy

In the movie 2001, A Space Odyssey, the director Stanley Kubrick spends a vast amount of time with lava lamp-style special effects. The last part of the movie is an interminable journey through the same scene with different colors. Kubrick would never make that movie now: at least a third would end up on the cutting room floor. But he was entranced with the shiny new technology and indulged it to distraction.

The same thing tends to happen when a new technology comes out. If you are an early adopter, you'll slog through the lava-lamp effects to get to the meat of the new technology. Groovy has followed this route. Because I've been following Groovy for a while, most of the previous Groovy books have been in two categories:

• wow, look at this new thing! Isn't it cool that you can do all this stuff, which contains useful information but also a fair amount of "look, she's walking upside down for 10 minutes" kind of stuff


• recipes for getting real work done (where Groovy Recipes falls, so I think it's very well named. I reviewed it just before this one.)
  

I don't mean for this list to sound pejorative: every new technology comes out with these books first: it's an inevitable part of the technology life-cycle for new languages. But eventually someone comes out with a book that no longer treats the new language like a shiny new thing, but as a serious contender in the language universe. And that's Programming Groovy by Venkat Subramaniam (disclaimer: I know Venkat, but you shouldn't hold that against him). It doesn't treat Groovy like a novelty act. It also doesn't provide recipes. Instead, it treats Groovy as a real programming language. I'll have to admit, this is the Groovy book for which I've been waiting.

Groovy is friendlier syntax for programming Java (I called it the real JDK here). Books about the practical aspects of Groovy are very important because, as a language, it resides in a unique place: it's a low impedance way to program the Java platform, and it displaces Java for lots of common tasks. But it is also a powerful language in its own right. Programming Groovy has 4 chapters on meta-programming Groovy, and another long chapter on building domain specific languages. That's meaty stuff. It never condescends or makes excuses for Groovy but treats it like a real language. It includes lots of material that's hard to find online (like how ExpandoMetaclass really works). This is going to be both a classic in the Groovy literature and an exemplar for describing the real power of new languages.

Book Review: Groovy Recipes

While I've been "away", hammering away at my own book project (see this blog entry for that history), several important books have arrived that I haven't had a chance to talk about. I'll cover them in chronological order. The first is Groovy Recipes by Scott Davis. This is the Scott half of a book project that he and Venkat Subramaniam started a while ago as a single book (disclaimer: I know both authors quite well), and they quickly realized that they were writing separate books, so they made that a reality (I'll talk about Venkat's book in my next post). Groovy Recipes does what the title says: gives you recipes for how to get stuff done in Groovy. But that's only part of the value of this book. It also teaches how to become an idiomatic Groovy developer. And that's incredibly important. The classic book on C, the K&R book The C Programming Language, did 2 things for C. First and foremost, it taught developers about the c programming language. But the second more subtle thing it did was to teach developers how to be idiomatic C programmers. I can remember reading the book and marveling at the conciseness of the code, which had as much to do with the way the language was used as the language itself.

Anytime you learn a new language, you have 2 battles: first, learn the syntax (which is the easiest part -- it's just details of how familiar concepts are expressed in the new syntax). The second battle is the more important one: how to become an idiomatic programmer in that language. Developers new to a language tend to write new code just like code from their former language, using new syntax. Only when they've had time to steep in the better, more elegant ways of expressing yourself in a new language do they truly become proficient. That's what Groovy Recipes does for Groovy developers. It shows not just the syntax, but how to idiomatically use that syntax to become proficient with Groovy. Groovy is a much more powerful language than Java. While you can take a Java source file and rename it with a groovy extension and have it still work, you're writing Groovy code like a Java developer. After you've seen and used Groovy for a while, you start writing code like a Groovy developer. The Groovy Recipes book is two things: recipes for using Groovy to solve problems. But, more importantly, it teaches idiomatic Groovy programming, which is the long-term benefit of the book.

The Productive Programmer - History & Future

No, I haven't fallen off the face of the earth. I haven't been blogging lately because I've been heads-down, finishing (finally!) The Productive Programmer. Understanding why it took so long requires some recent history.

Back in 2005, after having fully recovered from writing the Art of Java Web Development in 2003, I decided to look for a fresh book project. I started wondering if the world could use another book on Regular Expressions, other than the seminal work on the subject by O'Reilly. I asked a few people and the universal opinion was a resounding "No!": the current book is so good that it's pointless to try to write another. I was talking about it to David Bock, friend and No Fluff, Just Stuff colleague when I visited NovaJUG, the Java User's Group he facilitates in the DC area. He agreed with everyone else, and we started chatting about what we thought would make a good book. We had both recently observed developers struggling to make an IDE do something that was trivial on the command line, but the developers had spent their entire careers in graphical operating systems and IDE's, and couldn't bash their way out of a paper bag. We decided that it would be cool to write a book about command line tricks and techniques for developers, and that we would write said book. The original idea was to write a gigantic recipe book for programmer productivity. We contacted a publisher (who suggested the title The Productive Programmer), and we started gathering recipes and writing about them.

Then, 2 things happened. David left his job of many years and founded a consultancy, Code Sherpas, and instantly became 300% allocated. At about the same time, his wife Lorna became pregnant with triplets! Clearly, David now has his hands more than full. At about the same time, I realized that a book consisting solely of recipes would be the most boring book every written. But, by that time, I had also noticed some patterns in the productivity stuff in which I was now immersed. In fact, I remember the exact moment I realized that this book should show patterns (or principles) of productivity. I was in India, working on a ThoughtWorks project by day, and writing the book by night. I had some long conversations with some of the folks with which I was working (Hi, Mujir!) about this, and finally settled on the five principles of productivity (which later became 4). Instead of being a book of fish, I now had a fishing manual.

Of course, I've been busy as well, so the work on the book was intermittent at best. Plus the fact that the publisher was really expecting a recipe book, and it was no longer that. So, the publisher and I started going back and forth, wrestling over the format and content to try to mold it into something upon which we could agree. By this time, I had kind of taken over the book because David was so slammed. Eventually, I realized that no amount of massaging was going to create the book the publisher thought they wanted, so the publisher and I decided to part friends. I now had distilled the 5 principles down to 4 (I realized at some point that indirection is really just an aspect of canonicality) and written about them. While I was writing, I was also doing Productive Programmer talks at No Fluff, Just Stuff, honing the material that was perpetually going to be out RSN (Real Soon Now). I now had about 100 pages of refined material. But I also realized that the principles really only covered one aspect of developer productivity, the mechanical side. I also realized that I had been talking about the practical side of productivity in my older talk Clean Up Your Code and its modern sequel 10 Ways to Improve Your Code. That was the last piece. I contacted my now publisher O'Reilly with 1/2 of a productivity book and a clean vision for what the second half should be. So, from December until March this year, I wrote the 2nd half. And, fortunately, David agreed to write the forward of the book, which gave a pleasing resolution to the original vision we both had.

For all those long suffering attendees of my Productive Programmer talks at No Fluff, Just Stuff for the last 2 years: the book is ready. It's in copy editing now, and should be out soon. RSN. For real this time.

This is a thanks to all the people who've attended the talk over the last couple of years. Your questions and responses made the book better, and now you can hold one in your hands. And, now that I'm back from intensive writing, ready to reengage the blogsphere with a vengeance.