General community and Process Questions (blog comment followups)

[Adam Malter]

Joe writes:
>
> Most Java programmers do not need to be language experts.  This is very much a feature and *not* a bug of the Java ecosystem.  Not having to be a language expert means Java programmers have time to be experts about other things :-)
>
> One of Project Coin's goals is to build up a larger body of expertise outside of Sun that can analyze, quantify, measure, and evaluate developments in the Java language..  A good way to get influence is to do some work.  I've been a bit disappointed in several aspects of the coin contributions.  For example, back in May there was an open issue concerning the grammar changes needed for underscores in numbers [5].  No one sent in a message on this matter until I sent in a grammar in July [6].   Neither the coin list nor readers on my blog caught the embarrassing but small mistake I made in the grammar [7].  In terms of difficulty of language evolution, this grammar change is easy.  Having taken an undergraduate class in compilers or automata theory is sufficient background to work on this, but no one else contributed a grammar for this despite presumed interest in the feature and the large number of coin subscribers.
>

> Collectively the Coin community to date has neither managed to get all the small details of proposals worked out nor provided an alternative larger view of the potential goals for the effort.  Sun has been working on the Java language for many years, is in a position to get input and feedback from numerous parties (including Coin!), understands the need for thorough analysis and mature evaluation, and has provided ongoing support.  Therefore ultimate decision making on Java language changes will stay with Sun.

First of all, Joe, thank you for the thorough and thoughtful reply. I
can fully understand your frustration with people who bring
complaints, but not contributions. This is an unfortunate 'bug' of the
village commons, and if we were to fix it, I believe we'd all be
having dinner in Stockholm very soon. :)

To get more concrete here, part of out problem is that anyone outside
of Sun or otherwise unfamiliar with the semi-formal proposal process,
needs to 'go through the meat grinder' before their work will resemble
the quality of one created by insiders. This is just an inevitable by
product of externalizing an internal process. I would just ask that
this be taken into account when judging the 'quality' of a proposal.

Additionally, we all have our biases and individual ideas on how to
best mutate the language for further growth. I will rapidly assent
that most users of the language (especially users that work in a
single problem domain) don't have the long term vision that language
designers require.

All of these things are very true, but we seem to be stuck in a more
pragmatic ditch. To bring us down to earth a bit, project coin seems
to be the best last hope for introducing useful language constructs
into Java (well, for this decade at least).

It seems to me that Joe has been charged with a monumentally difficult
task, which is to fix the impedance mismatch between the subjective
proposals and what would truly fulfill the mission of finding the
loose change language constructs that would most benefit the current
ecosystem and further the language growth. As in your analogy Joe, as
'coach', you cannot be influenced by your own nits and prejudges, but
must do whats best for the 'team'.

My personal opinion on this would be the introduction of the
tripe-quote or @" (aka C#) enhanced string literal definition. I'm
honestly unsure if this would be the 'best bang for the buck' feature
change, because I work in only a few problem domains and because I
have never been a language designer. It is also no fault but my own
that it was not until recently that I understood the process that
would lead to this language change.

>   The hard part, and the most valuable part, is the work analyzing the impact and benefit of a change, which ideally includes a prototype.  Project Coin invited community participation in that work.

So I guess my question becomes (to both Joe and Ruslan), is there
anything that we can do at this late stage to influence the process?
If we could put effort into producing a prototype parser now, would
there still be enough time to consider it? (I've done an ANTLR SQL
grammar, so, hopefully some of that transfers over)

I don't want it to be too little, too late, and fully accept your
counsel on showing up empty handed.

(Too late I understand, but I'm willing to work with Ruslan, whoever,
to come back with something working and worthwhile and to maybe
overcome some your disappointment and actually have some true
community contribution)

It's also only now that I understand the greater mission of coin,
which was to not only introduce small grammer changes, but also help
'teach' the community to stand on their own. Consider this part of the
learning process.

- adam malter @ tradecard . com