The Promise Of Spring's Groovy On Grails

After having learned a dozen or so languages over the last 25 year, it takes a lot to get me excited about a language. Groovy On Grails gets me excited. Here's why:

DRY ("Don't Repeat Yourself") programming: Makes SO much sense, and is such an ancient and fundamental concept in software (perhaps any) engineering. Examples of this are third normal for relational databases (see "the key, the whole key and nothing but the key"), COBOL copybooks, pointers, and so on.

A good example of "repeating yourself" is what Matt Zaney once called "meat-grinding": Adding layers of code which essentially just move data from one format to another - screen-text to object to xml to object to database, for example. (See "The Layered Look" on this blog.)

With the demise of the copybook concept, the code purists, often the designers of the more recent languages, have been arguing that code refactoring is the right way to DRY a body of code. Well, that's great in theory and in the classroom, but not in the real world of day-to-day business programming. Repeating yourself (copy/paste/morph a chunk of code), instead of refactoring, is what real-world programmers are forced to do every day, when their boss is standing over their shoulder saying, "I need this done yesterday. Now just fix it and you can refactor it later." Somehow, there's never the time or will-power for "later".

"Convention Over Configuration" programming: This is an implementation of the DRY concept, eliminating the need for config files, especially in the early stages of agile development. Do a default behavior, and only config if you need a non-default behavior. See here for explanation. I guess someone at Spring finally agreed with "Crazy Bob" and me. (See "The Flexibility Mantra") because one of the new pitches for Groovy On Grails... from Spring, mind you, the same people who once touted xml-based IoC as almost the Holy Grail of software engineering! ...one of the new pitches is (drumroll, please) NO MORE XML configuration!

In concept, Groovy On Grails has the right idea, but unfortunately, the implementation is still too new and unproven to be a mainstream industrial-strength solution. IF (and that's a big IF) it ever matures, it will effectively reduce the number of layers to the minimum required for agile development. Things will have been made "as simple as possible but no simpler"...

...and this should help put an end to "The Layered Look" of "Stupid Computers". :-)