Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of the Lambda

cr.openjdk.java.net

Post reply on HN
Print view View original

11–20 of 44 posts

Re: State of the Lambda

#13

Post by jfager »

henrikschroder wrote: post #8

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

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 func) {
      //...
    }
you could write something like

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

Re: State of the Lambda

#15

Post by mbell »

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

Re: State of the Lambda

#17

Post by mgkimsal »

mbell wrote: post #15

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

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.

Re: State of the Lambda

#18

Post by benmccann »

mbell wrote: post #15

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

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.

Re: State of the Lambda

#19

Post by rforax »

mgkimsal wrote: post #17
mbell wrote: post #15

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

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…

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

Post reply on HN