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

31–40 of 182 posts

Re: Everything about Java 8

#31

Post by pcote »

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…

>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 the way, you actually can accidentally alter attributes in the calling and callee objects if you aren't careful.

Re: Everything about Java 8

#32

Post by smackfu »

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.

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

Re: Everything about Java 8

#33

Post by aardvark179 »

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…

Give the desire for lambdas to enable more simple concurrent programming, and the added complexity mutating the external variables in the implementation, I think they made the right choice.

If you _really_ have to mutate those variables then put them into a final array, and alter the entries in that, the same can be used if you need to do an effective pass by reference.

Re: Everything about Java 8

#34

Post by rallison »

volkadav wrote: post #28
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…

We actually evaluated Lombok for this reason (and others), and eventually decided against continuing with it for a few reasons:

* Every team member must install the eclipse plugin (which, if you already have any eclipse vm args set, also requires you to add a couple of extra arguments).

* No reasonable way to add javadoc comments to getters and setters without explicitly writing those getters and setters (kind of defeating the purpose of lombok).

* Sonar (which we use for static code analysis) will now report those private fields as a major warning as it thinks they are unused private fields. You can make those warning go away by adding //NOSONAR on each line, but yeah..

* Relies on internal java APIs. While the authors seem to be quite good and stay on top of things, I fear that this is still inviting issues down the road.

We felt that the cons outweighed the pros in this case, despite some of the beauty in lombok.

Disclaimer: I am a colleague of the author of the linked article.

Re: Everything about Java 8

#35

Post by kainsavage »

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.

I think it gets even easier than that since stream/parallel are the basic calls:

  collection.parallel().map(operation1).reduce(operation2);

Re: Everything about Java 8

#36

Post by microtonal »

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?

- A class can only inherit from one abstract class, but can implement multiple interfaces.

- An interface cannot have member variables.

Re: Everything about Java 8

#37

Post by stelonix »

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.

I disagree wholeheartedly: the verbosity caused by a lack of such an 'irrelevant' feature makes my eyes bleed.

It doesn't really matter, some people see classes/objects as a minor feature too. I agree with him: operator overloading is not a minor feature and it's probably one of the reasons I am not very fond of Java.

Re: Everything about Java 8

#38

Post by kbenson »

swift wrote: post #21
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…

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

Re: Everything about Java 8

#39

Post by masklinn »

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.

> Just a minor little feature that most people would use only occasionally in their objects.

Yeah until you have to work with java's Bignums one day, then you start wanting to choke people to death.

Re: Everything about Java 8

#40

Post by RyanZAG »

Massive issue here for many when it comes to Java 8 - what about Android ?

Android's dalvik is based off of Apache Harmony, which doesn't appear to be updating anymore. Does this mean no Java 8 for Android/Dalvik? Seems like it would be a major issue if so.

Post reply on HN