2009/9/17 Reinier Zwitserloot <[email protected]> > > 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. >
This is probably pouring oil on the fire, but it looks like hacking a prototype even lets you circumvent the JCP ;) http://altair.cs.oswego.edu/pipermail/jsr294-modularity-observer/2009-September/000334.html [ Disclaimer: I work with OSGi every day, and support the recent Simple Module System as a good compromise ] Now where are my asbestos underpants... -- Cheers, Stuart 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 -~----------~----~----~----~------~----~------~--~---
