function types syntax

[Mikael Grev]

That's a purist's view IMO.

I would instead say that user satisfaction (user here being the developer, from good to bad) is the one and only thing that matters. Not just with closures, but for anything about how Java is developed. The sooner we can get people in charge that understand this at heart, the better. Correctness and code quality in the compiler is only good for maintaining user satisfaction over time and the resources it takes to do so. Think Apple.

Take generics for instance, as you did. It is very pure solution in that you can always "prove" that with the correct generic type you have the correct type of object. This is unlike arrays which are more pragmatic and not as pure. But how often do you get ArrayStoreExceptions? All those who think generics are too complicated, and that's the bulk of developers by now, would've been much happier if generics worked like arrays. Less pure, but much easier to handle. Reified generics is not a solution to this btw, but you guys know that.

So, to maximize user satisfaction generics should've been made less pure and more pragmatic. Then we would have less flack from developers demanding reified generics, even though they don't know it won't solve the complexity problem which they want solved.

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).

At least this is how I see it. And I mean no disrespect to purists.

Cheers,
Mikael Grev


On 6 jan 2010, at 18.14, Lawrence Kesteloot wrote:

> On Wed, Jan 6, 2010 at 3:41 AM, Zdenek Tronicek <tronicek at fit.cvut.cz> wrote:
>> So far I thought that we all have the same priorities for closures syntax:
>> 
>> - readability (they are easy to understand),
>> - intuitiveness (one does not have to learn them for weeks),
>> - completness (the syntax proposed should involve all the use-cases).
>> [- compatibility]
>> 
>> Anything else is far less important.
> 
> You forgot "correctness", which is actually at the top. I do not want
> readable syntax at the expense of  a broken compiler. Having to
> implement complex features like closures and generics in half a dozen
> compilers and pseudo-compilers will decrease the chance of correctness
> and portability. (If you get a chance, read through the javac sources
> to see just how much incomprehensible code is littered throughout to
> get generics to work. It's frightening. When I added list
> comprehensions, the bulk of my frustrations were with getting the
> feature to work with generics, despite the fact that I was working at
> a level where they were supposed to have already been erased.)
> 
> To put this another way, imagine the GWT project being started after
> 1.7 is out, rather than when 1.4 was out. Would they have:
> 
> 1. Aimed for 1.4 compatibility, guaranteeing that none of their active
> code could be compiled (because of 1.5 features, generics, and
> closures).
> 2. Aimed for 1.7 compatibility, making their task even more daunting.
> 3. Scrapped the whole project.
> 
> I suspect 3, though of course we'll never know.
> 
> I'm not arguing to scrap closures. I'm arguing against the repeated
> arguments on this list that Java == JDK and as long as we have a
> single working implementation, then we're done.
> 
> Lawrence