Hacker News Reader

Comment by matan_a | Hacker News Reader

Well, I can understand the convenience of lambdas for the folks who are used to them.

But overall I think that this can be viewed as "just another feature" that wasn't in their list of priorities when they designed java - nor was it widely even popular in the communities that the java language was targeting. Because of that, it probably caused a lot of grief on implementation. Slap on the Design by Committee mentality that is at the root of Java innovation and i'm surprised it was implemented at all.

To me, it seems like a middle-aged guy getting his ear pierced and some ripped jeans to look cool again with the young crowd.

View on HN

I am entirely unclear on why it is being added to Java. Is there really someone out there who will stick with Java if lambdas are added in the next twelve months, but switch to C# if they aren’t? Is there someone thinking about a new project who will choose Java if it has lambdas?

It strikes me as being one of those check-box features. Someone says “We’ll use Java,” and a C-level executive asks, “Shouldn’t we go with C# and Windows? The Microsoft Solutions Sales Guy tells me you people will be more productive using its advanced features?”

Now the team lead can reply, “Oh, Java now has all that fancy stuff like lambdas," and go ahead writing the code he’s always written.

There's a powerpoint you can find at www.javac.info/bloch-closures-controversy.ppt.

In it is a slide titled "Why Are We Considering Better Support for Closures?", with the following explanation:

Fine-Grained Concurrecy - Passing snippets of code to fork-join frameworks using anonymous classes is a pain

Resource Managememnt - Using try-finally blocks for resource management is a pain, and causes resource leaks

Oh sure, there are good reasons for a language to have support for lambdas. Thanks for the link. My question is not whether they offer benefits, but whether those benefits are going to sway anyone’s decision one way or another.

This is like asking whether any product should have feature X. We go out and do a survey, and find some number, “C," of our customers would use the feature if we implement it. But this is not the number we need. We need the number of existing customers we would lose to competitors if we don’t implement the feature in the near future (“L"), and the number of new customers we would win away from competitors if we implement the feature (“W").

The salient number to consider isn’t C, but rather (L+W). That’s the number that tells us the return in market terms of implementing the feature. In my comment, I was asking if (L+W) is significant. The reasons given for lambdas speak to C and perhaps L.

It seems like you're thinking about it in terms of a programming language market place, and you're trying to optimize Java's placement in that market place. Which is a valid perspective, but probably not the one they're coming from.

I think their perspective is more, "Given that Java is the programming language some people will choose, how can we make their life easier?" I think that's a valid perspective as well, since many people are forced to use a particular programming language.

Perhaps they are being added just because current Java programmers believe it will make their lives better?

c.f. the Saphir Whorf conjecture, those Java programmers who know that simplified access to anonymous functions will make their lives better is by default restricted to that minority that has encountered them elsewhere. Many of these people, in my experience, would rather not be writing Java.

But that's not the same as saying they are not writing Java.

True enough. It just seems like it'd be disheartening to be plugging away at Java with enough foreknowledge to push through the JCP if you really wanted to be playing in a different playground.

I know and like lambda functionality and I also use Java. People pay me good money to write Java for them and I like the language and platform well enough so the chance to get closures in Java is great. At some point I'd love to use Scala or Groovy or Gosu at work but that's not the case now and I'm fine with it.

Hey, I'm all about the generalization.

Is there really someone out there who will stick with Java if lambdas are added in the next twelve months, but switch to C# if they aren’t? Is there someone thinking about a new project who will choose Java if it has lambdas?

On the margin, sure. It's like asking "will we really sell more widgets if we reduce the price by 1%". If you want a specific case, look at Apache Wicket. It uses tons of anonymous inner classes to emulate lambdas and developing in it would be a much better experience with less cumbersome syntax.

There is a certain convenience to common things being commonly available in common languages. It's just nice to be able to jump between languages and have a lot of things work the same way, or to be there at all.

I suspect that lambdas have gained enough modern mind share with developers that it's just a nice thing to have. A lot of tasks these days probably have the look of "put lambda here" to a lot of people.

Whether Sales Guy and Manager are playing chess over the matter, it's just nice to be able to write the code the way that you would naturally write it.

Closures/lambdas in Java may affect how implementations of other JVM languages implement their corresponding features.

This may affect interoperability between languages positively. Currently JVM languages interoperate nicely with Java but advanced non-java-like features between other JVM-based languages do not match so well (can you pass a ruby block from JRuby to Scala?)

I think it was Neal Gafter who raised this as a good reason for closures in Java, but I could be mistaken.

Reply on news.ycombinator.com