It seems that Groovy is almost upon us; another creation from the people who brought Geronimo to Apache.

Personally, I think that there's a lot good going on in Groovy, and though I've had my brushes with Strachan et al in the Geronimo project (I wrote the bulk of the JavaMail implementation, before quitting in disgust at the treatment of people who weren't with the 'in' crowd), there's a lot to like in the Groovy language. It bridges the gap between Java and JavaScript, in some senses allowing a scripting language to be used for creating programs.

That's not to say that all is good -- or well -- in the Groovy camp. The same 'Not Invented Here' syndrome still exists, and at the end of the day, the language feels like it has been evolved rather than designed. Elliotte Rusty Harold seems to agree with this point, and in particular complains about the duplication of =, == and === in a language, prefering the verbosity of .equals() for equality checking. I can't say that I agree with that particular point -- a language should have equality for all in a way that doesn't have to be implemented manually, and it should not be important whether it's a primitive or reference type.

To be honest though, the fact that Strachan doesn't know what a Closure is is one of the most depressing things about the language. A closure is a closed mathematical term, so in EL, "Hello ${name}" is not a closed term, whereas evaluating it with 'name=Alex' and resulting in "Hello Alex" is a closed term. A closure is often used to describe an application of a function to its arguments, and thus their term for closures is actually not only wrong but absolutely incorrect, since their functional blocks explicitly have free variables that are expected to be bound. But I wouldn't bet on them changing their terminology, because they are right and everyone else is wrong, OK?

But personally, I think the Groovy language is a step in the right direction -- getting rid of Java's quirks and supporting decent types is something I've been experimenting with for a while; though it has to be said, Groovy's beaten me to it for most things. Some things that it hasn't done:

1. Ditched the crap C stuff that's been dragging Java down. I'm talking about octals, weird blocks like 'switch', put in decent language-level support for doing guards and other multi-threaded/channeled code, and have a select-like block that works on expressions, not characters.
2. Use named expressions instead of positional parameters. You open up a lot more compatibility than having positional ones, along with a lot better documentation. Plus, you can then ditch the whole 'setName/setAddress' methods into a single 'set' with the whole set of data -- and get rid of overloaded methods/constructors with stupid default-value hacks.
3. Build in streamable types. I mean have data that can be streamed, not processed in chunks as systems treat things today. For example, present a file as a sequence of lines, not as a whole block of text, or dynamically generated sets of data. Building in more streamable stuff will help with multi-threaded code, and would allow XML processors to properly stream data rather than relying on a crappy PipedInputStream (which, by the way, has a maximum queue size of 1k)
4. Created zoned support for data, that can map to a page (or set of pages). Most objects have high locality of reference, and in most cases, creating zoned support for that data can constrain objects to live in one page instead of being spread evenly over memory. Think about zoning like the nursery in the HotSpot compiler; but partition the nursery and main memory into two; then you have two zones. Partition it into three, and you have three zones. The problem is, this is a VM-level issue and not a language one per se.

What it does show is that the time of the VM backed OO language is here to stay; whether it's Java, .Net or technologies that build upon them. Java has stagnated under the inept control of Sun for some time, and it's Microsoft's push for .Net that has seen the first innovation in Java since 1.2 in the new stuff that's coming out in 1.5. However, much of what's there is actually just tacked on as opposed to being designed -- the generics stuff doesn't check or validate anything at runtime, just compile time; whereas .Net's generics check this at runtime.

I think that the next language -- whether it's Groovy or XL, is going to have these features in droves, and the weak compile time checking but strong runtime typing are going to be key features of the next generation of programming languages.

But then, Python already has this stuff now, doesn't it?