jastrachan | 7 Dec 01:47 2004

Re: Bug postings...

On 6 Dec 2004, at 23:50, Mike Spille wrote:
> Since everyone else is, I'll throw in my two cents as well :-)  For 
> starters, I agree 100% with Cedric's statements.  I'm working now at a 
> big-ass financial services company which has looked very closely at 
> Groovy and is deeply impressed with the potential of the language.
> But it's seen today as effectively an alpha effort (with many leaning 
> towards a pre-alpha moniker) and not nearly suitable for production 
> use.  The reasons why have been well enumerated on this list - too 
> many ambuiguities, too many surprises, and of course the stack trace 
> errors.

FWIW most of the ambiguities have been resolved; though we've not yet 
had a chance to work through everything on the user list. Its our hope 
to brain dump things into the JSR test cases, then put those on the web 
in easy to read HTML so folks can see. Also an EBNF

> And the lack of progress in fixing these issues,

Agreed. Hopefully we can get more folks to step up to the plate to help 
fix the rougher edges... The new parser will help enormously catching 
user errors...

> and lack of transparency into the JSR.

This I find a bit of a shock; apart from 1 face to face conference; 
which is available in wiki & MP3 format mostly (we really tried hard to 
disseminate information) everything is either on a public wiki, email 
list, IRC or CVS repo. But sure there's been some face to face & 
off-list chat.

> I'm sure a number of readers here will categorize these statements as 
> grossly unfair - and they are.  But that's how corporate IT works.  
> They evaluate what a tool does, and not so much who it comes from.


> Where I work, Groovy is seen as exciting because it has a number of 
> excellent script-like features, it can let us leverage a huge Java 
> code base, and it potentially has a low barrier of entry to Java 
> coders.  But we will not use it in its current state, and I personally 
> am worried that the current state may be about all we're going to see. 
>  Mystery references to issues resolved in London and tricks a Sun guy 
> bestowed on the project aren't very comforting.

Well, until things are all fixed, what else can we say?  As I said a 
few days ago on this list in response to Brian's email, we've a 
schedule and by the end of Jan I hope we've got 95% of the core grammar 
that folks use day in day out all clearly documented in test cases so 
that folks will know what 1.0 of the JSR is gonna look like. Not that 
much is gonna change from what we were writing a year ago; but some 
things will bite people & the earlier we can warn them the better.

> Split this thing up - grammar, runtime, libraries, extras.  Show the 
> grammar that can be implemented by a simple parser.

Thats exactly what we're doing. John Rose and Jeremy Rayner are both 
working on this right now.

> Show a runtime that can be bootstrapped easily and yet has the 
> potential for optimization down the road.  Libraries and extras - 
> these will follow naturally if the first two basics are there.

Agreed - we're doing this. It just takes time and we're all a bit busy 

> Finally - fears about breaking existing code are, I believe, a red 
> herring.  Let's be optimistic and say a thousand developers have any 
> significant amount of Groovy code out there.  The list here is 
> terrified of breaking the code of those (optimistically) thousand 
> people - and are willing to thereby saddle tens of thousands (or 
> hundreds of thousands! :-) of potential developers with less than the 
> best.  Realistically, Groovy is still Alpha, and existing coders are 
> not on the bleeding edge, but already thoroughly bloody.  Don't worry 
> about the existing Groovy code base, worry about the potential future 
> code base.  Decisions made now can either make their transition easy 
> and Groovy a joy to work with, or turn them off so badly that Groovy 
> dies on the vine.
> The last point needs to be faced up to.  I won't say that I've talked 
> to every developer in existence, or even a small fraction thereof :-)  
> But I've talked to a fair number of them, and all of them who are not 
> Groovy insiders see Groovy as teetering on the brink of exitinction.

Its maybe hard to see from the outside, but Groovy got a massive 
re-injection of life at the conference; in our heads for those that 
attended, the language has been pretty much fixed; its just a case of 
getting the parser & runtime to implement it :). But I hear you & 
hopefully in the next 2 months things should start to motor along 

> Sorry if I'm coming off as superior and arrogant, as I usually do.  
> I'm not trying to put Groovy down here, far from it - but I'm trying 
> to inject a viewpoint of the larger viewpoint, and a number of people 
> who would dearly love to see a solid Groovy standard and 
> implementation - but are afraid it will die from waffling before ever 
> getting there.  Focus on the absolute basics, make it solid at 
> Gibraltar, keep it simple, and everything else will follow.

I totally agree and thanks for your mail. Its basically what we've been 
trying to do from the conference onwards; fixing the core stuff and not 
worrying too much about the periphery.  We should hopefully have a 
solid parser with EBNF etc quite soon. The big ball of mud that is the 
bytecode generation (ClassGenerator) might take a little while longer 
to tackle - but thats just one class; most of the runtime (AST, 
MetaClass et al) is normal Java & shouldn't be too hard to patch or fix 
of any bugs.

> P.S. I may be able to squeeze some time to help out, perhaps even with 
> my boss' blessing.

Fantastic! Lets try out the new parser spike with EBNF notation a 
little first and if its looking good (& giving users meaningful 
messages & catching most typeos) then we can try wire it in. In the 
mean time there's heaps of issues in JIRA that could use a hand; 
particularly runtime issues like method invocation issues (which will 
remain the same code even if we switch the parser & bytecode