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

91–100 of 182 posts

Re: Everything about Java 8

#91

Post by ethzero »

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.

It's not an identical capability. Scala doesn't technically have operator overloading, it has symbolic method names and operator syntax for methods. This means you can use any valid name as an operator.

With C++, you can only overload the built-in symbolic operators. This means instead of choosing the best symbolic name to use as an operator you're forced to re-purpose some built-in operator like "<<". In Scala you can pick any name or symbol you want.

Re: Everything about Java 8

#93

Post by Chris_Newton »

amouat wrote: post #86
Chris_Newton wrote: post #71

Earlier quoted context omitted.

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

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 unchanged. Both behaviours can be useful. Both are widely used in libraries, with those exact function names. You just have to read the documentation and learn how each library you use works, which is particularly... entertaining... if your project uses multiple libraries and they don’t all follow the same convention.

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.

Edit: I did take a look at the article you cited. It appears to be an elaborate troll, actually consisting of little more than a set of unlikely examples (I wouldn’t write a function called divide() to “divide” two matrices, so why would I suddenly feel the urge to write a / operator?), a set of assertions without proof (some of which are just begging the question), and a final ad hominem that conveniently discards one of the most obvious demonstrations that operator overloading can be useful on the basis that anyone making that argument just doesn’t understand (and ignores counterexamples like OCaml, where basic arithmetic operators really are different for basic numerical types, which is a significant pain point in the language).

Re: Everything about Java 8

#94

Post by mbell »

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…

> Getters and setters, C# style. That is, instead of

I just stopped using getters and setters all together unless I have a real use for them. The most common reasons are: because they are required by some third party library or they are the external interface for whatever the module of code is doing. For all internal classes, if the field needs external access, just make it public.

Most of the arguments I hear for using getters and setters are the result of the tendency in the Java world to over engineer everything. e.g. "What if you want to change the internal name in 8 months? or add validation years from now? or add some logic to the getter? (ignoring the fact that would no longer make it much of a 'getter')"

The only argument that holds water with me for using getters/setters everywhere, because it is actually painful, is mocking field values, but there are ways around that and the trade off in code readability with public fields is well worth it.

Re: Everything about Java 8

#95

Post by mercurial »

mbell wrote: post #94
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…

> Getters and setters, C# style. That is, instead of I just stopped using getters and setters all together unless I have a real use for them. The most common reasons are: because they are required by some third party library or they are the external interface for whatever the module of code is doing. For all internal classes, if the field needs external access, just make it public. Most of the arguments I hear for us…

With dependency injection frameworks, you don't really need setters anyway. I add getters only as needed, unless it's a public API.

Re: Everything about Java 8

#96

Post by y0ghur7_xxx »

amouat wrote: post #86
Chris_Newton wrote: post #71

Earlier quoted context omitted.

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

>> natural syntax like a+bc 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.

Re: Everything about Java 8

#97

Post by mercurial »

Someone wrote: post #90
gjulianm wrote: post #76

Earlier quoted context omitted.

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

You could have a method returning a nullable Integer.

Re: Everything about Java 8

#98

Post by mercurial »

ethzero wrote: post #91
tragomaskhalos wrote: post #77

Earlier quoted context omitted.

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.

It's not an identical capability. Scala doesn't technically have operator overloading, it has symbolic method names and operator syntax for methods. This means you can use any valid name as an operator. With C++, you can only overload the built-in symbolic operators. This means instead of choosing the best symbolic name to use as an operator you're forced to re-purpose some built-in operator like "<<". In Scala you c…

Same with Haskell, which makes it compact but not always very readable (it effectively turns many libraries into their own non-intuitive DSL).

Re: Everything about Java 8

#99

Post by pootch »

Well, this is all nice, except that the JVM cant run with a heap more than 8GB without huge GC pauses.

It really doesnt matter what java can do . The JVM is broken and is basically a DOS runtime circa 2013.

Re: Everything about Java 8

#100

Post by mercurial »

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…

What I'm missing the most from C# is actually the "var" keyword.
Post reply on HN