So we’ve been busy at work for the last six weeks building a new version of our software that will run as a web application. I can’t link to anything about it yet because it’s not finished, but we’re already having fun trying out new stuff.
One of the biggest new things that we’re using is Grails. Grails is a neat web application framework that builds on the well-known enterprise Java stuff like Spring and Hibernate. It also uses the Groovy language.
Obviously jumping into something like this is a huge change. It has meant that we have had to redesign the whole system so that it fits the framework and we’ve had to change the way that some stuff works. It’s not often that you get the opportunity to completely start from scratch to build a new version of software.
One of the reasons why we were able to justify doing this is that Grails is such a brilliant environment for rapidly developing applications. For example, we have been able to pretty much build a system that functions and could be useful within just a few weeks. Obviously there’s still an awful lot of polish needed before it can be put in front of paying customers, but with Grails we’re able to get to that point much more quickly.
Also, from an engineering point of view, Grails is a lot neater to work with. It uses the model-view-controller paradigm from the off and pretty much forces you into sticking with it. This is good engineering practice, particularly as we are able to much more explicitly segregate application logic and view rendering and the domain model.
Another important advantage for us is that we can reuse a significant proportion of our existing code that was written in Java. Groovy code compiles to the same Java bytecode and runs in a normal Java virtual machine. This makes integration of Java and Groovy code a doddle.
Groovy has a huge pile of features that can improve developer productivity. For example, it introduces untyped variables, closures and lists/maps as explicit syntactic entities. It is also totally object oriented - all the primitive types are now used as their class equivalents. It looks a bit strange to be calling a method on a number, but this is now quite useful. Groovy makes querying the database a trivial activity - dynamic finder methods make it quick to write simple queries or you can use a Hibernate query language (HQL) builder to construct an HQL query if you want more complexity.
Untyped variables are useful in some areas. It makes it useful to just define a variable without caring what type it has. Of course, you can still have everything fully typed if you want - static type analysis at compile time really is a good thing and can’t be ignored completely!
We haven’t yet found uses for all the features of Groovy and Grails - stuff like metaprogramming looks like it may be useful but is not yet necessary for anything that we do. Obviously learning a new language and framework means that after a short time you have to go back and refactor some stuff now that you’ve worked out the proper way of doing things, but even so, we have seen a huge gain in productivity.
The downsides? Well, it clearly new to us, so we’ve had to learn it. And this is on-the-job learning too! Some of the documentation is out of date or not quite up to scratch - this is noticeable as Grails is only recently maturing as a quality framework and stuff has changed a lot up to around a year ago. Grails has stabilised nicely though and we are seeing a continual improvement in the quality and availability of the documentation.
One risk that we considered was that Grails and Groovy were relatively new technologies. It’s clearly a risk that stuff might change or that they go out of favour.
All in all, Grails and Groovy appeared at just the right time that we could get started with them. They have proved a godsend to us and may possibly be the enabling technology that allows our business to succeed.
“untyped variables” is the best thing I know to reduce(!) the developer productivity. You don’t need enemies anymore if you have untyped variables.
Groovy is a nonsense. It much more complex than Java (=powerful), nontransparent like Perl (=flexible) and more error-prone than PHP (=dynamic).
The support on the IDE level is very basic. The lot of functions like Autocompletion, Code navigation, Debug or Refactoring work only halfway.
Rodion,
I agree that untyped variables can cause problems. Hence my comment that they are only useful in certain places. In fact, in our project I have just written the coding standards and recommended that typed variables are used where possible.
I come to Groovy from the perspective of a Java purist. My first thoughts were “argh, this is so complicated”. Then I realised that most of the “complexity” is just stuff that is in Perl and PHP anyway but it a right pain in the arse if you’re using Java. This is a big win - there’s a learning curve but nowhere near as big as there would be going from Java to Perl or PHP.
PHP is just awful as a language. I have seen so many people who “code” in PHP, but they get lulled into all the traps that a dynamic language can cause. Groovy is a nice middle-ground. Perl has always and will always remain the perfect language for text processing - hence the acronym that was applied to the name Perl (practical extraction and reporting language).
One thing I agree with is the IDE support. However, IDE support for other “web” languages like PHP has only recently matured, so I don’t see it as a big deal. We are already seeing productivity improvements using Groovy with IntelliJ, even considering that some IDE features are only partially optimal.
By the way, in selecting the framework and language for our project, we did a *very* through cost-benefit analysis. We even went to the level of producing a prototype system to make sure we understood the consequences of our decisions. In the end, the decision was based firstly on the need to integrate or reuse code from a legacy Java system and secondly on the skills of the development team (being mostly used to Java). It’s a bit early to say whether our decision was correct, but so far I have yet to see any significant concerns regarding our decision.