Joerg Plewe's Blog

Why I don't use Groovy: I just cannot.

Comments

• Modern IDE's make it easier and faster to write a java program than a Groovy script, because of these excellent code completion features.
  I personally prefer Eclipse IDE. Eclipse has such powerful functions like 'Quick Fix' and 'Content Assist'. They make it a pleasure to code in Java. The IDE always knows what i have to code next. It's like magic.

  Posted by: gruenewa on August 17, 2006 at 04:21 AM

• The eclipse groovy plugin is totally broken. It strongly reminds of the good old emacs time - except that indentation does not work at all. From my point of view, the usability of groovy would rise dramatically if the IDE support would be better.

  Posted by: fuad_abdallah on August 17, 2006 at 04:47 AM

• The couple of times I tried groovy, I came to the same conclusion you did. Once you get used to IDE completion, the java API is too verbose to be used "manually".

  Groovy really needs an API that has grown with the dynamically typed language much like python's API has - the python class library always seems more natural for python than the java class library does on groovy.

  Groovy actually does include some API sugar to make the simple things like easier, so you don't have to use BufferedReader/InputStream, etc to read from a file - it just needs more of that sugar - and have it documented and easier to remember than reaching for the java API.

  Posted by: wmeissner on August 17, 2006 at 05:40 AM

• I think that's one reason why I like Ruby - because I can read in a file with:

  foo = File.read

  So even though the Ruby Eclipse plugin just does syntax highlighting and not much in the way of method completion, it's ok, because frequently there's not that much to remember.

  Posted by: tcopeland on August 17, 2006 at 07:22 AM

• Hm... Reading a file in Groovy can be almost as simple...

  
  def foo = new File("foo.txt").eachLine { line ->
  println line
  }

  
  No need to mess with Input/Buffered/Readers and so on... The closure will handle opening and closing the file. You can go to http://groovy.codehaus.org/groovy-jdk.html to see the changes that Groovy introduces to many of the standard classes.

  Fred

  Posted by: freddyjean on August 17, 2006 at 10:31 AM

• Actually it is that simple in Groovy:

  def foo = new File('foo.txt').text
  

  Posted by: graemerocher on August 17, 2006 at 11:57 AM

• Of course, having code completion in IDEs for Groovy would be great. Someone has started adding support for basic completion for the Groovy Eclipse plugin. Despite it's not there yet, we can already navigate from variable uses to its definition, to classes, etc. If completion for statically typed variables were there, that'd be really great.
  But it's funny to see that only a few months ago that JavaScript started to have basic code completion. And not that many people complained about the lack of completion for JavaScript in the past. Same for the 13 year-old Ruby which only recently got basic completion in one or two IDE support modes.
  Writing shell scripts in bash doesn't provide completion either, except for file or directory name.
  Despite that, thousands of developers have managed to build scripts and even full applications without code-completion.
  Let's cross our fingers for the support of completion for Groovy!

  Posted by: guillaumelaforge on August 17, 2006 at 12:38 PM

• With Groovy being part of the Dynamic Languages JSR, I'm totally confident that more developers will turn to it after JDK6 gets out. That means more people interested in Groovy and more people that will be willing to help. I'm too am a user of the Eclipse plugin and I don't find the lack of autocompletion so great (but surelly love to have it). What I'd like to see is the GDK listed in the Help. =)

  Posted by: aalmiray on August 17, 2006 at 01:16 PM

• If you use Jython and Eclipse, you may use PyDev, an Eclipse plugin that has code completion.

  It's really cool for Jython scripts !

  Regards,

  Xavi
  

  Posted by: xmirog on August 18, 2006 at 03:03 AM

• I end up not using scripting languages at all really... A lot of scripting idioms don't transfer to Java, so API design via scripting isn't that useful. Java offers more options in terms of optimizing for performance, so again scripting languages don't transfer, and finally there's the type thing...

  The only thing I find scripting languages useful for these days is actually fine-tuning business logic. For instance, I put up a fast implementation of a search function for our business unit in half a day (TCL). I tweaked it for about 3 days in order to really make it behave as searches are supposed to behave. This included sorting, caching, suggestions etc. Then they reviewed, suggested minor changes, and then I reimplemented it in Java, in about 2 days.

  The tweaking would've been slower in Java, and I think that's fair to admit, but overall development was fast considering the maturity of the product.

  So the answer? Don't! I find that scripting languages are useful for only very high level problem solving, and if that's your goal, feel free. But for low-level Java api-design, why bother?

  Posted by: ilazarte on August 18, 2006 at 10:40 AM

• Lack of IDE support blocking you from programming in a language you define as cool and that you'd like to use?

  Call me a dinosaur, but lack of IDE support is not going to prevent me from programming with a language I'd like to use but I can understand what you're saying...

  Heck, I still use 'vi' (vim to be more precised) and I have been for the last many years...Sure, It'd probably be much easier if I was using a neat IDE like Netbeans - I have thought about it but this is not a the main priority for me...I just need my VI and some Java API doc that I can acces through my favorite browser and off I go at it...

  Would I pick another language because it has better IDE support? the answer is a NO. But that's just me.

  Now, am I saying that IDE support is not important? absolutely not but at the end, I am using the language I favor, I want and I can write some code...

  I'm not programming in Groovy but if I had to, that would not change a thing...and isn't it supposed to be easier to program with these last generation (dynamic) languages? (IDE-plugin or not)

  Hopefully your posting about your experience will trigger something...
  

  Posted by: forsini on August 18, 2006 at 12:54 PM

• Just last week I found my first "real" use for Groovy: build scripts. I moved a complex J2EE Ant built into a Groovy script (still using Ant), and I couldn't be more impressed at how simple it is now. Groovy is able to leverage the full capabilities of Ant, and it's types and tasks. So I've given up nothing in capability, and gotten rid of hundreds of lines of XML.

  And the IntelliJ groovy plugin seems to be working okay.
  

  Posted by: jsando on August 19, 2006 at 07:51 AM

• yes, the build scripting is another good example. Groovy makes ant easier ... but it definately competes e.g. with the NetBeans ant debugger! If ant editing gets even better supported by NetBeans, groovy looses advantages again....

  Posted by: herkules on September 04, 2006 at 04:03 AM

• Remind everyone that Groovy is NOT really a scripting language. It's an alternate syntax that compiles to bytecode that conforms to what other Java classes expect.

  It's really one of many mutinies against the current situation with verbosity that threatens the comprehensibility of everything we work on. You *can* and *should* declare types and not use def (closures should be type Closure, etc). You *should* precompile your classes unless you are allowing for re-configuration in the field. There's a hardheaded-ness in the Java syntax on these points that the traditional camp hasn't come around on yet:

  
  When you MUST opt out of the compile-time type checks for a moment, it must be *less* verbose/redundant because it becomes more critical that you actually *understand* what is getting compiled. In Java, when you need to opt out of the type system you do a lot of casting and reflection invokes. The syntax for these situations is completely ridiculous. Examples of pathological cases are almost everywhere in J2EE.

  Anonymous classes are a bad attempt to continue to make interfaces do things they aren't made for. There are situations where closures are the only thing that comes close. Much, if not most Swing code doesnt handle event dispatch threads correctly because it's entirely too inconvenent. This is how the common case of running a long op in it's own thread then notifying the UI should look in Swing (using some Groovy to show its clarity):

  
  //Notice that this variable is not final
  String dnsName = null;
  invokeAsync {
  dnsName = dnsLookup();
  invokeLater {
  hostnameTextField.setText(dnsName)
  }
  }

  
  This is the sort of thing that happens thousands of time in Swing code, but nobody does correctly because this code is illegible when done correctly in Java. This is not unsafe. It's more safe than in Java because it's almost impossible to misunderstand.

  Look at some Java DOM parsing code written by another person. Even if it's not messy, it's so verbose that you can't quickly envision what the original XML looks like. Being able to iterate/extract/write into XML as a composite structure should be very direct, and unencumbered by all the API goo that surrounds it. But the only way that reading in XML would be typesafe with Java is if the DTD were transformed into an API that codifies the tagnames into members that can be checked by the compiler. But code generation isn't nicely integrated into Java as a first-class member either (etc..when code generation is used, debugger would step into the ultimate source - not the stuff generated behind the scenes.) So, for XML parsing without a DTD, why not use runtime-checked member invocations to iterate over the structure? It's much more readable, and is not less safe.

  //The intent here is clear with this sort of syntax
  doc.html.head.title = "My Web Page"
  ...

  Alternate syntaxes like Groovy can be used in the role of configuration language. The reality of integration is that often you will have a pair of components that you would like to wire together at deployment time and may have to have a little code to handle partially compatible interfaces. Look at a Spring XML file, or some of the JBoss config files, or Ant files. There is a lot of script code cross-dressing as data. Then you can decide to either deliver a pre-compiled configuration, or allow it to be edited by the customer.
  

  Posted by: rfielding on May 01, 2007 at 11:26 AM

This work is licensed under a Creative Commons License.