Earlier quoted context omitted.
yes, for a long time, anonymous classes was enough, verbose but enough.
http://en.wikipedia.org/wiki/Turing_tarpit
More a feature tar pit, yes.
State of the Lambda
21–30 of 44 posts
Re: State of the Lambda
#22Re: State of the Lambda
#23I'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).
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…
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.
Re: State of the Lambda
#24Hey, it's only been 17 years.
In which Java basically has taken over the world of enterprise programming. Contrary to fringe languages like Haskell and the like.
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.
Re: State of the Lambda
#25I'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).
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.
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.
Re: State of the Lambda
#26Earlier quoted context omitted.
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…
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.
Is that the @compilestatic one with 520ms ?! I'd imagine not.
Certainly Ruby's acceptable for a large number of tasks, as is Groovy. I use it every day, and will enjoy the speed benefits of Groovy2 in Grails2.x in the coming months, but it's certainly production ready for a large number of tasks now.
As many people continue to point out, if Groovy's slow, write those portions in pure Java. But you can get a lot of the way there just by using explicit types when you know them. The @CompileStatic is yet another performance boost, but you can often get improved Groovy perf by typing if you want to.
Re: State of the Lambda
#27Earlier quoted context omitted.
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.
Is that the @compilestatic one with 520ms ?! I'd imagine not. Certainly Ruby's acceptable for a large number of tasks, as is Groovy. I use it every day, and will enjoy the speed benefits of Groovy2 in Grails2.x in the coming months, but it's certainly production ready for a large number of tasks now. As many people continue to point out, if Groovy's slow, write those portions in pure Java. But you can get a lot of th…
520ms was for the full dynamic version.
But we did have a snafu. The 'groovy' program seems to choose its JVM in an odd way, it was using Apple's 1.6 JVM despite 'java -version' returning the 1.7 JVM.
I fixed this by setting JAVA_HOME and now get ~300ms for the full dynamic version, 22ms for explicit types and 586ms for the @CompileStatic version.
I'm guessing my method of running this is not compatible with @CompileStatic given its results. Did you run this through groovyc and package it into a jar for your tests?
This is on a 2012 MBA with the i5 cpu btw.
Re: State of the Lambda
#28Most 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...
Re: State of the Lambda
#29> 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(); });
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.
Re: State of the Lambda
#30Earlier quoted context omitted.
Is that the @compilestatic one with 520ms ?! I'd imagine not. Certainly Ruby's acceptable for a large number of tasks, as is Groovy. I use it every day, and will enjoy the speed benefits of Groovy2 in Grails2.x in the coming months, but it's certainly production ready for a large number of tasks now. As many people continue to point out, if Groovy's slow, write those portions in pure Java. But you can get a lot of th…
520ms was for the full dynamic version. But we did have a snafu. The 'groovy' program seems to choose its JVM in an odd way, it was using Apple's 1.6 JVM despite 'java -version' returning the 1.7 JVM. I fixed this by setting JAVA_HOME and now get ~300ms for the full dynamic version, 22ms for explicit types and 586ms for the @CompileStatic version. I'm guessing my method of running this is not compatible with @Compile…
I actually ran through the intellij version 12 EAP "LEDA" which has Groovy 2 in it for most of the tests.
The @compilestatic stuff should work regardless, but you do need to import the compilestatic transform.
import groovy.transform.CompileStatic