I should start by saying, I'm not a Groovy person and I certainly don't want to dispute your claim that Groovy wasn't pulling it's weight in what ever it was that you were trying to achieve. And, I don't know why you needed to know the type of the parameters being passed in but it is my experience (mostly with Smalltalk) that having to know the type is a rare event. But then, that also depends on your coding/design style. Some people's thought process is just not well suited to dynamic languages. Having them move to that style of coding just doesn't work. Conversely, I've seen disasters with people with strong dynamic language backgrounds move into a strongly typed regime. I'm by far not the only one to have noticed this. (Smalltalk) Dave Thomas once commented that only 30% of developers were able to work in multiple coding paradigms. Now there were fewer closer to mainstream coding paradigms when he made this comment so maybe having people exposed to may have changed this ratio but certainly not to 100%. Fact is; polygot programming is simply not for everyone.
Regards, Kirk On May 9, 2011, at 7:27 PM, Cédric Beust ♔ wrote: > 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.
