function types syntax

[Mikael Grev]

If your aim to absolutely improve the solution to almost pure, yes. I see your point.

But what I mean is that the 95%-type solution, with a simple and likable rule set/syntax, is fine and preferable to the 99,7%-type solution with a more awkward syntax/rule set. Even as the end result. The last percentage points are bonus and can be handled on a feedback basis, if possible.

If one can chose between 95% solutions that individually have different probability to get to 99%, one should do the home work and chose the 95% solution with the best forecast, given usability is the same. To this I agree, we should not be lazy. What I mean is that many discussions and opinions are about already now going for 99,7% with a worse syntax rather than a better one that might max out at 97-98% and have a better 95% syntax.

I essence, I would like to concentrate more on the properties of the different 95% solutions and how to make them the best possible, usability wise. Then if there are many such solutions, and only then, should we concentrate on finding the one that has the best head room for further improvement.

Too many 95% suggestions are shot down with arguments in the 98-99% range IMO. We are simply not there yet.

Sorry about all the percentage lingo, but I hope you understand what I mean. These are soft things compared to language theory and not as easily discussed in text.

Cheers,
Mikael


On 6 jan 2010, at 22.04, Neal Gafter wrote:

> On Wed, Jan 6, 2010 at 1:21 PM, Mikael Grev <grev at miginfocom.com> wrote:
>> The discussions on this list almost always spiral down the purity path, making sure that
>> every little 0.1% of use cases are handled for every possible situation. What we instead
>> should do is to create a syntax and rule set that works really smooth for 95% of the use
>> cases and simply make the compiler forbid the last 5% for now. Then we should have a
>> plan for Java 8 to polish the syntax to cram a few more percent out of the solution (and
>> it is important that this is communicated directly for the release of Java 7 closures).
> 
> The only way we can be sure we have a way of developing such a plan in
> a subsequent release (without breaking compatibility) is to work out
> the issues today.