Over the last several weeks, I’ve been asked a few times “Why Groovy?”  More specifically, it’s phrased like “Why should someone who already knows PHP/Ruby/ASP bother to learn Groovy?” or “If I was starting off a new project from scratch and had a choice between XXX (Ruby, Python, .Net, etc.) why should I use Groovy?”  I’ll attempt to tackle these as a whole, though there’s a bit of nuance between these questions I might get to also.

First, some background.  I’ve worked with web technologies since late 1995 (December, I think).  I got started in Perl, but was introduced to PHP/FI (PHP2) very quickly.  I used both Perl and PHP, then later ASP, from 1996 until around 2000/2001.  At that time most of the work I did focused on PHP.  In the intervening years, I’ve done small utilities with Python, played around with Ruby (nothing professional), Java (mainly doing Lucene/SOLR stuff), some .Net (a desktop app and webservice) and done a bit of Flex/Flash/AIR.  I’m by no means a polyglot at the level of a Neal Ford or Venkat Subramanian, but I am comfortable working my way around new languages (except Erlang – another topic for another day!)

In mid 2007 I was introduced to Groovy and Grails via presentations by Scott Davis and Jason Rudolph.  The presentations really got me excited about development again.  A somewhat new syntax with some nice features to make some of the boring stuff a bit easier (or redundant), some newish (to me) features (lambdas/closures) and a passionate community excited about the language were all reasons enough to get me interested in diving in to Groovy and Grails.

Looking back, this was almost the same semblance of qualities which attracted me so much to PHP back in the mid/late 90s.  There were certainly enough things in the language which made all the Perl/CGI stuff irrelevant (setting headers, parsing out POST values or loading the behemoth CGI.pm, etc.), the community was small and excited about the developments (especially when PHP3 hit the scene), and it was different enough (both language-wise and context-wise) from the early VB and Notes work I’d done to get me hooked.

These are also likely the same qualities which get many people excited about Ruby.  I’ve done a small amount of Ruby, and certainly appreciate the elegance of the language (in some cases) and the efficiency people find in Rails.  I just haven’t quite got ‘bit by the bug’ the same way I did with Groovy and Grails.  Yet.  Maybe that’ll change.  I’m working my way through Obie Fernandez’s “Rails Way” book these days.

But back to Groovy.  Why should someone learn Groovy?  I think there’s some abstract arguments to be made, and some practical ones.  I don’t make any claim that these are uniquely my arguments – I’m sure they’ve been made before, just not on my blog. 

Abstract

Learning a new language is good

At CodeMash 2008, Neal Ford gave a good keynote on the value of learning multiple programming languages.  When learning new programming languages, you get a better perspective on how problems are tackled by different camps, and can more easily learn to break down whatever problem you’re facing in different ways.  I do think you learn to think differently because of it.

This is not much different from being able to read/write multiple human languages.  My limited experiences learning Spanish and travelling to other countries has forced me to rethink how I use my words, and more importantly, how others may react to what and how I communicate.

This isn’t to say you have to be a master at every single programming language around.  But getting outside of your comfort zone will force you to rethink some assumptions about how you develop in your primary language(s).  You’ll also be exposed to other tools and techniques developers from other camps, which can also give you new ideas about how to tackle your day to day work.

Groovy is new, but not so new that you’re going to find breaking bugs every week like you might have a few years back.  The community is open and willing to help newbies.  This combination makes a great candidate for a learning language.  Yet the skills you learn can have immediate applicability, because Groovy compiles down to Java.

Learning a dynamic language is good

Jared Richardson gave our JUG some advice last year – learn something different.  This applies to the point above, but he was more specific.  To people who’ve only done Java their entire career (or C#, for the .Net people out there), learn Ruby, or Python, or Groovy.  This echoed Venkat’s point at CodeMash 2009 (lots of people are making this point these days!)

There’s productivity benefits in dynamic languages, and many of the drawbacks people have traditionally levelled against dynamic languages simply aren’t true, or aren’t true *enough* to warrant avoiding them.

Groovy is an excellent standalone dynamic language for learning dynamic language concepts.  The integration it has with Java makes it that much more comfortable for Java people wanting to experiment with dynamic langauges, but with the ability to fallback to ‘mainline’ Java, even in the same file, should they feel the need.

Learning a statically typed language is good

Many of the suggestions I’ve heard have been aimed at Java/C# people, urging them to took at dynamic languages.  I think there’s also something to be gained by people traditionally using dynamic languages like PHP, Python or Perl to learn from statically typed languages.  Understanding why compilers need certain things spelled out for them, or at least the implications of doing so or not, is a useful thing when thinking about how to write code.

Because Groovy sits on top of Java, you can be as dynamic or as static as you want.  Want to declare your property types as String, Int, Float, etc?  Go ahead.  Want to skip it for now?  Skip it.  Groovy makes a great learning environment for dynamic people looking to learn more about one of the most prevalant statically typed languages out there – Java.

Practical

Ecosystem

The Java ecosystem is one of, if not, the largest software ecosystem in the world.  If you need a library for something, there’s likely a Java version of it.  Because Groovy and Java can coexist in the same project (even the same file!) reusing all the solid libraries out there can be a real time saver.   There’s quite a lot of industrial-strength open source stuff already out there in Java.  This is not to say it’s “better” – certainly you could write the same libraries in almost any language.  Given that it’s usually already written, though, the practical argument for the rapid development aspect of Groovy gluing together the functionality of strong, time-tested Java libraries is a hard one to ignore.

The Apache foundation has a sizable library of high-quality Java components for many needs (Roller and JackRabbit come to mind). This is the sort of ecosystem I’m referring to.

Compact syntax

Optional typing, closures, builders and other goodies in Groovy make some of the repetitive boilerplate Java code (which made for nightmarish maintenance) a thing of the past.  I understand that other languages have this advantage too in some measure.  PHP could make most Perl code shorter *and* more understandable at the same time, for example.  If you like Ruby compactness and elegance, you’ll like Groovy’s too.  It’s not 100% the same, but definitely a similar spirit.

Productivity

This is more a plug for Grails than Groovy.  The Grails framework makes it very easy to build simple-to-moderately complex applications very quickly, and makes the very complex ones *easier* to manage.  The plugin architecture has spawned a growing mini-ecosystem of its own, and there are dozens of plugins to help manage many different aspects of your projects, from UI to database to security and logging and more.  The “domain first” strategy in Grails, coupled with the heavy-hitting GORM library, can also make for very rapid prototyping.

Being able to write this sort of code as a domain:

class Person {
    String name
    String email
    String phone
    Date birthday
 
    static constraints = {
        name(nullable:false)
        birthday(nullable:false)
    }
}

and have to do *no* database work because GORM creates the database tables for you, coupled with scaffolding which will generate (beforehand or at runtime – your pick) the forms with appropriate validation (and internationalization of messages) lets me focus on sketching out ideas of data structures, flow and business logic rather than thinking about creating databases tables and relations and stuff. You *can* manage all that by hand if you want (and you might *need* to later) but for getting ideas out quickly to test them, Grails has helped me be very productive.

Newer language features

Groovy is new enough that there’s still some new language features making it in these days (multiple assignments, for example).  But even if Groovy didn’t make one syntax change ever again, the syntax set is still far advanced beyond the traditional Java language.  Pure Java might not get Groovy’s feature set natively for many years, but you can enjoy the time-saving features today.

Drawbacks

Are there any drawbacks to Groovy and Grails?  Yep, there’s some.  Stacktraces in Grails when you hit an error really stink (still).  Groovy isn’t as fast as native Java (and may never be).  There’s a bit of a one-time startup hit due to some compilation (which is getting shorter every version). I’m sure there’s others many of you can think of.

Should this be enough to keep you away from at least *learning* Groovy?  I’d say emphatically *no*.  Learn it.  Play with it.  Take the time to soak up the ideas that are different from what you do day to day.  You’ll learn some new things, and will likely see your ‘regular’ language in a new light.

Wrapping up…

I still do PHP work, and probably will for some time, though I’m doing some Grails these days too. But the experience of having worked with Groovy and Grails the last 18 months or so has made me rethink my PHP yet again.  It’s not that I wasn’t aware of other language ideas (I’d put together one of the first MVCish frameworks for PHP back in 2000) which could be implemented in PHP.  However, continually keeping a pulse on other technology camps continues to make me a better developer.

The hardest thing is keeping a balance.  Many people suggest learning a new language every year.  I’m not quick enough to be able to do that, only because once I get in to one I like I tend to dig further in to that.  But I will likely do more Ruby this year, and continue with my PHP and Groovy as well.

I hope this has given you some food for thought as to why Groovy deserves some investigation if you haven’t done so already.