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

81–90 of 182 posts

Re: Everything about Java 8

#81

Post by mikeash »

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.

For me, and perhaps others, this is because C++ enshrines idiotic counter-intuitive operator overloading in its standard library.

Re: Everything about Java 8

#82

Post by mikeash »

pcote wrote: post #31
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…

>Operator overloading is easy and common in Python, but in my (limited) experience, it's used to create new classes which respond to existing operators with existing semantics, e.g. to make new number classes. In Python, it's called "special method attributes" and they can do a lot more than just create classes. The __eq__ attribute returns a straight boolean for example in response to the "==" operator. And yes, by…

Sorry if I was unclear, but I meant that this facility lets you create classes whose instances work like built-in numbers, not that the facility itself is used to create clases somehow.

Re: Everything about Java 8

#83

Post by DoubleMalt »

MichaelGG wrote: post #66
twic wrote: post #58

Earlier quoted context omitted.

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…

TryParse returns a boolean. So you use it like this: int res; if int.TryParse(s, out res) { // OK } { else // not ok } You certainly do not need an exception to deal with the simple case of "did this string parse into an int". Edit: A great alternative signature is to use Maybe/Option, so you get Some int or None. match int.TryParse s with | None -> ... | Some i -> ...

Ah apparently I remembered it wrong. I thought it was

int res = int.TryParse(s, 0); // 0 as the default if parsing fails

Of course if there is no reasonable default you should bubble the thing up anyway or handle it on the spot. But very often for input parsing there is sane default you can choose.

Re: Everything about Java 8

#84

Post by MartinCron »

smackfu wrote: post #32
stelonix wrote: post #18

Earlier quoted context omitted.

Nonsense. To paraphrase myself from a similar discussion on reddit: "List.add(otherList) Honestly, it's about time the Java crowd stops with the mantra and starts thinking from themselves. Or at least, learn why the reason you hate operator overloading is fallacious.

It just seems an odd hill to die on. Just a minor little feature that most people would use only occasionally in their objects.

It just seems an odd hill to die on.

There's an axiom to be found somewhere there. If it's a hill, someone will be willing to die on it.

Re: Everything about Java 8

#85

Post by smrtinsert »

stelonix wrote: post #18
pcote wrote: post #11

Earlier quoted context omitted.

Why? Sure, overloading a "+" operator can be elegant looking. But the aesthetic gain vs. maintainability doesn't seem to be worth the tradeoff 99% of the time. I certainly wouldn't want to be the one who has to debug the thing because someone accidentally side effected one of the "operands".

Nonsense. To paraphrase myself from a similar discussion on reddit: "List.add(otherList) Honestly, it's about time the Java crowd stops with the mantra and starts thinking from themselves. Or at least, learn why the reason you hate operator overloading is fallacious.

the nice part about java is the legibility. I can simply start with a new instance of your object and auto complete to the method that I want. Once operator overloading joins the fray everyone is off to the races for crappy dsl of the week. "here's how you do the XXX lib way".

I'd prefer if that option stays off the table. Given that java users are on ides, autocompletion makes an api call a one character effort anyway and saves us from tons of stupid operators.

Re: Everything about Java 8

#86

Post by amouat »

Chris_Newton wrote: post #71
Hermel wrote: post #55

Earlier quoted context omitted.

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

Operator overloading: considered bad practice for high-reliability code. Generally, Java favors explicit statements in order to prevent mistakes. Considered by whom? The example gjulianm gave, where == is safe if nulls are flying around but calling .equals() on a null expression results in an exception, seems a clear counterexample. I’d also argue that if your code is mathematical in nature, it is both quicker and mo…

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

Re: Everything about Java 8

#87

Post by dougk16 »

mongol wrote: post #72
Hermel wrote: post #55

Earlier quoted context omitted.

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

> 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. How can this be a general statement? Some state can be internal, some can be public. Java supports both. Or how do you suggest that state should be accessed? Because I don't understand how a system can work if no state is shared between o…

At least one paradigm, is that you ask an object to do something for you with its internal state and return the result, instead of getting its internal state and doing the operation yourself. And instead of setting state directly, you have methods that let an object know something happened, with data optionally associated with the event. This paradigm really decouples objects, which is good, but is fairly time-consuming to pull off, and doesn't necessarily lend itself well to being extensible. I generally utilize this paradigm for mission-critical business logic. If I'm doing something UI-related on the other hand, my classes are festooned with getters and setters just because I need to iterate fast and get it done.

Re: Everything about Java 8

#88

Post by simpsond »

Java 7 failed to excite me. Java 8 however, has many features that I can use today. Lot's of stuff from guava, cleaner anonymous classes (lamdas), trait-like interfaces, FluentIterable++ (streams)... it's a good time to be a java developer.

Re: Everything about Java 8

#89

Post by smrtinsert »

krg wrote: post #12
smrtinsert wrote: post #8

Language and api wise these are nice additions, but all I can think about these days is emscripten. The JVM should support the client side out of the box, why oh why didn't Google buy Java?

I'm not sure what you mean exactly, but as mentioned in the article they've built a new JavaScript engine (to replace Rhino) to be included in Java8: http://openjdk.java.net/jeps/174

Just that an entire revolution is happening in the browser itself, I'd really like to be able to code Java directly with something GWT. I read recently that GWT has support for the latest html5 stuff, but complaints about compile time and lack of performance after compilation turn me off...

Re: Everything about Java 8

#90

Post by Someone »

gjulianm wrote: post #76
twic wrote: post #58

Earlier quoted context omitted.

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…

Well, you could substitute that for if(Int.CanParse(s)) { i = Int.Parse(s); // OK things. } else { // Not ok. } but it also be weird in Java because Parse throws and exception, so you'd have to either write an empty catch block or declare the method with a throw clause, event though it actually doesn't throw anything.

That either is inefficient (you end up parsing each number twice) or requires the compiler to have deep knowledge of the standard library.

Similarly, C# has TryGet where in Java, you need a containsKey/get combo, or have to assume your collections do not store nulls.

I do think C# could do better, though. Neither C# nor Java have the equivalent of "insert ... on duplicate key ..." for collections. You now have to do:

   items.TryGet( key, out value);
   items[key] = value + 1;
In C++, that would just be:

   items[key] += 1;
Post reply on HN