I always try to stay on the open minded part of the population. I have been trying with Groovy too… Half year later I can state – it is a fancy toy that looks great in the sample, but not a generic purpose language.
Groovy advocates usually have following reasoning:
Static typing doesn’t give any benefits – you have to unit test anyway
I am almost certain that nobody will ever hear from me that testing is unnecessary – quite the opposite.
But type checking allows to instantly identify a whole bunch of common coding mistakes, without need to wait for the tests to execute (and those can take some time)…
Java is too verbose, Groovy is much more compact.
Let’s make the identifiers optional wherever there is only one token in scope that fits! Compiler can figure things out and the code will be 17 bytes shorter!!! All this time I would have spent so much time on pressing the space…
Java is verbose – but what is wrong in being verbose? The more compact code, the more comments are required and it the end it sums up to the same number of bytes. I could start writing a more verbose, self explanatory Groovy code too. In other words – to make a code that is easier to read I would have to discard the compactness of Groovy. In such case – why bother with Groovy at all?
I don’t deny Groovy the right to exist – I definitely can see its the benefits. There are even things in Groovy I really like. Closures. Compact syntax for creating instances of ArrayList and HashMap. XML parsing. Groovy definitely can be useful.
However I am certain that those are only the situations when once you got working code, you never touch it again… Projects when the functionality has to be there now, and will be thrown away week later. Or tiny, very specialized classes you can throw away when they need to change and write them again. Refactoring a Groovy code will be a nightmare – because of its dynamic nature.
So – if doing anything with longer time frame, anything that might get refactored – keep away from Groovy.