Late last year I got interested in a programming language called "Groovy."  The language looked interesting because it appeared to be what Java would be if it were written today, rather than the mid-90s (yes, it's that old).  A dynamic language running on the JVM and featuring full access to all existing java classes and libraries, Groovy seemed as if it would be a timesaver and a fun thing to learn.   Rumor had it that Groovy required far less code to accomplish the same things as a similar Java program and as someone involved in leading many development projects, for me, this held the promise of greater productivity leading to shorter development times.

<!--break-->

My experiences with Groovy began where many programmers begin their journey into a new language: writing "Hello, World."  This inane ritual which dates back to the late 1970's when Kernigan & Ritchie first published first published "The C Programming Language" with the worlds first example of "Hello, World" has become the standard first program that most programmers write in any new language they're learning.    It's not so much a good example of what one can do with a language, but the initial reassurance that the environment is set up properly and that it is possible to successfully write something that works.

My next step was to jump into writing a small GUI-based desktop application for one of my clients.  The application was designed to enforce a workflow where the contents of incoming files in an upload directory were evaluated by a person and then manually dispatched using the program to working directories on an internal network.   Writing GUI-based applications in Java has always been a somehwat tedious task.  Groovy's SwingBuilder allows one to easily write GUI code in a simple declarative way. You simply declare the widgets you're using, along with their attributes and SwingBuilder does all the heavy-lifting of creating objects and wiring them together for you.   My first GUI-based cross-platform (the client needed to run this under both Windows and Mac OS X) Groovy application was up and running in under 10 hours, and using an estimated 70% fewer lines of code than if I had written it in Java.

Groovy's dynamic typing (it supports static typing too), closures, lists and maps make it easier (think: less tedious) to write code.  I've heard the argument made that dynamically typed languages are not suitable for team development, but having run development projects for years using Perl, PHP and Python, I've developed the beiief that the productivity gains from dynamic languages outweigh any potential losses from tracking down type errors during debugging and QA.  Testing needs to be done whether one uses statically typed or dynamically typed languages.  The bugs/lines of code statistics definitely favor dynamic languages.

After writing several desktop applications, I was curious to investigate Grails, an MVC (Model-Viewer-Controller) web framework for Groovy.  Grails uses a "coding by convention" (a la Ruby on Rails or ASP.NET MVC) paradigm that allows automatic associations between components based upon name.  Grails can auto-generate a database schema, controllers and views based upon definitions of domain classes.  Basic CRUD (Create, Read, Update, Delete) functions are generated - either as editable code that can be modified, or dynamically at runtime (for simple apps/operations).   Grails Object Relational Mapping (GORM) provides a simple-yet-powerful way to define domain classes and relationships (One-to-one, Many-to-one, Many-to-many).  The details of the creation and storage of these objects within a database (such as MySQL, for example) is handled quite transparently as is locking, caching, and timestamping.

Grails' taglib functionality (borrowed from Struts) provides a powerful and easy to use method of componentizing frequently used routines for presentation.  Tags allow for syntactically pretty pages which are, IMHO, easier to debug.

 "Coding by Convention" relies on uniform naming schemes rather than XML configuration to bind components together.  This allows Grails plug-ins to easily modify the appearance and behavior of existing applications, often with little modification required to adapt the new functionality.

Overall, application development with Grails is fast, really fast.  In each of several projects, we were able to get done in weeks, what migh have taken months without it.  Despite frequent releases of both Groovy and Grails (most are evolving rapidly), the platform proved stable and reliable enough to reach production.

100K+ lines of code into running development projects based on Groovy, I'm happy to report that Groovy and Grails have provided many productivity benefits for developing applications, both for the web and for the desktop.  I highly recommend both Groovy and Grails as "high-productivity" programming environments for development.  I'm eager to watch both mature and develop further.