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

On 24 Jan 2005, at 22:55, Mike Spille wrote:
> At 11:05 AM 1/24/2005, you wrote:
>> 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.
>
> Oh please James.  This is plain bullshit.

Huh?

Given I've spent a lot of time hacking Groovy code, from the grammar to 
the AST to the runtime to the bytecode generation, to the test suite, 
you'd think I maybe had some idea of the relative amounts of work that 
has gone into each part - and I stand by what I just said. The hard 
part isn't the parser, its the rest thats the hard work. That does not 
imply that I'm saying the parser is easy - just that there's heaps of 
work to do elsewhere. I've probably spent > 60% of my time on Groovy 
just on the bytecode generation part alone.

>  Face reality - if this was so easy _you would have a grammar by now_. 
>  You told the world in the beginning of December we'd have a grammar 
> "in a couple of days".
> You were wrong then and you're wrong now.  Groovy beta-9 is unusable 
> in its current state.  The grammar being put in based on decisions 
> made by you and John Rose will make it even worse.
>
> Your own developers realize this, James, and it's amazing that a man 
> as talented as yourself can't see it.  They've spent months trying to 
> get your vision to work, and it's not happening.  Yet you keep telling 
> them how easy it is.  They offer suggestions and say "no, too verbose" 
> - if they're lucky.  Most of the time you just ignore such messages.

Like what?

You're keyword suggestion has come up before - about a year ago IIRC 
from Sam - and certainly if a keyword were used, 'def' rather than 
closure/delegate would be my preference - but I'd much prefer the 
Ruby/Smalltalk syntax { |params|  code } unless someone proves that its 
really not possible - since a closure is passed into methods most of 
the time and it looks & reads much better than using a keyword.

The semicolon issue is not much of a big deal really; quite a few 
languages can manage just fine without extra punctuation on every 
single line and it doesn't break the grammar particularly.

Return is mandatory in New Groovy; one rule (which we could discuss and 
maybe miss out) is currently to keep GPath expressions nice and short, 
we're allowing return to be omitted if a block contains a single 
expression inside a closure. Maybe for simplicity we should enforce 
return everywhere.

Other than that, the only optionality left which could cause problems 
is the rule that parens are optional for top level method calls. As 
I've said to anyone who's asked, if it really messes up the grammar, 
I'm prepared to ditch this one, or at least push back on it until 
things are working - though if we can I'd really like to keep the neat 
Ruby style method calls, with last param of closure...

foo.each { something(it) }

or

foo.each { |x| something(it) }

>>> 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.

Seriously Mike, you seem to not want any syntax sugar at all thats 
offered by scripting languages - so why isn't C# 2.0 exactly what you 
want?

>>
>> So rather than
>>
>> coll.each { println it }
>>
>> its
>>
>> coll.each( delegate(Object it) { System.out.println(it); })
>>
>> I know which I prefer - and I think you prefer the other one :).
>
> James, I've heard what you prefer.  The problem is that you've never 
> demonstrated that it can actually work.
>
> We know for a fact it doesn't work in Classic Groovy.  Given that no 
> one has delivered an ANTLR grammar I think it's clear that it doesn't 
> work in New Groovy either.

The fact that we haven't finished yet implies that we must drop 
everything and revert to Java/C# 2.0? That doesn't make sense.

>> 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 ()).
>
> I call bullshit.  This is not "cruft" - it's necessary to have a 
> parsable language.

No its not. Try looking at a language other than Java and you'll see it 
is possible. e.g. JavaScript, which is quite Java like but has some 
syntax sugar, ditto Ruby. Remember Groovy != Java

> The typing is not unnecessary.  It's required to make the language 
> unambiguous.
>
> I repeat - you have not yet shown how your ideas can be implemented.  
> Groovy still does not have a new parser.  Stop repeating your vision 
> and start paying attention to reality.
>
> And stop with the "verbose" schtick.  Java is verbose, we all admit it.

If you're happy with verbose & don't want syntax sugar of any kind - 
why not stick to Java then?

>   The Groovy I propose is an order of magnitude less verbose.  The 
> unimplementable ideas you have save on average 3 characters and are 
> unparsable and ambiguous.  This is not Ruby.
>
> I'll take the 3 extra characters and have a solid Groovy language in 
> my lifetime.

Its not '3 characters'.

coll.each { println it }

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

Thats 25 versus 59 - an extra 29 characters - more than 100% larger!

>>> 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.
>
> How many months will this go on?  Excuse me - how many _years_?

We only started the new parser last December after having the JSR 
meeting in November. Sure its a long time for full time employees on a 
day job, but for open source, its not that long.

>>> 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.
>
> James, you need a reality check.  I've talked to many Groovy 
> developers, some on the JSR committee, both current and those that 
> have left.
>
> Every single one of them said that they're frustrated with you.  Some 
> used much stronger language.  Every single one indicated that you were 
> obstructing Groovy progress.

If anyone has come forward to volunteer to do some work on the project, 
I've always gone out of my way to help them. I don't see how I'm 
obstructing anyone do anything on the project.

> Every single one stated that when an issue came up that you didn't 
> approve of, you would silence the individual bringing it up by 
> ignoring them.

FWIW I never ignore folks, I'm just so busy & get so much mail that I 
can't answer everything.

> Your "discussions" have been mostly you ignoring what you don't like, 
> and then issuing mandates to volunteers who disagree with you but are 
> too polite to come out and say it.
>
> Every single one admitted to despair and feel that Groovy is in 
> jeopardy.
>
> Every single one hate the fact that you and John Rose make arbitrary 
> decisions on your own and lock out everyone else.
>
> Every single one has said they don't really understand what's in New 
> Groovy.  It's a big amorphous mass that's impenetrable, and apparently 
> locked permanently in your brain and John Rose's, never to emerge into 
> sunlight.

This is why we've been pushing to get a EBNF so folks can see what the 
syntax is and then we can have frank & open discussions on it. Other 
than the language guide I wrote on the wiki, its hard to take the time 
to write down a full language spec & semantics

> They beg you or John Rose to write it down _and you ignore them_.

Its not ignoring - its called being busy.

> The changes for New Groovy only make it worse - more special rules.

Clearly there are some rules, however so far I'm happy with them & we 
may simplify further (see above). Nothing is yet cast in stone & I hear 
your comments and have taken them on board - if we can't nail the 
grammar soon you could well be right.

> People try out Groovy bright eyed and excited by its possibilities, 
> then they write some code and leave confused and slightly angry.  5 
> line code snippets fail in obscure ways.  The reason?  All those 
> stupid special rules and optionals that eat up so much development 
> time.  How many cumulative man hours have been spent "tweaking" the 
> parser to try to "fix" these things?

When I was hacker of the original parser, I can tell you - very very 
little. I'm sure you're not gonna believe me and write another rant 
against me - but honestly its true. All the time was spent on the 
bytecode generation & AST & runtime & test cases. I think you're 
focussing on the stuff you don't like in the language (; parens and 
closure syntax) and thinking those must be the reasons that Groovy is 
not finished & that the parsers's not completely implemented & wired 
into the bytecode generation and so forth.  While I can understand you 
not liking some of the things in the language (someones always gonna 
dislike something), this really isn't the reason Groovy's not finished 
yet - it just takes time.

James
-------
http://radio.weblogs.com/0112098/