jstrachan | 27 Jan 05:45 2005

Re: [groovy-dev] Diff of Java and Groovy grammars

Mike Spille wrote:

> At 10:41 AM 1/26/2005, you wrote:
>>> For example, if I'm doing some numerical processing and with to find 
>>> an x such that f(x) = 0, I don't want f() to be able to exit from my 
>>> zero finder.
>> Sure - like I said its your call. However you may want to be able to 
>> abort a lengthy iteration by the closure deciding when to stop.
>> e.g.
>> doSomethingSlow(Closure c) {
>>   for (i in 0..someLargeNumber) {
>>      c.call(i)
>>   }
>> }
>> doSomethingSlow { i | if (i > 1000) { return } else { println i }}
> This will be incredibly unintuitive to a Java programmer.  I don't think 
> I can even express in words just _how_ unintuitive.  Perhaps 
> "abomination" comes close.
> This is yet another reason to consider the language a bit more deeply in 
> the past - is it going full-hog into functional-style block land, or is 
> it going to stay relatively closer to the semantics today?  BTW, note 
> that no one would have problems with the notion of "return returns only 
> from the closure" if you do:
>>         doSomethingSlow (def { i | if (i > 1000) { return } else { 
>> println i }}})
> Once again it comes down to it - clarity and consistency, or save a few 
> keystrokes and move ever closure to Ruby or one of its cousins?

Mike, closures are not about 'saving a few keystrokes'. Its like saying 
to an OO guy, ah these objects, they just save a few keystrokes - stick 
to global functions instead.

Closures fundamentally make a programming language more expressive. They 
are IMHO the biggest thing that makes Groovy so expressive (e.g. witness 
  GroovySQL or the various helper methods for working with files & IO etc).

Quite frankly, to me closures are the biggest delta from Java which adds 
power and expressiveness when working with Java objects (which are the 
main aims of Groovy afterall). This really isn't about keystrokes.

Now closures do not exist in Java - so Java developers moving to Groovy 
have to learn about them. There is no direct equivalent in Java to draw 
on (though we do often describe them as being similar to things in Java 
like functions / anonymous classes / blocks). However that doesn't imply 
we have to cripple them for fear of the poor Java developer not 
understanding closures (since they don't exist in Java at all anyway).

i.e. I think we should implement closures properly like other languages 
have done in the past (Smalltalk & Ruby to name 2 off the top of my 
head) rather than use a crippled Java-style closure system for fear of 
confusing users - who have never used closures before anyway. i.e. its 
not like they're gonna try use Java-closures and find they're different 
in Groovy - they just don't exist in Java.

As an aside, someone coming from backgrounds in Smalltalk (you'd be 
surprised how many ex-Smalltalkers are in the Java community), Ruby or 
other languages with closure support - admittedly a much smaller user 
base I imagine -  would be instantly at home with Groovy closures; or be 
very confused if we crippled them as you suggest.