jastrachan | 24 Jan 17:05 2005

Re: [groovy-dev] Pragmatic Groovy Development and Project Management

On 24 Jan 2005, at 14:20, Mike Spille wrote:
> Great response.
> My main point is about what's achievable given the people available, 
> and the time they can put in.  And being willing to compromise in 
> order to deliver something.
> In many ways Groovy Classic was an experiment - lots of changes from 
> Java.  Some of them were good and really indisputable.  Other ones 
> cause significant problems and eat up huge amounts of development time 
> - but the net benefit to users is small.
> Closure disambiguation (is that a word?), optional semis, optional 
> parens - these are huge resource drains which aren't giving anything 
> to the users, and they're severe departures from Java.  Add a closure 
> keyword, make semis and parens mandatory, and suddenly there's almost 
> no work to do :-)

Not really; the hard work is getting the parser, AST, bytecode 
generation and runtime to all work fine while giving useful error 
messages & having a consistent naming convention. We don't spend much 
time at all on disambiguating.

> Serious question: how much time has John Rose spent on desperately 
> trying to get optional stuff to work?  How much time has he spent on 
> trying to save the closure syntax?
> How much time have others spent?
> Now - use a closure keyword, get rid of the optionals.  Now how much 
> work is there in getting a Groovy grammar together based of a Java 
> grammar?

What you are describing is pretty much what C# 2.0 is. Seriously - 
maybe you'd be happy just hacking C#? It sounds exactly what you need.

So rather than

coll.each { println it }


coll.each( delegate(Object it) { System.out.println(it); })

I know which I prefer - and I think you prefer the other one :).

I hear you, you've always wanted mandatory everything & verbose code to 
avoid confusion from users. However what I'd like us to do is fix the 
parser so it catches common user errors & lets them know exactly whats 
wrong - rather than forcing them to type lots of cruft. Groovy started 
because Java is just way too verbose most of the time so the aim is to 
make something like Ruby/Python which is concise but understandable. 
That means letting the parser do more for us rather than being dumb & 
expecting us to do lots of unnecessary typing (like ; and ()).

  e.g. I've never heard anyone in the Ruby world say they want mandatory 
semicolons to let them spread statements across whitespace in arbitrary 
ways - or demanding why parens cannot be mandatory when passing 
closures into a method.

> On semantics - there must be huge changes in semantics, because we 
> know Groovy Classic semantics are broken.  A tiny example is the 
> exception issue you've been addressing.  Also scoping rules.  There 
> are many others.  The only reason they are not discussed is because 
> Groovy Classic semantics are so poorly documented that there's little 
> to discuss.
> Yes, Groovy has always been not quite Java, but there are "easy" 
> deltas and then there are hard ones.  Omitting features is not very 
> difficult and does not eat time - omitting Java features isn't all 
> that hard :-)  Changing fundamental Java semantics and syntax _is_ 
> hard - making newlines significant (sometimes), parens optional 
> (sometimes) - these are _hard_.
> And it's all about what the available people can achieve.  Parallel 
> tracks are, frankly, insane.  There's not enough people for parallel 
> tracks.  Period.  You can wish it wasn't true, but that doesn't change 
> facts.

The aim of the 'parallel track' is to finally have a concrete, 
non-ambiguous parser which is self documenting. Then its a base on 
which folks can discuss stuff. Its just a parallel spike of the parser 
- nothing more. As soon as its working, we'll just have 1 track again.

> Since the November meeting the only "progress" New Groovy has seen is 
> an antlr grammar file that's broken.

Not really - there have been many discussions as well - but yes little 
of that is clearly documented in one place that we can point at to 
prove progress.