Live data from Hacker News

Java 8 lambda syntax decided - same as C# and Scala

mail.openjdk.java.net

31–40 of 81 posts

Re: Java 8 lambda syntax decided - same as C# and Scala

#31
post #8

Earlier quoted context omitted.

Erm, its not?. Shawndumas was just pointing out that a decision was finally made. They were grappling over the syntax for over two three years. Now they will just need to grapple over with what kind of scoping that Java's lambdas will have.

I think stating it that way trivializes the amount of work that _has_ gone into lambdas. There's been a lot of other, more fundamental things discussed over that 2-3 year period about their implementation; way more than syntax.

What in particular? (Java isn't my primary language, so I haven't been following this.)

Do you mean about how lambdas are implemented from a bytecode standpoint, or other types of issues?

Re: Java 8 lambda syntax decided - same as C# and Scala

#32
post #30

try { // for a really long time } finally { // made a decision }

There's a JVM language out there that initially allowed try-statements without catch or finally clauses, e.g try{ //for a short time only to decide } But one of its despots, five years after the language was first released, changed the syntax to make a catch or finally clause compulsory, e.g try{ //for a short time to decide }finally{} Because I had used these standalone try-statements a lot, I had to go thru all my…

What benefits does an empty try block give you? You can always use braces to separate a block without try at all.

Re: Java 8 lambda syntax decided - same as C# and Scala

#33

Lambdas are a lot of fun on C#. new Thread( => { doStuff(); }).Start();

Big deal: new Thread(new Runnable() { public void run() {doStuff();} }).start();

But for a small function (which a lambda typically is), the syntactic overhead of "new Runnable() { public void run()" swamps the actual logic. When I read this version, it's hard for my eyes to find what work is actually being done because there are so many braces and brackets and words. The big deal of lambda syntax is that it lets you focus on the code that does the work (the doStuff) instead of the adapter (the "new Runnable() { public void run()") that the library needs around that code.

Re: Java 8 lambda syntax decided - same as C# and Scala

#34
post #30

Earlier quoted context omitted.

There's a JVM language out there that initially allowed try-statements without catch or finally clauses, e.g try{ //for a short time only to decide } But one of its despots, five years after the language was first released, changed the syntax to make a catch or finally clause compulsory, e.g try{ //for a short time to decide }finally{} Because I had used these standalone try-statements a lot, I had to go thru all my…

What benefits does an empty try block give you? You can always use braces to separate a block without try at all.

You can use it to suppress exceptions.

Re: Java 8 lambda syntax decided - same as C# and Scala

#35
post #30

Earlier quoted context omitted.

There's a JVM language out there that initially allowed try-statements without catch or finally clauses, e.g try{ //for a short time only to decide } But one of its despots, five years after the language was first released, changed the syntax to make a catch or finally clause compulsory, e.g try{ //for a short time to decide }finally{} Because I had used these standalone try-statements a lot, I had to go thru all my…

What benefits does an empty try block give you? You can always use braces to separate a block without try at all.

> What benefits does an empty try block give you?

An empty try block allows us to repeat variable declarations with the same name in a long stretch of scripty-style code.

> You can always use braces to separate a block without try at all.

You can use braces in Java, but not in that language I'm talking about: it'll throw an error saying "Ambiguous expression could be a parameterless closure expression, an isolated open code block, or it may continue a previous statement; solution: Add an explicit parameter list, e.g. {it -> ...}, or force it to be treated as an open block by giving it a label, e.g. L:{...}, and also either remove the previous newline, or add an explicit semicolon ';'".

The standalone-try looked far more elegant than:

    dudlabel:{
      //do something
    }
Better for that despot to re-enable standalone try-statements in Groovy than petitioning the Java 8 designers that thin arrows look better than industry-standard thick arrows.

Re: Java 8 lambda syntax decided - same as C# and Scala

#36

I see that the proposed lambda expressions can omit type annotations on the parameters. Does that mean that Java 8 will have at least some limited form of type inference?

The single abstract method interface type of a lambda will be inferred by its declaration site.

Will they be full closures and remember the state of objects in scope?

Re: Java 8 lambda syntax decided - same as C# and Scala

#37
post #21

Earlier quoted context omitted.

nah, it would have to be new Thread(new ThreadStart(doStuff)).Start();

Sorry, but since C# 2.0 we could just write "new Thread(DoStruff)" or "SomeDelegate del = SomeMethod".

I can't resist, so,

    public static class ActionExtensions
    {
        public static void InvokeAsync(this Action target, object context)
        {
            new Thread(obj => target(obj)).Start(context);
        }
    }

     ((Action) (Console.WriteLine)).InvokeAsync("Hello, World");

Re: Java 8 lambda syntax decided - same as C# and Scala

#39
post #27

Any details on variable capturing from outer scope? The same as C# (apparently capture all variables?)?

yes, closures are implied. lambda's are almost useless without closures being included.

I think the difference between capturing values at call time and full closures only matters if you are mutating variables, which my closures rarely do, since my code is fairly functional'ish, so for me it does not matter.

Re: Java 8 lambda syntax decided - same as C# and Scala

#40
post #30

try { // for a really long time } finally { // made a decision }

There's a JVM language out there that initially allowed try-statements without catch or finally clauses, e.g try{ //for a short time only to decide } But one of its despots, five years after the language was first released, changed the syntax to make a catch or finally clause compulsory, e.g try{ //for a short time to decide }finally{} Because I had used these standalone try-statements a lot, I had to go thru all my…

  But one of its despots, five years after the language was
  first released, changed the syntax to make a catch or
  finally clause compulsory, e.g
Are you the person who believes the Groovy developers are personally working to invalidate your web tutorials so they can discredit your fork of the language?

Lest HN think I'm being ungenerous, please read http://groovy.codeplex.com/wikipage?title=Blog01 , which features similar language regarding "despots".

  Of course, Groovy also differentiates itself from Guava
  by having a dedicated language syntax, which is no doubt
  why the cartel don't want to standardize it. If it was
  standardized, they couldn't make some random blogger's
  sample code stop working by suddenly requiring all
  try-statements to have an empty finally clause.
Post reply on HN