Live data from Hacker News

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

mail.openjdk.java.net

61–70 of 81 posts

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

#61
post #60
post #50

Earlier quoted context omitted.

I did say scripty code. My typical scripting session from scratch starts with opening a simple editor and starting to type in code. The structure is loose, perhaps it's testing something I've written in another file in a statically-typed language. As the code evolves, I slowly give it more structure by reworking it. At some stage I MIGHT put some code into methods. But before that stage, nested scopes are useful beca…

Why not just use braces? Take all your 'try' keywords out and the scope limitations are the same. Unless you're relying on the try {} to avoid bombing when there are assertion errors? That just seems a bad way of doing unit testing.

You can do that in Java but not in Groovy unless you write

    tr:{
      //...
    }

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

#62
post #25

Nice to see pragmatism playing a role here. A big problem with Java has always been the "design by committee" nature of it where we end up with some theoretical best case that satisfies everyone's egos but turns out to utterly suck when used in practice. From another point of view ... it's a shame we needed so many years to come up with "let's do it like C#".

It's also a shame they haven't done so with other features -- like getting rid of checked exceptions.

I think checked exceptions are just ahead of their time. They make sense when you statically check your code against contracts, which is why they showed up again in the spec# research project. http://en.wikipedia.org/wiki/Spec_Sharp

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

#63
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'm more familiar with C++ lambdas, and in those you must specify how you will capture variables (no capturing, by reference, by value, or some mix of those).

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

#65
post #55

Earlier quoted context omitted.

It often leads people to write code like this: try { // do stuff } catch (TheCheckedException ex) { // ignore it } then the code continues even though it could be in a bad state if an exception did occur. It's a much better solution to let it propagate up the call stack until it can be dealt with appropriately (e.g. by ending the application, giving a 503 error on a web page request, etc.) Unchecked exceptions will p…

So add a 'throws' clause to the method in which you call the code that throws the checked exception and it will propagate upward.

...or rethrow it as an unchecked exception(RuntimeException).

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

#66
post #46

Earlier quoted context omitted.

Can you expand on why would you like to get rid of checked exceptions?

It often leads people to write code like this: try { // do stuff } catch (TheCheckedException ex) { // ignore it } then the code continues even though it could be in a bad state if an exception did occur. It's a much better solution to let it propagate up the call stack until it can be dealt with appropriately (e.g. by ending the application, giving a 503 error on a web page request, etc.) Unchecked exceptions will p…

Well, just use runtime exceptions for your own code. (Though, they'll hardly ever change the exceptions in the base libraries to runtime exceptions)

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

#67
post #62

Earlier quoted context omitted.

It's also a shame they haven't done so with other features -- like getting rid of checked exceptions.

I think checked exceptions are just ahead of their time. They make sense when you statically check your code against contracts, which is why they showed up again in the spec# research project. http://en.wikipedia.org/wiki/Spec_Sharp

Optional checked exceptions have some benefits.

Java got them the wrong way around - unchecked should have been the default, with checked available when you need them.

Because Java does them the other way around, you either get code bloat from the large numbers of exceptions you are catching and handling subtly differently or you have a generic catch(Exception e){..} block. Neither are ideal.

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

#68
post #12

Excellent to have this finally resolved. I'm sad to not see something a little closer to the ruby block syntax like in some of the early proposals, though. Special syntax for lambdas as the last argument to a function lets you write very readable code for a host of useful cases.

Nota Bene: A Ruby Block is not the same thing as a Ruby Lambda, although conversion between them is easy. Yielding to a block has somewhat different semantics than calling a lambda, especially with respect to non-local return.

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

#69
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…

Perhaps you can educate me on your better reasoning, but the only purpose I can see for an empty try block is to limit the scope of variables in a method. Quite frankly, if you find yourself in need of artificially limiting the scope of variables in a method, you've probably done too much in the method and need to refactor.

Try block are for just that, trying something you know ahead of time might fail. There's no point in using the try paradigm if you don't also intend to handle the expected failure.

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

#70
post #25

Nice to see pragmatism playing a role here. A big problem with Java has always been the "design by committee" nature of it where we end up with some theoretical best case that satisfies everyone's egos but turns out to utterly suck when used in practice. From another point of view ... it's a shame we needed so many years to come up with "let's do it like C#".

It's also a shame they haven't done so with other features -- like getting rid of checked exceptions.

Why are you opposed to checked exceptions?

Frankly this is one complaint about java I have never understood. I, myself, have missed checked exceptions in C# when I have had to port Java code to C#.

Post reply on HN