One(?) word for you - “multicore”. Java has always been pretty good at supporting concurrency, and this feels a natural evolutionary step in that. Have a look at the slides here - http://www.slideshare.net/buzdin/lambda - good overview of some of the thinking behind this (even if the implementation details are a bit old).
I’m sure we’ll all get used to it over a few years and then we’ll wonder how we managed without.
(see: annotations, generics, etc)
Having said that I’m convinced that the current “state of the art” when it comes to multicore computing design is basically just a massive bodge job. If I ruled the world we’d have software configurable core pipelines and immutable message passing and languages would be kinda designed around a more transputery sort of way of doing things.
Cas 
Transputers are awesome. The problem is someone needs to design a language to program them in.
I keep on hearing that again and again, but it seems to only boil down to ‘annon inner classes suck, but my cryptic hackery is totally cool’.
Trying to sell a feature that supposedly fixes something that is not broken?
You might say so, but there’s a paper long predating the lambda proposal out there from one of the big names in Java (might have been Gosling himself) going on about how Java doesn’t need any kind of lambda syntax because it has anonymous inner classes.
Thankfully less conservative voices like Bloch ultimately prevailed, and others like Gilad Bracha, and the aforementioned Gosling signed on to it. So folks, are they just kiddies with their bling trying to bodge silly hacks, who don’t know what they’re doing?
Leaving snark aside (don’t worry snark, I’ll come back, daddy loves you) one of the main reasons for ultimately adopting lambdas after all, and as has been discussed here previously, is that they’re not simply syntax sugar, but can be optimized specially by the compiler in ways that the JLS would otherwise specifically forbid for anonymous inner classes.
They did, it was called Occam. I suspect just about anything message-based would do fine though.
So, you didn’t read through all the slides or the point above about bytecode implementation then? 
Lambdas aren’t inner classes, and because they’re not specified or implemented that way, there is potential for significant performance improvement.
Broken, no. Slow, possibly! Turing completeness doesn’t specify speed. ;D
You might call them ‘less conservative’, others might call them opportunistic. You just like them now because you agree with them on this one part.
Though I doubt if Bloch et al would look at your code, you would really want to hear what they have to say.
or as someone once mentioned: Lambdas in several languages seem to be defensive moves more than anything else ("Stick around! We’ve got those too!!)
When I look around, most of the people calling for these are people coming from other languages asking why their cool feature is missing.
Got anything to back up that statement? Not just rumours or whatnot, I want to see facts.
Because I honestly only hear about what all these cool features will do, but nothing that would convince me. Show me just how great it really is and how much better everything will be if I do pick it up and you just might sell me on it.
Until then, it is simply today’s shiny new toy.
Not that really anything we say or do will change anything. I simply see Java going the way of so many other languages and joining the feature death-march that will only lead to it’s demise. Today it might be the one you like, tomorrow it might be something you do not want. Once the ‘omg, we need this also’ dam is broken, you will be hard set to stop it again.
That was once what made Java so great.
More bloody slides! - http://www.slideshare.net/jaxlondon2012/lambda-a-peek-under-the-hood-brian-goetz
I’m pretty sure that I remember what you’re talking about and want to think it was Gosling. But you gotta take into account the “public face” factor. Look at the spin on “type erasure” as an alternate example. (Which of course they’re working on a non-type erasure version). Looking at the pre-and-post Java works of various early Java folks:
Gilad Bracha: Smalltalk
James Gosling: LISP
Guy Steele: LISP/Scheme/Oh…many LISP variants/Fortress
Patrick Naughton: Surely looking for “closure” on that sex case (I couldn’t resist).
So you have a bunch of people (ignoring all the other smalltalk/strongtalk/self people) with experience designing/implementing languages with lambda expressions before working on Java…AND working on/designing/implementing during or post their work on Java…all of which include lambda expressions. It’s simply not plausible that lambdas were not considered early on…and rejected since it was an issue that could be (painfully) worked-around (and thus moving the task from the VM/compiler & design side…which had to have been critical path to library side with grunt programmers).
BUT: Be that as it may…my point is that it’s rather silly to think that java is just adding lambda’s to follow some fad. And likewise java didn’t add generic’s simply to follow C#'s lead.
Yes Occam…that’s sort-of proves my point doesn’t it? Seriously, the problem with transputers is that it too much of a paradigm shift. Programmers want coherent memory architectures and to be able to think in a logically sequential programming style. And code/data memory should be logically infinite and not manually managed. Sure you “could” use any off the shelf functional and/or message passing system, but it doesn’t really map well. Look at all the love programming the PS3 got, which is (basically) a transputer rip-off design. I’d love to be proved wrong…and I’ve always wanted to take a look at Cray’s chapel to see if it is promising or not…but I’m too lazy!
XML literals was a fad that I’m glad Java didn’t follow. Lambdas are as much a fad as functions themselves are. Heck, they’re more battle-tested than this newfangled “OOP” thing everyone keeps talking about.
XML LITERALS?
what’s the point of XML if it’s HARDCODED into your program?
For the point of rapid development and prototyping, Python is often better, especially since properly written code can document itself. (Python is basically pseudocode) However, for more complicated (game) graphics stuff, Java is better since it has simpler, more up-to-date libraries. (Clutter is a great library, but it is meant for visualization not gaming.) LWJGL is good for OpenGL (and has some abstractions) and canvases are good for simple 2D games (or as viewports for other renderers).
I have been thinking about this for a while, but I couldn’t make up my mind, so I’ll ask: Which use cases are there in which anonymous inner classes are actually a performance problem? I’m using them for listeners and such, and it never was a bottleneck or even a minor problem for my programs.
Maybe you can show me some examples where anonymous inner classes are a performance problem and how lambdas will help there.
There aren’t really any performance issues with inner classes - they’re just classes after all, like everything else in Java - but the lambda stuff is supposedly going to make certain bits of really complex code that deals with multithreading for performance be much easier to write (and get right).
As for Occam… yes, you can easily see why it failed, but IMHO the problem with programmers wanting coherent memory models is that they/we’ve been brought up to believe that that is how computers are supposed to work, whereas I’m pretty much certain that computers would be much better off having non-uniform local memory architectures from the ground up and we send data by passing messages (a la VBOs in OpenGL for example). A language designed around this paradigm is quite easy to get to grips with. Provided it doesn’t look completely stupid, like Occam.
Cas
Lately I’ve been experiemneting a lot with multithreading, and at the moment I think that functional code is much better suited for concurrency than object oriented code. So I assume that features from functional languages will indeed help there.
Except lambdas!
There’s a bit about performance of lambdas vs inner classes in the second slides links I posted above - pages 31-34. In a lot of current uses of inner classes I guess they’re not really a performance issue. However, tied in to other things that are coming in Java 8, such as internal (and therefore parallelizable) iteration of collections, they could be.
Yeah, that is a good read and explains how it might speed things up by a few microseconds a call; I suppose of more interest to people depending on multicore computing in the future. (Will be a few years yet before it’s really relevant to gaming according to the Steam hardware survey)
Cas
Seems like there’s some point missing going around. Take a look at this: http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html
Reading this, in my head develops the impression that Java 8 will not be a Java anymore as we know it, but a critter of new and old functionality with a confusing mix of options. Just like C++ is a beast, offering so many ways to do things, and requiring so much knowledge to use it well.
I like(d) Java because it was pretty straightforward from the offered concepts.
There were primitive types, and objects.
Now they add a third category, Lambdas. It seems this will have deep impact, because APIs that were built on the old two concepts now don’t look well anymore, and there is a force to change them. So not only the core language changes, but there is force to change all the libraries too.
I’m very careful with changes. This case looks like a change which has almost unpredictable impact on the future development of Java.
Stability is also virtue for a language. Call me old-school, late adopter, and living in someones basement. My opinion at this point of the discussion is that lambdas have the capability to change Java very thoroughly, and I feel sad about losing a simple and still mighty object oriented language this way 