What is the meaning of this?

[Osvaldo Pinali Doederlein]

Sorry if the hyperbole did sound provocative or anything. In the future 
I will use... only cult, even biblical hyperbole, like "gnashing of 
teeth". Or I will wait until I have the status for that (I vividly 
remember my professor Theo D'Hondt in 1999 saying that "inner classes 
are 'ooorrible'" [fake, subtle Dutch accent for extra effect]). ;-)

Ok, maybe I was just a little angry but that's natural after digesting a 
couple hundred emails and proposals around certain issues, like blocking 
transparent closure calls due to Java's field/method visibility scoping 
and the (purism of?) not wanting extra scoping cases or method 
resolution rules, or this new issue of 'this'. My gut feeling is that 
the problems caused by such designs would be vanishingly rare in the 
real world, and the benefit of transparent calls would be a very 
positive tradeoff. My point is that "common developers" are NOT idiots 
(oops!). But we believe/fear too much that they are, so we are going to 
select some syntax, like x.(y), that half the planet will hate like you 
aptly put.

Programmers are flocking in droves to alternative languages, some of 
them less well designed than Java and full of pitfalls; or much more 
complex, like the monstrosity of C++ that's still used by millions. We 
don't have to do SO much baby-sitting. If a powerful, clean lambda 
proposal will have a few corner cases that allow Josh&Neal write an 
entire "Java Puzzlers - Special Lambda Edition" volume, so be it </sarcasm>.

A+
Osvaldo

Em 02/02/2010 20:39, Alex Buckley escreveu:
> -1 for unnecessary hyperbole. ("doomed", "most cumbersome", "idiots")
>
> Lambdas introduce plenty of new concepts: function types, lambda
> conversion, "effectively final" variables, shared variables (possibly),
> method references (possibly), extension methods (probably). To say
> nothing of API changes to actually consume and produce lambdas.
>
> I am pleased that this list has exposed different opinions and (more
> importantly) their underlying beliefs. Doubtless the draft spec will
> take a position that reflects some beliefs and not others, leading to
> much wailing and gnashing of teeth. That is inevitable. But I will say
> this: with nine million Java developers, designing something that looks
> familiar is a feature, not a bug.
>
> Alex
>
> Osvaldo Doederlein wrote:
>    
>> I agree too (with Mikael/Rémi/Neal). And I add that, it worries me this
>> (apparent) thinking of "we cannot add new concepts to the language" - if
>> this is not Josh's position, it boils down to that in practice: i.e., in
>> Java there are only methods-inside-objects (or classes for statics), even
>> inner classes are very explicitly methods-inside-objects, so any new
>> construct to contain code must be a method-inside-object... we can't have a
>> fundamentally new construct, like a function/closure/lambda. We can only
>> have something that _looks like_ a function/closure/lambda but is firmly
>> rooted (both syntactically and semantically) in the method-of-object
>> concept, down to backwards-compatible behavior of 'this', identity / memory
>> allocation, etc.
>>
>> With such restrictions, Java is doomed to evolve only in the most cumbersome
>> way possible, every new feature always paying enormous tradeoffs not only to
>> backwards compatibility (which is already often a big hit - and I agree that
>> cannot be avoided), but also to the backwards thinking - let's not invent
>> any really new concepts because most developers are idiots who can't learn
>> that a function is something different and will certainly write all sorts of
>> evil code that will fail or not be portable...
>>
>> I say, let's design functions as well as we can (ok as well ss you can - I
>>
>>
>> 2010/2/2 Mikael Grev<grev at miginfocom.com>
>>
>>      
>>> I must, slightly reluctantly due to historic reasons, agree as well. No
>>> matter how things are turned lambdas is something new and the object
>>> implementation should not shine through if not needed or shown advantageous.
>>>
>>> Also, I have always thought declaring a variable as 'volatile' would've
>>> been a better solution than forcing it to be final since so many go around
>>> that anyway. I know I do sometimes, and I just feel dirty when I do, for no
>>> good reason since I know what I'm doing (most of the times anyway. Can't
>>> think of a bug introduced that way).
>>>
>>> Cheers,
>>> Mikael
>>>
>>> On Feb 2, 2010, at 19:48 PM, Rémi Forax wrote:
>>>
>>>        
>>>> Le 02/02/2010 19:40, Neal Gafter a écrit :
>>>>          
>>>>> I think Zdenek had it exactly right.
>>>>>
>>>>> A lambda expression is not an object creation expression.  The function
>>>>>            
>>> is
>>>        
>>>>> not declared within the scope of some object type.  A lambda is written
>>>>>            
>>> as
>>>        
>>>>> an independent block of code, and should be scoped accordingly.  Trying
>>>>>            
>>> to
>>>        
>>>>> make a lambda act the same as an anonymous class creation expression
>>>>>            
>>> smacks
>>>        
>>>>> of cargo-cult language design.
>>>>>
>>>>>            
>>>> I agree. Lambda is an anonymous function.
>>>>
>>>>          
>>>>> Cheers,
>>>>> Neal
>>>>>
>>>>>            
>>>> regards,
>>>> Rémi
>>>>          
>>>        
>>      
>