Hacker News Reader

Comment by zkhalique | Hacker News Reader

The language itself is verbose. Instead of overloading operators, for instance, the convention is to have longer method names.

View on HN

Of all the verbose aspects of Java that you could complain about (getters/setters, checked exceptions, no automatic casting or type inference...) you had to pick operator overloading?!?

Coming from a C++ background, I consider Java's policy on operator overloading to be positively enlightened. There's plenty to complain about in the language, but this isn't one of them. I don't want to program in an ascii-art language.

thanks for this. I always have to hold myself back when one of the worst language features is being seen as something positive. Now I feel I don't have to rant.

That is part of why I am currently trying out Kotlin. It is essentially Java with the pain points taken out: non-nullable references, simpler advanced generics, lambdas, classes are final by default as are methods, interfaces can have default implementations of methods, semicolons are optional, fields are removed in favour of properties, etc.

If you want to play with it it is pretty simple to install it in the community (free) version of Intellij and marginally more difficult use without an IDE (you can get the compiler for the command line if you want). It is interoperable with Java so i recommend you try porting one of your existing classes (IntelliJ is supposed to be able to do that for you, but I haven't tried that so far).

Seconded. +1 on Kotlin. I am a really big fan.

It's always a tradeoff. The language is verbose in some places due to legacy commitments. In other places (i.e. compared to dynamically/gradually typed languages), it's to make sure the compiler does work for you. In others (like in the case of operator overloads), there are predictability benefits to only allowing predefined effects from core language features, and building everything on top of those, rather than meta-programming with them.

But that's the point: convention is a product of the community. You don't need operator overloading to design classes with shorter method names.

In many cases, the community starts with something that looks like a languages standard library. And Java's is very verbose, so it makes sense that the community would have verbose method names as well.

However, while I can see it taking some getting used to if one comes from a different background, I personally find Java to be nicely self-documenting when using the conventions on display in the standard libraries. Lines are long and sometimes a statement spans multiple, but in many Java libs/apps things do exactly what they're named.

That's convention, the language doesn't prohibit you from overloading. Also, Java is not significantly more verbose than C#.

Read again, operator overloading, not function overloading.

My experience has been that in practice, Java is much more verbose than C#, mainly due to C#'s compact getters and setters, LINQ, and operator overloading.

https://projectlombok.org/ eliminates getters & setters; LINQ and operator overloading I happily live without. The main disadvantage to Java is checked exceptions, but it's possible to avoid them for the most part. Having rewritten some C# code in Java recently, the result was not significantly more or less verbose.

That said, badly written code will suck in either language.

You can do operator overloading, you just have to extend it [1].

[1] https://github.com/amelentev/java-oo

sigh

Reply on news.ycombinator.com