State of the Lambda

http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-4.html

by jondot • 14 years ago

63 43 14 years ago

cr.openjdk.java.net

rat872• 14 years ago

State of the Lambda December 2011 4th edition

eranation• 14 years ago

Yes, why old news make front page? I guess not everyone is aware of it yet.

CervezaPorFavor• 14 years ago

Fortunately for us, the programming language world isn't as litigious as the smartphone world.

simgidacav• 14 years ago

I cannot see how to apply the lambda-calculus to smartphones…

eblackburn• 14 years ago

Lamdas are not orignal.

rat872• 14 years ago

Considering every other very high level language(gc'd) language has them(and even c++/obj-c to some extent) there is plenty of prior art.

pacala• 14 years ago

> Default methods provide a more object-oriented solution for this problem: people.sort(comparing(Person::getLastName));

Yay function pointers.

rforax4• 14 years ago

and default methods are traits but it's a secret.

henrikschroder• 14 years ago

> An alternative (or complementary) approach to function types, suggested by some early proposals, would have been to introduce a new, structural function type. A type like "function from a String and an Object to an int" might be expressed as (String,Object)->int. This idea was considered and rejected, at least for now, due to several disadvantages:

Too bad they didn't, C# originally had delegates that you had to declare, but with the addition of generics and lambdas, that system got prettier and easier. The generic delegate types Func and Action are just that, so I can have a method that looks like this:

  private Foo MyMethod(string str, Func<Bar, string, int> func) {
    //...
  }

...which means that MyMethod is a method that takes two arguments, the first is a string, and the second is a method that takes two arguments, a string and an int, and returns a Bar object. But when I call it, I can use a lambda expression, like this:

  var result = MyMethod("hey hey", (s, i) => new Bar(s, i));

...which is far from unwieldy. But I can see how checked exceptions would make it horrible, and I'm glad C# doesn't have those.

jfager• 14 years ago

Using lambdas in Java 8 looks pretty much exactly like your example.

The line you quote from the article is about a proposed way of declaring lambda types, where instead of

    private Foo MyMethod(string str, Func<Bar, string, int> func) {
      //...
    }

you could write something like

    private Foo MyMethod(string str, (string,int)->Bar func) {
      //...
    }

jmcdonald-ut• 14 years ago

If this helps replace functors I'm all for it.

batgaijin2• 14 years ago

Hey, it's only been 17 years.

rforax4• 14 years ago

yes, for a long time, anonymous classes was enough, verbose but enough.

eslaught• 14 years ago

http://en.wikipedia.org/wiki/Turing_tarpit

factorizer• 14 years ago

In which Java basically has taken over the world of enterprise programming. Contrary to fringe languages like Haskell and the like.

karterk• 14 years ago

Not everything that grows like weed is necessarily awesome. Just saying.

batgaijin2• 14 years ago

Java forces you to write code in a pretty readable/static manner. Of course you can write 'bad' Java, but the point is that Java limits expressiveness so that YOU are replaceable/won't introduce memory issues. That's the whole point of using Java in the enterprise.

To be clear, I'm not saying anything bad about the JVM.

mikeash• 14 years ago

Kind of like how Windows basically took over the world of PC computing?

mbell6• 14 years ago

I'm surprised more people aren't just using Groovy. The performance of Groovy 2.0 on JVM 7 is greatly improved to the point where its a non-issue in 95% of situations (and you can just drop to java for those portions with no penalties).

mgkimsal6• 14 years ago

I tend to agree with you, but Groovy 2 is still pretty new. In my experience, most of the hardcode Java shops and devs that rejected Groovy (primarily?) because of speed are generally slow-adopters, and wouldn't be using Groovy 2 just because it was released a few months ago.

As to speed, I've not benchmarked it on JDK7, so I'm not sure what effect the InvokeDynamic stuff has yet, but @CompileStatic annotation helps a lot.

My fibonacci stuff at https://github.com/mgkimsal/newgroovy2 (did a presentation on groovy2 last week) showed:

fibonacci run of 30:

* pure java (not in the github) - 12ms

* groovy2 compilestatic - 18ms

* groovy2 dynamic with typedefs - 30ms

* groovy2 no typedefs - 500ms

So yes, while @CompileStatic groovy2 is technically approx 40-50% 'slower' in these tests, the noticeable diff for a lot of projects (especially considering file and db access will be constants regardless) will be likely negligible.

rforax4• 14 years ago

@CompileStatic is a great idea even if I prefer approach like Dart or ActionScript partial typing.

Groovy closure used dynamic scoping rules not unlike 'this' in JS which makes Closure a corner case for the static analysis performed by @CompileStatic.

mbell6• 14 years ago

Just for the sake of comparison, I ran your groovy code vs a similarly styled ruby version of fib.

Groovy 2.0.1 (simply ran with 'groovy fib.groovy') JVM 1.7.0_06_64-b24 ~520ms

Ruby 1.9.3p194 ~475ms

Obviously this is well into micro-benchmark territory but it seems even worse case is on the order of ruby's performance which is perfectly acceptable for a large number of tasks.

vorg2• 14 years ago

Groovy 2.0 was only released a few months ago, and isn't production ready. Groovy 2.0 has two jars in it, one with static-compilation and static-inference grafted on, and the other with optimizations for JDK 7's invoke-dynamic bytecode. Programmers can't use both static-compilation and invoke-dynamic in the same source file.

Also, both jars seem to have problems. Groovy 2.0.4 was released yesterday only 2 weeks after version 2.0.2 was released "to fix static compilation and type inference problems". Grails 2.2-rc-1 (actually the first beta and not a serious "release candidate" for production use, because the releases called "beta" are really alphas) has only just been released, the first with Groovy 2.x, with only the static-compilation jar from Groovy 2.0.2 bundled, not the invoke-dynamic jar.

The facilities of the invoke-dynamic jar might never be merged into the static-compilation jar. There seems to be some infighting at SpringSource over who's in control of Groovy. Version 2.0.3 was skipped because the P.M. "compiled it on the JDK 6 instead of JDK 7 by mistake", which looks like a political play by Guillaume Laforge, SpringSource's project manager for Groovy, against Jochen Theodorou, their technical lead who's done most of the programming work on Groovy since 2004.

A year ago, Laforge hired another developer, Cedric Champeau, to put static type inference and compilation into Groovy, in order to mitigate a SpringSource business threat by Alex Tkachman's Groovy++, a static-compilation addon to Groovy which has since been abandoned. Groovy++ had to switch from supporting Groovy 1.8 to 1.7 for a while during its development because of compatibility problems in subsequent beta releases of Groovy, which may have been deliberate, and at the very least, Groovy++ served as an "inspiration" for Groovy 2.0's static-compilation jar. It's looking like Theodorou's invoke-dynamic bytecode optimizations aren't being merged into the static-compilation jar because of a power play by Laforge and Champeau who control the static-compilation jar. The project manager is diluting Theodorou's technical importance to Groovy and thus increasing his own influence.

Concerning your benchmarks of Groovy with Java, you left out Scala and Clojure, also popular JVM languages, and you chose an algorithm not used much in business. Both Scala and Clojure have lazy-evaluation in their library lambdas/functions, as will Java 8. Groovy only enables strict evaluation, which slows down many computations used in real business programming scenarios, of which fibonacci isn't one. Lazy-evaluation isn't in the pipeline for Groovy anytime soon. Its "GDK" utility methods were mostly written early on by a programmer without the aptitude for developing anything too complex, such as lambdas with lazy-evaluation. Seems like JDK 8's lambdas, due to ship in about a year, will be the first time Groovy will enable lazily-evaluated computations, long after Scala and Clojure. As for the invoke-dynamic bytecode optimizations being merged into the main jar used by Groovy 2.0 and Grails 2.2, JRuby's long stolen that show. It might never happen with Groovy.

And of course there's no spec for Groovy, unlike Scala's detailed spec or Clojure's function doc-strings. Without a spec, Groovy is still single-platform, unlike Clojure and Scala, and many other JVM languages that began their life somewhere else first.

So I don't think slow adoption by Java shops that were concerned about Groovy's performance is the reason more businesses don't adopt Groovy. It's more likely that the static-compilation code isn't production ready, just laden with problems, political infighting at SpringSource, trailing behind other languages in lazy-evaluation of lambdas (Clojure, Scala) and invoke-dynamic optimizations (JRuby), an informal-only spec that changes between point releases, the names "Groovy" and "G-Strings" evoking drug use and discrimination against female employees, and a general sense by technical managers that there's a price to be paid later down the line if they adopt Groovy.

benmccann• 14 years ago

Groovy 2.0 isn't really used because it's so new. E.g. you can't use Groovy 2.0 with Grails until Grails 2.2 is released.

mbell6• 14 years ago

While I understand that its not like Groovy requires a large change to start using (unless your running Grails I guess). I just started using it a month ago when I ran into a hunk of JSF controller code that would be drastically simplified with the use of closures. It only took 1 dependency in the pom and a tweak to the maven compiler plugin and I was off and running. It integrates so easily with Java that no code changes anywhere but the controller I was writing were needed.

spullara• 14 years ago

Most of the effort around Lambda in the JVM has now shifted to implementing the collection libraries. You can follow along here:

http://mail.openjdk.java.net/pipermail/lambda-libs-spec-obse...

ScottBurson2• 14 years ago

> It is our intent to prohibit capture of mutable local variables. The reason is that idioms like this:

  int sum = 0;
  list.forEach(e -> { sum += e.size(); });

> are fundamentally serial

An unfortunate decision. Yes, updating such a variable from multiple threads can cause race conditions. But there are many ways to run into race conditions when writing multithreaded code, and this doesn't really add a new one.

Furthermore, most code is mostly serial, and the ability to modify captured variables is a very useful one in serial code. (I've written code like that in Lisp for decades.) And finally, the restriction is, of course, easily worked around -- just store the value you want to update in a 1-element array.

So the restriction doesn't really protect anyone from anything -- it just forces them to use an ugly workaround in order to write their algorithms in a natural way.

seanmcdirmid• 14 years ago

Ironically, "sum += e.size()" is conceptually not serial at all; the order that each iteration runs is not relevant while you could restructure the computation into a tree of partial aggregations.

The work around in Java, using a Cell<T>, is a hack that gives you the updatable mutable variable you need without too much ugly overhead. so something like...

  cell = new Cell<T>(); ... { ... cell.Value = ... } })

kevinpet• 14 years ago

The motivation is that the question of whether list.forEach (or maybe better, iterable.forEach) is serial or parallel is to be left up to the implementation of the collection. Everything related to multi-threaded code since about Java 5 has been about hiding the details of concurrency and allowing programmers to think about code in a serial fashion, but still get the gains from multi threaded code.

It's not necessarily about parallelism either -- you could just as easily pass in a function as some sort of callback that gets called far in the future, for example,

String error = null; return createClientWithErrorHandler(e -> { error = e; });

What does that even mean? Does the execution context need to be kept hanging around?

Java already provides good atomic references if you need to have a sum variable or anything similar.

ScottBurson2• 14 years ago

> What does that even mean? Does the execution context need to be kept hanging around?

Once the block containing the declaration of 'error' has been exited, the only way anything could refer to 'error' would be if there were at least one additional lambda expression in the same block that was closed over the same binding of 'error'. Two such lambda expressions could thus communicate with each other through the shared binding.

ww520• 14 years ago

It actually looks pretty good. I can see they spend a lot of effort to make sure it fits into the existing system, keeping new syntax or new form to the minimum.

State of the Lambda

Related Stories