Malcolm Davis's Blog: Groovy isn’t hip

With a kind of weird cryptic syntax, it reduces the lines of code by making code less readable. Didn’t’ we learn our obscuring lesson with C? The beauty of languages like Python is not only the abstractness and easy of use, but also readability. Of course the creators of Groovy will rave about its virtues, and an ugly baby will always look beautiful to its mom, but this baby needs to be put to sleep.

If you’re looking for a higher level (more abstract) OO language, you might consider Jython, or look at the Bean Scripting Framework at Jakarta

Positive Note: I found Groovy’s flaws in a one-hour presentation, rather than several hours of playing around with the tool. A good reason to be at JavaOne.

Bookmark blog post:

del.icio.us

Digg

DZone

Furl

Comments

Comments are listed in date ascending order (oldest first) | Post Comment

BSF ain't a language
FWIW BSF is a framework for integrating scripting languages with Java code - so its not a language and so can't possibly be compared to either jython or groovy.

Hey if you prefer Python and find its syntax more understandable go for it, use the tool you prefer.

Though I'd be interested if you could describe which bit of the syntax was cryptic or 'lower level' than python - a language which makes extensive use of special magic underscored methods and uses 'self' parameters rather than use object primitives.

e.g. you claim to have found groovy's flaws - care to describe any of them?

Posted by: jstrachan on June 30, 2004 at 03:14 AM

Cryptic?
I am surprised you found it cryptic. To me it seems to have simply taken a lot of the more convenient and powerful pieces of python and ruby (particularly ruby) and made them more java-ish. Frankly, imho, where it tries to adhere more to Java syntax is where it starts to look less natural to me. (I fall into the "other camp" Rod mentioned (I want strong Java compatibility, but doing it at bytecode is fine, the language doesn't need to look like Java ;-))

I really am curious what you found cryptic. To my knowledge, the syntax has been designed to use the clearest idioms used to express most features, while specifically trying to keep it Java-developer friendly.

Posted by: brianm on June 30, 2004 at 06:07 AM

A lot like Ruby
I think Groovy was inspired in large part by Ruby. Which is very clean, though a little alien to the C, C++, Java, C# style of Syntax. Ruby is a mix of Perl and Python and is cleaner than both.

I've used Groovy for an article recently and the only problems i found were that the documentation was a little ahead of the language implementation. So the docs would tell you that this looping construct would work when it didn't.

I did find the {:} syntax for an empty has a little annoying. I would prefer this {} for an empty hash and this [] for an empty array.

Posted by: jherr on June 30, 2004 at 06:55 AM

A lot like Ruby
I hear you - we ended up going for [:] and [] for empty maps & lists so that we could reserve {} for blocks and closures to avoid ambiguity.

Posted by: jstrachan on June 30, 2004 at 07:55 AM

BSF ain't a language
I agree, BSF ain't a language.

However, its direction is much closer to the type of work the JCP does than the Groovy effort is.

Most JCP efforts work on standardizing APIs for the language, in general, not separate langauges. As such, its usually more interested in the Interface + reference/vendor implementations approach. This makes the BSF very much like JDBC, EJB, Servlets/JSPs, etc.

That Groovy supports the BSF in its release shows that the BSF is actually of higher importance in the bigger picture of things. Being able to use the same API to handle any scripting language is far more useful to the Java developer than the specifics on the language itself.

Posted by: acroyear on June 30, 2004 at 08:07 AM

BSF ain't a language
There's also JSR 233 which specifies a standard binding from the Java platform to any scripting engine including a web-tier connector for using any scripting language (PHP etc) inside web apps.

The JCP process is big and scalable enough to handle standardising both APIs to things (like JSR 233) as well as standardising languages like the Java language (which is done through the JCP process) as well as other languages like JSP / JSTL / JSF as well as Groovy.

I'm sure there's room for more languages to be standardised through the JCP process too (e.g. a standard rule language syntax would be a good idea).

Posted by: jstrachan on June 30, 2004 at 08:31 AM

Very annoying...
It seems to be a kludge to me. I read all the stuff on the Groovy site and its seems a mish mash. Then I read this:

Works:
[1, 2, 3].each { println it }

Works:
[1, 2, 3].each (
{ println it }
)

Doesn't work:
[1, 2, 3].each
{
println it
}

Whitespace has NO place in a language like Groovy. It is just plain wrong to have special cases like this.

Posted by: zatoichi on June 30, 2004 at 08:51 AM

Very annoying...
Agreed - though not its not whitespace sensitivity per se, its newline sensitivity. Today Groovy assumes that each line contains a complete statement and so statements can only span multiple lines under certain circumstances - and passing a closure into a method can't today span multiple lines as you describe. Though if you really wanted to format your code like that you could do

[1, 2, 3].each(
{
println it
}
)

This whitespace issue is being debated heavily by the JSR and yes folks are concerned about this. Basically this is an argument for mandatory semi-colons which would avoid this whitespace sensitivity. We'll see what the JSR EG come up with

Posted by: jstrachan on June 30, 2004 at 08:57 AM

less absolutism please?
> Didn’t’ we learn our obscuring lesson with C?

well thats a little below the belt..

I've used groovy a little bit, a tiny bit of BeanShell and am going to also look into Jython

i don't think the kind of absolute statement is very useful - a balanced critique would be better

i've not really learnt anything from this blog apart from the author went to a presentation on groovy and decided he didn't like it

Posted by: asjf on June 30, 2004 at 09:36 AM

less absolutism please?
yes 'absolutism' is the right word.

"Sometimes reality doesn’t meet expectations, and that’s how I feel about Groovy"

Fine.

Sometimes reality doesn’t meet expectations, and that’s how I feel about Swing, EJB and certain other APIs ... but I do not fall back to absolutism then.

Posted by: thebohemian on June 30, 2004 at 02:28 PM

Groovy Success Story
Here is an email about an agent simulation model done in RePast, using the Groovy language. The short summary is that the Groovy advantages such as automatic getter/setter pairs for beans, concise language features, brevity and so on really do add up to an interesting scripting environment for Java.

I have found that it is really difficult to evaluate something as complete as Groovy without an in-depth study like this and I would love to hear from more of you trying such a stunt.

From: Owen Densmore
Subject: Groovy / RePast success!

Just a quick note to let folks know I've been successful getting the RePast simulation environment to work nicely with Groovy.

Basically, I wrote a trivial RePast model (TinyModel.java), bypassing the SimpleModel class which had caused problems in my earlier emails. The model simply creates a bunch of randomly colored balls and has them move about randomly, being careful not to step on each other (occupy the same cell in the RePast grid).

I then copied the java code into a groovy file (tiny.groovy) and started hacking away the compatibility problems. Took about 2 hrs. I then made a copy of this file (nifty.groovy) where I started using the nifty groovy iterators and taking advantage of the bean styles etc. Note: This JIRA entry was the one thing I cold not work around.
http://jira.codehaus.org/secure/ViewIssue.jspa?key=GROOVY-451

The interoperability with RePast was quite nice .. RePast is a bit demanding, using reflection and bean setter/getter pairs for managing parameter adjustments. In the image (GroovyRepast.jpg), for example, the NumAgents and SpaceSize are such properties.

The performance is really quite snappy. One case I ran was to have 20 agents run for 1000 ticks. RePast/Java = 20 seconds; RePast/Groovy = 23 seconds. These were run on a Mac/Panther environment, using CLASSPATH set to the RePast libraries and using JDK 1.4.2.

URLs:
http://backspaces.net/files/GroovyRepast.jpg
http://backspaces.net/files/TinyModel.java
http://backspaces.net/files/tiny.groovy
http://backspaces.net/files/nifty.groovy

Posted by: backspaces on June 30, 2004 at 04:47 PM

Powered by
Movable Type 3.01D

java.net RSS Feeds