What is the meaning of this?

[Alex Buckley]

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