two points: 1) In Groovy you can optionally type your variables/method signatures. 2) IntelliJ's Groovy plugin is IMO way better than the Eclipse plugin. I've found adding in type info to the method signatures/variables gives me fairly close to Java level quality of IDE help. The IDE can help much more when it knows your variable types.....
I still say the "ideal" language would have inferred static typing w/o optional dynamic typing. And I say this with Ruby being my favorite language. That's why I'm a fan of Mirah http://www.mirah.org/.... 2011/5/9 Cédric Beust ♔ <[email protected]>: > 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. > -- 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.
