Summary
The last time I paid any attention to Groovy was when Mike Spille blogged about it, and when the Bile Blog chimed in (links below). Basically they wrote off the project (albeit giving lots of details about why). But recently the Java Posse talked about it in slightly different tones, so it made me start wondering.
Advertisement
Here is
How Groovy Lost its Groove Thang posted by Mike Spille almost a year ago, and
The groovy sinking ship posted on the Bile Blog (warning: foul language) a month before that. Both of these longish posts did a fairly serious analysis of the situation and decided that Groovy was toast.
Although the Java Posse was reasonably positive about Groovy, they did acknowledge that it had some problem areas -- syntax problems and obvious bugs that should have been caught before shipping -- and then they seemed to hedge a little. These were some of the same issues that the above articles talked about so I'm wondering if anything has really changed.
Is anyone actively using Groovy that might be able to give some insights? Or can you point to other articles or weblog entries?
The problem with projects that go awry is that it's rare that people actually announce that fact. It seems an issue with business in general -- we loudly announce our new projects and successes, but people tend to learn more from failures than they do from successes, and we tend to try to cover up our failures. Also, if a company is depending on a technology, it's rather important to know if the project has gone off the rails, but that's very hard to find out.
Then again, the fact that Java 6 is supposed to provide better support for dynamic languages may change the picture.
Scala http://scala.epfl.ch/ seems to be still in heavy development, but I don't know much about Groovy.
I guess Groovy was supposed to be an official scripting language for the JVM.
It seems like Sun should give an official nod to some other agile language or come up with something on their own. Hell, even Microsoft employees the guy that does IronPython.
I have to say that I think Groovy is a solution in search of a problem. They're trying to define a new language syntax for a Java-hosted scripting language? I would think that Beanshell (bsh), which runs interpreted java/javascript code would be preferred by most Java developers. We use it extensively in-house, where Network Engineers can use a friendly CMS to edit basic network element configuration scripts without having to learn how to compile, package, and deploy code to our app servers.
And the remaining folks who don't like Beanshell would, I expect, use Rhino JavaScript or Jython. Why in the world would we need a new language to solve dynamic typed, real-time interpreted problems?
Disclosure: I have been a Groovy Comitter for about two years and am still active in the project.
Groovy is not dead and is being quietly adopted for production use around the world (I recently consulted for a US Fortune 500 corporation using it in a large mission critical application).
Language development is a long and taxing process. It doesn't provide instant gratification. I think we have addressed and resolved all the issues raise by Spille as well as fixing some more fundamental issues that he did not notice.
Languages do not spring fully formed into the world - both Python and Ruby spent several years in complete obscurity before emerging into the limelight. I think we in the Groovy team did ourselves a disservice by encouraging the attentions of the Boggerati before the language had time to settle down. The JSR didn't help either.
So Groovy goes on under the steady hand of Guillaume Laforge. We have a usable system now but there's lots more work to be done, especially on performance.
Now to address your question; Does Groovy Matter?
Probably ;)
The JVM is not an ideal platform for dynamic languages and every attempt to implement a dynamic language on the JVM adds to our understanding of the problem. Groovy differs from Jython and JRuby in that it is not constrained by an existing language design. In principal, this should allow us to reduce the impedance mismatch between a dynamic language and the Java libraries available on the JVM (which is one of the huge attractions of using the JVM). So we have both statically and dynamically typed variables which helps us to deal with the method polymorphism exposed by many Java libraries (i.e. overloaded method which are selected on the basis of the type of the parameters)
So Groovy matters because it is yet another approach to the problem of implementing a nice dynamic language on the JVM. We hope it matters because it will eventually become the dominant dynamic language on the JVM, But that's for the future to determine.
I think many developers out there just don't get the fundamental advantages of using a language like Groovy. Unfortunately Groovy's documentation is very poor I hope that the upcoming Groovy in Action book by Manning will change that as apparently this is a situation that will be rectified after the books release. I recently saw a post on the groovy mailing list asking about Groovy's power features and the answer was "there is no documentation".
There are things in Groovy that are simply impossible in Java like builders, closures, the groovy truth etc. but the thing that excites me most about Groovy is the potential of Meta programming.
It essentially allows you to create DSLs that allow for a more concise syntax and allows many of the concepts of AOP in a dynamic language. You can inject methods, properties, constructors, fields etc. into your objects at runtime. You can intercept calls to methods and change the behaviour. You can even add new methods to existing core java classes. This is why it rather amuses me when people compare it to something like BeanShell, there is simply no comparison.
I'm project lead on the Groovy on Rails project (http://grails.codehaus.org) which although has a similar name to Rails has many differences. it is not quite ready for release yet but will be before JavaOne where it will be presented. Grails is really an example of using Groovy's power features, for example:
On a professional level I started using Groovy as a glue language to pull together process' and aid in content aggregation for my business' rapid e-Learning development tool. Since then I havn't looked back and have been writing web applications with a combination of Groovy and WebWork. Given how more and more of my business is moving to web based delivery I wanted to continue to benefit from Groovy's power and have RAD web development hence why I started Grails
I've been a fan of groovy-esque type languages for a while. But I think that it's an idea that never quite lived up to its potential.
When I <a href="http://alblue.blogspot.com/2004/07/groovy-is-almost-here.html">blogged about it</a> in July '04, I thought that it was almost ready to go.
In <a href="http://alblue.blogspot.com/2005/01/groovy-is-stuck-in-groove.html">Jan '05</a>, it was clear that it was in the same place that it always had been.
The problem is that it was designed, much like Jelly (xml scripting language) as a good idea but with no firm foundations. Most of Maven's power grew up from experimenting what worked and what didn't, and it's only recently that things have become defined, but in retrospect.
Whilst you can design things in retrospect with a system, you can't do that with a language. Heck, most of the arguments in the JSR were about trifling details instead of saying 'Why don't we just nail down the grammar of the language and start from there'. Even the groovy parser/interpreter has been thrown away a few times.
It's a shame; I think the world needs a language like Groovy. But Ruby and Python have got such a following that realistically there's no reason to choose Groovy these days, especially when it comes to IDE integration (where RadRails really kicks).
We don't see the invokedynamic bytecode as much of a benefit. As all our method calls have to be routed via a MetaClass the compiler never generates a direct call to a method on a class. Of course we will have to see what Bracha comes up with in the end but we are not hopeful at the moment.
. Steve Yegge coded a GUI Sokoban game on every JVM language he could find that could use Swing (only nine of over 200 JVM languages). The website has each of the programs as well as his (currently incomplete) comments on the nine languages, both in themselves and as candidates to replace Java. His review of Groovy ("betas" 9 and 10) is damning. Taking his account to be accurate, though, the most damning criticism you could make of Groovy would probably be "why bother? What does it offer that Jython or JRuby couldn't provide?"
(I'm just reporting here; among other things, I've never used Groovy myself.)
That most damning criticism is exactly why I haven't allocated the time to pick up Groovy. I already know Python. Jython is the natural extension for it.
Why would I want to even bother about Groovy? If you know Python, you can code for CPython, for Jython, and for .NET's IronPython. Groovy? Meh.
There is another language in my list to learn. But it starts with "R", and it rhymes with booby.
To be honest there has been a lot of FUD spread around about Groovy and I guess Groovy's big mistake was marketing itself too early. Its a very young language (when compared to Ruby which is as old as Java and Python even older) and has improved greatly since articles like the one about the Sokoban game was written.
Its still not perfect, far from it but it has huge potential. Languages like Jython and JRuby suffer from the fact that the syntax is not java-esque and the real power behind languages that they originate from (ie Python and Ruby) is there ability to so simply interface with natives C libraries. Something that is impossible in the JVM without JNI, at which point it gets ugly.
BeanShell cannot really be mentioned in the same breath as Groovy as it is quite simply java without the typesafety.
In my opinion the 2 languages with the most potential as truely dynamic languages for the JVM are Groovy and Pnuts, the rest are either 'pretend' dynamic languages that only provide half the solution or ports from other languages that don't provide that neat fit with Java (apologies if I'm missing any languages out but the ones i have mentioned are the ones I have looked at)
The only thing which put me off was Mike Spille's blog. Why bother learning a new language when it's that bad below the surface? Whether Mike's article was factually correct or not, the amount of destructive bile which came with it did Groovy an incredible disservice.
I think that in the long term, the JVM is going to prove far more significant than Java itself, and getting an elegant Ruby-like language which runs, and which is designed for, the JVM will be a great step forward.
And Groovy fulfils this. It's elegant and it's designed from the ground up for the JVM.
As far as I can see, James Strachan did a great job on the conception of Groovy. Anyone who can dismiss the importance of that kind of pioneering effort with lists of complaints about lack of error reporting, dodgy comments in ANTLR code, etc, really is not seeing the wood for the trees.
Now that the initial hype about Groovy is long past, I hope it continues to develop and stabilize at its own pace, and developers can choose to use or ignore it on the basis of its merits and not on the basis of the hype and bile it's had to endure in the past. As soon as I've got the confidence that it's stabilized as a language and production tested, I'll be using it.
Warning: This is one of those "I did not do anything to improve it, so I bitch about something I am getting for free" posts.
I am using groovy with Ant scripts and thus far I like it. It has some very interesting language features and they are neatly integrated into java-specific surrounding. However, documentation for the project is worse than documentation I make. And that means BAD. I mean maybe I am not looking in the right places but I can not find any information about variable scope and about functionality around the 'def' keyword. There are usecases and examples but there is no language specification that I can see. Documentation that formally defines language itself with its features is just absent. "there is no spoon", everybody can use it and see it but it's just not there. I will try to not even comment about JSR, which is few pages ripped from Java(TM) spec. I can live through the bugs, I can even help debug them and test them but I will not recommend to my management use of technology that lacks basic documentation about what it is.
> That most damning criticism is exactly why I haven't > allocated the time to pick up Groovy. I already know > Python. Jython is the natural extension for it. > Exactly. There are far more mature languages already available if you really need a scripting language. Why learn another one (and one that can hardly be called stable to boot)? Most of us have a hard enough time already staying current in the technologies we use to pick up yet another one just to be seen using it.
> There is another language in my list to learn. But it > starts with "R", and it rhymes with booby.
Looked at it, too similar to Python in what it can do for me to bother with it.
Flat View: This topic has 16 replies
on 2 pages
[
12
|
»
]
Previous Topic
