Nelz's Blog

Mah blogginess

Groovy/Grails One

Last night I went to the "Groovy/Grails One" session, hosted by the folks from No Fluff Just Stuff. (Originally I had started copying the slides, but during a break Jay said he’d post the slides to the NFJS site… Which is good, so I don’t have to repost a lesser-quality version of the slide contents, and this will allow me to post more of my impressions, rather than content that has already been written by someone else…)

Dynamic languages have been getting quite a bit of press lately. I can see why… They seem to be really flexible and quick to develop in. I believe the flexibility is what people chafe at with Java in general, so I can understand why people are so excited about porting dynamic languages to run with Java. (See Jython, JRuby, Groovy.)

Groovy seems to be unique amongst the Java-enabled scripting languages in that it can work directly with old school Java objects. The fact that it can make Java development quicker and easier, yet compile down to the same byte code is incredibly attractive to me. File manipulation, IO, XML parsers and encoders all seem really cool.

Grails, following th lead given by Rails, is a web-platform accelerator that encourages convention-over-configuration. It uses it’s own layer of stuff on top of Hibernate, along with a bunch of open-source libraries to get a web app up and running right quick.

I had been thinking about looking into Ruby/Rails recently, but since I’ve attended this session and learned about Groovy/Grails, I’m gonna shoot for that instead of the Ruby/Rails combo.

At the end of the evening they opened up a Q&A/panel discussion. One of the questions that someone asked is "Why Groovy/Grails over JRuby/Rails?" I thought it was a great question, and the response was just as cool… Basically, if you are a Java programmer, you can pick up Groovy with very little overhead, yet have all the same benefits that are part of Java. If you are not a Java programmer, JRuby is really easy to learn w/o having to know all the other Java cruft. Both solutions have their forte’s…

Also, someone asked about strict/strong typing versus dynamic typing. Neal Ford was there, and he got on his soapbox that I’ve heard him on before about how strict typing is just "bureaucracy". This time it sunk in a little bit better for me. Basically, his premise goes like this: Everyone agrees functionality is guaranteed by testing, so why involve the compiler to limit what types of objects are being used? I dunno if that overly simplified explanation works for you, but it did for me… (Update: Neal Ford posted a bit about this here.)