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

171–180 of 182 posts

Re: Everything about Java 8

#171

Post by mikeash »

tragomaskhalos wrote: post #169
mikeash wrote: post #158

Earlier quoted context omitted.

I disagree that the precedence is natural. Without looking it up, and without compiling it, what do the following (IMO quite reasonable in general) lines of code do? cout As for the visual implication of movement, I have no objection whatsoever to using the << operator for stream operations in general. However, I strenuously object to doing this in a language which already defines them as bitshift operators. Repurpos…

Point taken, but small beer IMO; I use parens in boolean expressions because I can never remember the precedence of && vs ||, so would naturally use them here too. And I don't buy the fact that Yes the << notation isn't perfect, but it is much nicer than named functions (and certainly superior to < (which Stroustrup initially considered)!). Adding arbitrary operators to the language would have required mechanisms to…

I don't really see the big advantage to 
    cout
It's about as readable to me. To me, operator overloading is good when the meaning is already obvious because of shared context that everybody has. That's not the case when co-opting << for stream operators.

Re: Everything about Java 8

#172

Post by mhixson »

svdb wrote: post #156

One small correction/addition: For Stream.anyMatch(), Stream.findFirst() and Stream.findAny() it is mentioned that these are short-circuiting operations. This is however also true for Stream.allMatch() and Stream.noneMatch().

You're right! Thanks, I'll get that fixed up in the next batch of edits.

Re: Everything about Java 8

#173

Post by amouat »

y0ghur7_xxx wrote: post #96
amouat wrote: post #86

Earlier quoted context omitted.

Considered by people who have used C++ and seen some awful problems creep in because of unnecessary operator overloading. Your last point actually highlights the problem - it is not more reliable because you are assuming what "+" and "*" do. EDIT: An old blog post about the issue: http://cafe.elharo.com/programming/operator-overloading-cons...

>> natural syntax like a+b c than verbose alternatives like a.add(b.multiply(c)). > it is not more reliable because you are assuming what "+" and " " do. You also assume what "add" and "multiply" do.

Yes, but I think it is far worse in the case of built-ins; it is explicitly obvious that "add" is not part of the language, which is not the case with "+". Admittedly this is much more of a problem for new programmers than experts.

To be fair, I think a lot my prejudice against overriding operators is summed up by Bruce Eckel (who explains why it is arguably misguided in the case of Java):

"[Java designers] thought operator overloading was too hard for programmers to use properly. Which is basically true in C++, because C++ has both stack allocation and heap allocation and you must overload your operators to handle all situations and not cause memory leaks. Difficult indeed. Java, however, has a single storage allocation mechanism and a garbage collector, which makes operator overloading trivial -- as was shown in C# (but had already been shown in Python, which predated Java). But for many years, the partly line from the Java team was "Operator overloading is too complicated."

http://www.artima.com/weblogs/viewpost.jsp?thread=252441

Re: Everything about Java 8

#174

Post by amouat »

Chris_Newton wrote: post #93
amouat wrote: post #86

Earlier quoted context omitted.

Considered by people who have used C++ and seen some awful problems creep in because of unnecessary operator overloading. Your last point actually highlights the problem - it is not more reliable because you are assuming what "+" and "*" do. EDIT: An old blog post about the issue: http://cafe.elharo.com/programming/operator-overloading-cons...

Your last point actually highlights the problem - it is not more reliable because you are assuming what "+" and " " do.* How is that any different to assuming what add() and multiply() do? In many ways, I’d say the latter is worse, because it’s not immediately obvious from just the function names whether the operation mutates the object it’s called on or returns a new object with the result while the originals remain…

> For + and * operators, someone already decided what the convention should be. If you just make them work like the built-in versions, the semantics are already intuitive to anyone who studied basic arithmetic at school.

I think it's exactly this that is misleading - your intuition may not be the same as developers. I think people assume more from "+" than they would from "plus()" and if you don't think about it you may falsely assume you are using a language built-in.

I'm not saying that operator overloading can't be useful, but in C++ developers did create horrible code by using /, *, + in their classes to 1) show off that they could and 2) to save typing. If they had to name their methods, I hope there is a good chance they would have done better than divide(), multiply() etc.

Regarding the article, I agree it is somewhat guilty of hyperbole, but I don't think calling it a troll is remotely fair.

BTW I don't understand what you mean by "can be useful on the basis that anyone making that argument just doesn’t understand", which makes me feel like I've wandered into a double joke ;)

Re: Everything about Java 8

#175

Post by kzrdude »

tragomaskhalos wrote: post #77
stelonix wrote: post #29

Earlier quoted context omitted.

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

There's basic language bigotry going on here: an aged internet meme declares that C++ operator overloading is bad because you can indeed, in theory, do idiotic counter-intuitive things with it. Yet the identical capability in Ruby, Scala and Haskell (inter alia) is deemed A Good Thing by the consensus.

You can't overload operators in Haskell. You can define new operators though. You're not going to change the meaning of + unless you remove the old.

Re: Everything about Java 8

#176

Post by suppressingfire »

nollidge wrote: post #59
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.

Guava's Hints.tryParse is about as good as it can get in Java... Maybe it could return an Optional instead of a nullable boxed type, but the calling code wouldn't be much different.

Re: Everything about Java 8

#177

Post by karianna »

spullara wrote: post #56
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...

There's no real work being done on this at the moment (I was involved with trying to kick start a small team with the original patch authors). We've started discussing it again, but it's looking like a case of "Real Life" getting in the way :-|. Will see if I can get the broader Adopt OpenJDK programme to take it on board.

Re: Everything about Java 8

#178

Post by karianna »

fierarul wrote: post #110

Very interesting read. So, nothing new on the Swing side?

Swing is effectively dead. Oracle will no longer invest in the technology, the preferred way forward is definitely JavaFX (2.0+), it shows a lot of promise for those who still need this type of UI tech.

Re: Everything about Java 8

#179

Post by tomjen3 »

swift wrote: post #25
scanr wrote: post #17

Java 8 looks good enough to make Java a reasonable candidate for Java.Next. Especially given that there doesn't appear to be a clear winner between the alternatives (Scala, Groovy, Clojure, Kotlin etc.). Java 8 seems to have borrowed a lot from Guava (Optional, Function, Predicate, Supplier etc.). Extension methods as well as default methods on interfaces would have been nice.

Mixins would be great too.

Default methods in interfaces makes them mixins.

Re: Everything about Java 8

#180

Post by tomjen3 »

sgt wrote: post #152
fierarul wrote: post #110

Very interesting read. So, nothing new on the Swing side?

I can't tell if you are serious or not. Swing is dead, from my point of view. In any case, desktop programs isn't really a strength of Java.

Actually that is a case where Java really shines, as it is cross-platform
Post reply on HN