Fwd: Comments on the straw man...

[Mikael Grev]

I second this, however, not primarily from a technical point of view.

Many parts in proposals such as Cfj and straw-man are easy to debate. What it harder though is finding consensus for the simple reason that there's no single answer that it right. It all boils down to opinions and preferences. Some of us can handle the full power of BGGA and some will never be safe beyond CICE. There is no way to know what is "right" for Java, and even after this is released we can never tell because we don't have the results for the other proposals. The grass will always be greener on the other side.

So, as long as a proposal is technically well though out and that the complexity is deemed "right", what will impact success more than anything is risk. Managing risk is key, we all know that, at least if you have been a project manager of some sort. Even though we are all techie geeks that want to dig in deep in details, project risk needs to be the deciding factor for volatile projects such as this.

The risk of creating yet another proposal at this stage is very high. Discussions may turn bad, key people might quit turn their back on it, or something else unexpected might happen.

Because of this alone, I would like to put my vote on Cfj. The risk is much lower. All key players except Sun seem to be able to accept it. The spec is solid and the complexity is in the middle of the field, probably hitting just about right on the bell curve for all but the most junior developers.

Only pride on Sun's part (NIH) can make this into something that will either not make Java 7 or push it even further into the future.

Java 7 needs this and it need to be out asap. Time is of the essence, much more so than subjective syntax preferences.

Cheers,
Mikael


Mikael Grev
Systems Architect

MiG InfoCom AB
S:t Olofsg 28a, 3tr
753 32 Uppsala
Sweden

On Dec 12, 2009, at 23:43 PM, Stefan Schulz wrote:

> Just some additional cents ...
> 
> I'm not quite sure, what to make of the strawman proposal. To me, it 
> rather looks like a quickly sketched technical wishlist for lambda 
> expressions, especially due to the tutorial style (but I think, that's 
> somehow what Mark mentions in the first paragraphs).
> 
> As Neal pointed out, there is lots of work to be done before it could be 
> taken as a serious proposal, and I don't think the strawman being 
> appropriate in its current state to do this by a rather large group of 
> people as are on this mailing list, but a reduced number of language and 
> closure/lambda experts (not implying that I would be qualified as such 
> an expert). The slightly heated discussion on one of the very most 
> optional parts "extension methods" IMHO shows the problem in not having 
> a mature base for common refinement.
> 
> I ask myself, if it would be wiser to pick up the latest version of CfJ 
> and adopt it to the ideas as written down by Mark. For the start, I 
> would even put the enhanced syntax for method-like invocation of 
> function types into the optional section. It seems, too many thoughts 
> are going into the beauty of syntax before having the base done right.
> 
> Stefan