4 ms·

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

abalone 11y ago
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.
- deleted 11y ago
  [deleted]
  - hdctambien 11y ago
    operator overloading means changing what + or * do. Ie, overloading the * operator for a Matrix class so you could do this: Matrix a = new Matrix(); Matrix b = new Matrix(); Matrix c = a * b; That is different than function overloading, which you are referencing.
- dikaiosune 11y ago
  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.
Delmania 11y ago
That's convention, the language doesn't prohibit you from overloading. Also, Java is not significantly more verbose than C#.
- Too 11y ago
  Read again, operator overloading, not function overloading.
- jimrandomh 11y ago
  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.
  - stickfigure 11y ago
    https://projectlombok.org/ 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.
stickfigure 11y ago
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.
- hippiefahrzeug 11y ago
  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.
dikaiosune 11y ago
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.
infinitone 11y ago
You can do operator overloading, you just have to extend it [1]. [1] https://github.com/amelentev/java-oo https://github.com/amelentev/java-oo
tomjen3 11y ago
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).
- mahmoudimus 11y ago
  Seconded. +1 on Kotlin. I am a really big fan.
peterashford 11y ago
sigh

abalone 11y ago

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.

deleted 11y ago
[deleted]
- hdctambien 11y ago
  operator overloading means changing what + or * do. Ie, overloading the * operator for a Matrix class so you could do this: Matrix a = new Matrix(); Matrix b = new Matrix(); Matrix c = a * b; That is different than function overloading, which you are referencing.
dikaiosune 11y ago
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.

Delmania 11y ago

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

Too 11y ago
Read again, operator overloading, not function overloading.
jimrandomh 11y ago
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.
- stickfigure 11y ago
  https://projectlombok.org/ 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.

stickfigure 11y ago

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.

hippiefahrzeug 11y ago
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.

dikaiosune 11y ago

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.

infinitone 11y ago

You can do operator overloading, you just have to extend it [1]. [1] https://github.com/amelentev/java-oo https://github.com/amelentev/java-oo

tomjen3 11y ago

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

mahmoudimus 11y ago
Seconded. +1 on Kotlin. I am a really big fan.

peterashford 11y ago

sigh