I have been been thinking about and exploring
Groovy for the last few weeks. I have been looking (forever it seems) to something like the Rails web framework built on Java. There is much to like about Ruby but in the end it is just another imperative, object-oriented language with poor performance, bad threading, libraries "built on a learning curve" [*], and non-existent internationalization. Rails, however, is much more interesting than Ruby. The two parts of Rails that I most like are (1) the "convention over configuration" approach to associating components and attributing behaviors to them and (2) the integrated support for a version's development phases and migrations between versions. These are great boosts to productivity.
However, I am committed to Java for the foreseeable future for most commercial work that I do. (I also work in Perl and PHP but these languages are mostly used for integration projects.) Java offers a wealth of best of breed components of which most are open-source and use the generous LGPL or BSD licenses.
So I was excited to find out about Grails and, as mentioned in an earlier post, after reading
Getting Started with Grails I found that it satisfied my need for a Rails work-alike based on Java. My concern was that it was written in Groovy and not directly in Java. And so, I spent the better part of three weeks working my way through
Groovy in Action.
Groovy in Action covers the language in detail, its idioms, and its use in several problem domains -- XML, relational databases, GUIs, web application, etc. I am very impressed with Groovy. I was not expecting to be. It is another imperative, object-oriented language with reasonable performance, great threading, best of breed libraries, and end-to-end internationalization. The "You had me at "Hello"" moment came a third of why through the book when the author explores using "builders" to construct XML documents. The code is
def builder = new groovy.xml.MarkupBuilder()
build.number {
description 'Square and factors of 10..15'
for ( i in 10..15 ) {
number( value: i, square: i*i ) {
for ( j in 2..<i ) {
if ( i % j == 0 ) {
factor( value: j )
} } } } }
which outputs
<numbers>
<description>Square and factors of 10..15</description>
<number value='10' square='100'>
<factor value='2' />
<factor value='5' />
</number>
<number value='11' square='121' />
<number value='12' square='144'>
<factor value='2' />
<factor value='3' />
<factor value='4' />
<factor value='6' />
</number>
<number value='13' square='169' />
<number value='14' square='196'>
<factor value='2' />
<factor value='7' />
</number>
<number value='15' square='225'>
<factor value='3' />
<factor value='5' />
</number>
</numbers>
This is a compact and maintainable solution to the XML document creation problem.
The use of builders to construct complex hierarchical structures be they XML documents or Swing GUI interfaces is a very powerful facility. This shows the strength of Groovy's meta programming and its support for closures.
Next week I plan to take a few days off and build a web application with Grails and Groovy. Wish me luck.
[*] I love this phrase. So much of what is open-source is written by people either learning the language, learning the domain, or learning the patterns. The older the language or the library and the greater the likelihood that what you have in hand has had several generations of revision and revisers and is the best that it can be. SmallTalk's libraries are the epitome of this. Most new languages and libraries (Groovy included) are written by folks while they are "on the learning curve." The result is often baroque, idiosyncratic, flaky near the edge cases, etc. ¶ With that said, one of my employability facets is that I build on the learning curve all the time! ¶ I have no idea where I first heard the phrase "building on the learning curve." If you know to whom I can attribute it to please contact me.
The images show an original picture and a re-imagining of it using whole images found on Flickr. This has been done before at the pixel level where images are picked for their approximation to the pixel in overall color and brightness. Using a coarser granularity, however, produces a much more interesting image. Chris, my wife and artist, likens the result to the the value of chemicals found in the human body.
