Joe specifically complained about a lack of prototypes in various places. Here's a verbatim quote from a comment he left on his own blog ( http://blogs.sun.com/darcy/entry/project_coin_final_five ):
> Project Coin explicitly encouraged prototypes as a way to demonstrate the > feasibility and utility of a change via an existence proof. > Yet, despite all this, most of the proposals sent to Project Coin did not > have a corresponding prototype, including improved exception handling. > Rather than complaining after the fact, a more constructive way to influence > future language decision is helping to hack prototypes ahead of time. The post that kicked off this thread was also by Joe Darcy and includes such gems as: > KSL received no significant community response. > Before Project Coin, Kijaro saw a modest > number of features developed, fewer than ten, which is also not a > particular vigorous community response given the millions of Java > developers in the world. The tone of disappointment is rather obvious to me. Replying to your own remarks now: On Sep 16, 7:40 pm, Bob Lee <[email protected]> wrote: > In this particular case, I think you just need to give people some more > time. We all have a lot on our plates and there are only 24 hours in a day. That's fine, though I suggest it's all sorted out well before the next coin. The faster the better - if coin proved one thing, it's that it was far too short a timeframe. I'm trying to convey to Joe that this lack of response is partly to blame for the 'view from an ivory tower' perception. > Coin got close to or over 100 proposals. Those proposals also enjoyed some > great feedback, from you in particular. What more could you hope for? Prototypes, obviously. And more proposals; let's get real for a moment - many of the proposals of coin were dead on arrival, written up with barely enough detail to make for a valid feature request on bugs.sun.com. I myself submitted (and some as only a pre-proposal) less than half of what I planned, because writing up the first one properly made me realize there's no way I could get it done in the mere month that was given to us. Consider projectlombok.org my less rushed response: Real prototypes, usable on real source code bases, with real development environments, so I can really get a feel for this stuff. > > I don't think they ever asked for JLS specs. Joe repeatedly asked for references to the appropriate JLS chapters during the coin process - even on (especially on) proposals where that was the last thing on my mind to determine whether or not the proposal was a good fit for java. > I believe Alex is one of the > few people who can actually do this. This is a bottleneck in the process, > but I don't really see any way around it. This is true, someone has to do this stuff, and its only fair the community owns up to its responsibility. But as this is the bottleneck, lets shove the job as far forward as we can: A few decision iterations worth of culling the proposal list down should pass before anyone names any JLS chapter, unless its particularly relevant to the specifics of a proposal. > > It would be nice if we could have detailed explanations for why each of the > 90 or so proposals was turned down, but the reality is that time spent on > this is time they can't spend actually implementing and integrating language > features. I prefer they spend time on the latter. > Absolutely. Defending 90 denials is next to impossible. Yet another reason for iterating early and often: If a proposal looks like crap, then say so. Right away. You can have some sort of officious level of denial which entails: I really doubt it, but if you go through the effort of a prototype and a full spec, we may always reconsider, but, don't get your hopes up. In the unlikely event a proposal you cancel early did have merit, odds are it has gathered enough cheerleaders that they may try this, but at least then the people who did put in the effort aren't disappointed when they are part of that 90. A big issue with that list of 90 is that the majority of them were ridiculous proposals, but a select few of them showed rather a lot of merit. There were a few proposals that didn't make it that nevertheless received some positive feedback and went through a bunch of iterations (case in point: Neal's exception handling proposal!), that were nevertheless not shortlisted. An explanation for this (which does not directly contradict a properly defended claim in the original proposal and is more than 6 words long) would be a great boon for the community, the coin process in general, and really should not be too much effort. The only problem is that coin let it come to 90 proposals in the first place. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
