Comment by lsd5you | Hacker News Reader

Comment by lsd5you | Hacker News Reader

Parent Full thread

I would say some people don't want to get it. There are plenty of toy languages and interactive calculators such as logo and which allow simple definitions of functions similar to the 'ideal' given. However noone would suggest writing complex software using logo.

I'm not going to defend every last aspect of Java, but in practice verbosity and readability are not it's biggest issues. In practice Java is pretty maintainable and quick to write.

To address this strawman directly. The first and last line of the 'dreck' are the namespace, which is missing in the top function. I think it is entirely fair to omit namespace and access modifiers. Probably there needs to be <T extends Summable> or some such (ignoring a number of issues with the approach here), but then this could be put in the class declaration at the top for reuse in more than one function. Which would leave

static T Sum(T x, T y) { return x.add(y); }

Which is what it is ...

>but in practice verbosity and readability are not it's biggest issues.

Right. It's biggest issue is inconsistency. Int or int? Equals or ==? Why can class String overload the + operator but I can't? On and on. But Java is very verbose. It's not a big issue in practice because we have IDEs that write most of the endless boilerplate for us.

Actually the == comparison is VERY consistent. == will return true only if the values are identical--in the case of primitives, this means the ints or doubles are identical, and in the case of objects it means the pointers have identical values--meaning they point to the exact same object. But this way I know that if I want to do something like change the way things stored in sets, I have to modify equals(), since that's what maps and sets use to check equality.

Strings are only allowed to use + because strings were traditionally seen as primitive types, rather than the objects they are in Java. It's a small inconsistency, but more of a concession to existing practice.

I'm not sure what else the "on and on" refers to...

Consistency really isn't that big an issue, the remarked points are really just details. (Of course in Javascript the use of == really is an issue).

The concept of equals is not as pure as it would like to be but it is not clear what can be done about this, since it is very convenient to have and it is not necessarily the case that there should be a universal concept of equality between all objects (although in practice this is only infrequently an issue in well designed code).

Java is quick to write because of the excellent IDEs out there. Typing out the full structure of a simple pojo by oneself makes one wonder why.

Reply on news.ycombinator.com