Funny that you should mention Groovy because I recently did a short dive back into it. I hadn't written Groovy code in a while, but not much has changed in terms of syntax (which is a good thing), so I was pretty comfortable from the get go.
However, after a few hours, I gave up and rewrote my code (a few hundreds of lines) in Java. What I needed was a text book example of where Groovy should shine: a simple script that processes some text and performs various transformations on it. Groovy's native support for regexps helped reduce some of the boiler plate, although I quickly found myself having to implement a few functionalities myself, which was unexpected. More specifically, I needed a piece of code that will do regexp replacing that preserves the case of letters. When I say I want to replace "foo" with "bar", here is what should actually happen: "foo" becomes "bar" "Foo" becomes "Bar" "FOO" becomes "BAR" A Groovy expert quickly confirmed that this wasn't supported by Groovy but rolling my own was pretty easy since Groovy's regexp replacement can accept either a string or a closure. Very convenient. I thought "Groovy is really paying off here". And then, Groovy's dynamically typed nature hit me hard: suddenly, the code I had written to customize the behavior could be passed either a String or a GroovyClosure. Next thing I know, I find myself having to do instanceof's and all other kinds of nasty things that made me increasingly uncomfortable. Add this to the fact that each time I wrote a method signature, my fingers were screaming to type these variables and it wasn't long until I found myself reverting to some limited form or Hungarian Notation to help me keep track of what happens. For example, imagine a method that accepts two strings and one regular expression... Good luck keeping your sanity without somehow encoding some type information in the variable names. And of course, there were a few times where I still passed "string, regexp, string" instead of "string, string, regexp". Grrr. The Eclipse plug-in worked a bit better than last time I tried it and while the Debugger stack trace is encumbered with a lot of stack frames that are not part of my script, the plug-in is smart enough to show there unrelated frames in a fainted font. Nice touch. I was also pleased to see that I could set breakpoints and inspect variables, that helped a lot diagnose problems. But at the end of the day, it became clear to me that Groovy wasn't pulling its weight, so I rewrote everything in Java. Rewriting the code took about fifteen minutes, then I Mavenized the project and a few minutes later, I had a full build with integrated tests ready to be checked into Github. Obviously, some of my negative experience is closely related to the nature of the project I undertook, but I really thought Groovy should be running rings around Java in that area, in all respects (higher level constructs, support for literal regexps and closures, etc...) but in the end, Java ended up beating it on pretty much all counts. I really want to like Groovy and I think that it's on par with Fantom in terms of nice syntax and functionalities, but it didn't quite work out this time around. -- Cédric On Sat, May 7, 2011 at 12:25 PM, phil swenson <[email protected]>wrote: > I was thinking about this the other day - why is groovy never > mentioned as java.next? > > then today I saw this nice write up on groovy as "java.next()": > http://batsov.com/2011/05/06/jvm-langs-groovy.html > > I've been doing a lot of groovy lately as we are reworking our entire > build/test/automation system in gradle. I really like the > language.... it's much more enjoyable to code in that java. Not only > is the language nice, but they cleaned up a lot of crappy Java APIs. > All the stuff that apache commons does to make what should be simple > data structure/file/xml/string/io tasks easy, groovy monkey patched to > provide directly in the Java APIs. (e.g. File.text reads in a file as > a string) > > *BUT* I don't think it's java.next. If groovy had decided to do > static typing way back when I think it would already be java.next (w/ > optional dynamic typing). But they didn't so it's simply too slow... > and a dynamically typed language will never have the quality of IDE > tooling that Java enjoys. Just isn't doable. > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
