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

21–30 of 182 posts

Re: Everything about Java 8

#21

Post by swift »

stack0v3erfl0w wrote: post #9

I recently started developing in Java and the thing I find most irritating is the lack of operators overload.

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 of operator overloads, you have to be very conservative about writing generic code that uses the operator.

Given these limitations, and the fact that most languages have relatively few built-in operators to choose from, I find that just operator overloading isn't enough. You really want the ability to define new operators as well. That's something Java (and C#, and C++, and many other languages) would really benefit from.

Re: Everything about Java 8

#22

Post by spartango »

Woah, that streaming abstraction looks really slick, especially given that it can be automatically parallelized.

The idea of doing a one-line parallel map-reduce that is

    collection.stream().parallel().map(operation1).reduce(operation2);
is surprisingly cool imo. And the availability of streams across the collections framework allows that they can be used in routine programming.

Re: Everything about Java 8

#23

Post by mikeash »

pcote wrote: post #11
stack0v3erfl0w wrote: post #9

I recently started developing in Java and the thing I find most irritating is the lack of operators overload.

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

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 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. For this, it's great. There's no particular reason the types built-in to the language should get special treatment for operators, as long as programmers can resist the temptation to be idiots.

Re: Everything about Java 8

#24

Post by gjulianm »

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.

Absolutely agree with you. I haven't seen yet a real reason to avoid including operator overloading in any language.

Re: Everything about Java 8

#25

Post by swift »

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.

Re: Everything about Java 8

#26

Post by rallison »

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…

The boilerplate getters and setters in java do get old very quickly, and C#'s properties handle this nicely. On the surface, it seems like something minor and superficial, but when you are seeing the unnecessary verbosity of getters and setters day in and day out, it becomes frustrating not to have something like C#'s properties.

I definitely would like to see a similar feature in java. In the meantime, I am pleased with the features in java 8 after being underwhelmed by java 7's new features.

Re: Everything about Java 8

#27

Post by eranation »

spartango wrote: post #22

Woah, that streaming abstraction looks really slick, especially given that it can be automatically parallelized. The idea of doing a one-line parallel map-reduce that is collection.stream().parallel().map(operation1).reduce(operation2); is surprisingly cool imo. And the availability of streams across the collections framework allows that they can be used in routine programming.

Yep, Java 8 starts to look a lot like Scala

Re: Everything about Java 8

#28

Post by volkadav »

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…

You might like project lombok re: getters and setters. It has a feature that implements this using annotations. True, this is an additional external dependency for a project when it'd be nice if it was a core language feature, but as external deps go it isn't a killer one -- the library is not huge and doesn't spiderweb out to a bunch of other deps.

http://projectlombok.org/features/GetterSetter.html

(There's also a lombok-pg project that offers more extensions.)

Re: Everything about Java 8

#29

Post by stelonix »

mikeash wrote: post #23
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".

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++ libraries that make use of operator overloading.

Re: Everything about Java 8

#30

Post by pfalls »

spartango wrote: post #22

Woah, that streaming abstraction looks really slick, especially given that it can be automatically parallelized. The idea of doing a one-line parallel map-reduce that is collection.stream().parallel().map(operation1).reduce(operation2); is surprisingly cool imo. And the availability of streams across the collections framework allows that they can be used in routine programming.

All I ever heard about with Java 8 was lambdas (which is understandably the big name new feature), but streams, in my opinion, are just as exciting. Unlike lambdas and they're new syntax, streams seem like something any developer can quickly pick up and start taking advantage of.
Post reply on HN