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

Everything about Java 8

techempower.com

Post reply on HN
Print view View original

51–60 of 182 posts

Re: Everything about Java 8

#51

Post by iso8859-1 »

kbenson wrote: post #38
swift wrote: post #21

Earlier quoted context omitted.

In my opinion good uses of operator overloading are ones that preserve the mathematical properties of the operator, so that the operator is in some sense "the same operation", just for different types. By this standard "+" for string concatenation isn't a great choice since string concatenation isn't commutative, but addition is. The same can be said for using "*" for matrix multiplication. If you define these kinds…

You mean like this? (not Java): multi infix: (Int $a, Int $b) { return $a + $b; } multi infix: (Str $a, Str $b) { return $a ~ $b; } say 10 plus 4; # 14 say "foo" plus "bar"; # foobar

what's that? Perl 6?

Re: Everything about Java 8

#52

Post by mark_l_watson »

Unless I am mistaking, Java 8 fails to address the major pain-point I have with Java: hash and array literals.

For me, one of the big wins of both Clojure and Scala is being able to handle maps, sequences, etc. conveniently.

Re: Everything about Java 8

#53

Post by nollidge »

gjulianm wrote: post #13

As a C# developer now experimenting with Java, I still miss some things even from Java 8. Probably some have technical reasons behind, but... - Getters and setters, C# style. That is, instead of private int foo; public int getFoo() { return foo; } public void setFoo(int value) { foo = value; } write this: public int Foo { get; set; } which is both easier to write and makes code more readable and understandable. - Man…

And the two things I notice Java has that C# does not (static methods on Interfaces, and functional interfaces) have completely viable alternatives in C# (extension methods, and Action/Func, respectively). This really smacks of catch-up.

Re: Everything about Java 8

#54

Post by iso8859-1 »

davesims wrote: post #14

With the ability to add static methods and default implementations to an interface, what is now the practical difference between that and an abstract class?

Did you read the article? Try again, search for "Why abstract classes can't be instantiated using a lambda".

Re: Everything about Java 8

#55

Post by Hermel »

gjulianm wrote: post #13

As a C# developer now experimenting with Java, I still miss some things even from Java 8. Probably some have technical reasons behind, but... - Getters and setters, C# style. That is, instead of private int foo; public int getFoo() { return foo; } public void setFoo(int value) { foo = value; } write this: public int Foo { get; set; } which is both easier to write and makes code more readable and understandable. - Man…

I don't think there are technical reasons behind, but rather philosophical ones.

- Getters and setters are bad design. In clean object-oriented code, the internal state of a class is not exposed to the outside. Thus, getters and setters should not be encouraged.

- Exceptions: yes, it would be nice to be able to throw checked exceptions in that example. But the rule that they need to be declared is one of the basic design decisions Java has taken with the intention of always forcing the programmer to handle them. It won't change. (You can still fall back to unchecked exceptions if necessary.)

- Modifying external variables: can be done with a work-around, e.g. "final int[] x" to have a modifiable int. Not sure why that is the case though.

- Operator overloading: considered bad practice for high-reliability code. Generally, Java favors explicit statements in order to prevent mistakes.

- Events: some of the listener stuff in the example could be moved to a library, making it smaller. But still a missing feature in Java.

- Pass by reference: this is normally used as a workaround to create methods with multiple return values. In Java, one could again use the wrapping-array-workaround instead as in the external variables point. I'd love to be have methods with multiple return values in Java.

Re: Everything about Java 8

#56

Post by spullara »

miloshadzic wrote: post #10

The only thing I wish made it in for 8 was coroutines(MLVM project).

I'm definitely pushing for this to be added ASAP — probably won't be before 10 though. In the meantime, it would be awesome if they could get it into OpenJDK behind a flag...

Re: Everything about Java 8

#57

Post by mikeash »

stelonix wrote: post #29
mikeash wrote: post #23

Earlier quoted context omitted.

It seems to me that it's a cultural problem more than anything. People know that they shouldn't take an existing, well-known method name and repurpose it for something completely different. But somehow a lot of people think it's OK to repurpose an operator to mean something completely different just because it's convenient. C++ being the classic example. I think it depends a lot on the languages. Operator overloading…

"But somehow a lot of people think it's OK to repurpose an operator to mean something completely different just because it's convenient. C++ being the classic example." Do you have any data to prove such assertions? A C++ STL operator chosen more than a decade ago is not enough statistical data for one to have such a narrow-minded vision and say these bold statements. Maybe you need to check all the nice C++ librarie…

You seem to have confused the phrase "classic example" with "the worst thing out there, with data to prove it".

It's an example. Do you dispute that? It's classic. That's subjective, and I claim it by raw assertion. That's it.

Re: Everything about Java 8

#58

Post by twic »

DoubleMalt wrote: post #43

Can someone please show the java guys the .TryParse(String s) from C#? I'm convinced everytime I have to manually write the try catch clause for parse a kitten dies somewhere!

As a Java programmer, i agree that the catch blocks around parsing are annoying, but i'm not sure a method that returns an error code is any better. Wasn't that tried back in the '80s?

The way Scala (and probably other functional languages, with which i am not familiar) handle this is with a little bit of polymorphism. Using Java syntax, parsing a string into integer would return a Validation, an abstract type which could be either a Failure or Success. This then exposes methods like ifSuccess(Consumer) (it's called something less obvious in Scala, because that's how Scala works) and ifFailure(Consumer), and various other useful things.

This seems a bit weird at first glance, but it makes it quite easy to deal specifically with either success or failure, or both, or to defer dealing with them until later (you can put a load of Validation objects in a set and worry about whether they're successful or failed later on). It also makes it impossible to ignore failure - there is no error code to forget to check, and no unchecked exception to forget to write a catch block for.

Re: Everything about Java 8

#59

Post by nollidge »

DoubleMalt wrote: post #43

Can someone please show the java guys the .TryParse(String s) from C#? I'm convinced everytime I have to manually write the try catch clause for parse a kitten dies somewhere!

Since Java doesn't have pass-by-ref, this would probably be just as awkward as try-catch.

Re: Everything about Java 8

#60

Post by kbenson »

iso8859-1 wrote: post #51
kbenson wrote: post #38

Earlier quoted context omitted.

You mean like this? (not Java): multi infix: (Int $a, Int $b) { return $a + $b; } multi infix: (Str $a, Str $b) { return $a ~ $b; } say 10 plus 4; # 14 say "foo" plus "bar"; # foobar

what's that? Perl 6?

Yep. Much of the language is implemented in itself (at least in Rakudo), using such structures:

https://github.com/rakudo/rakudo/blob/nom/src/core/Int.pm#L1...

NQP in that link is "Not Quite Perl", a subset of the language which is the what actually needs to be implemented to support Perl 6. This is what's almost done being ported to Java. Again, for Rakudo, which is one implementation.

Post reply on HN