4 ms·

As long as java doesn't support aliasing (ie: import com.tool.foo.Bar as FooBar) , its gonna be very hard to tackle the extreme verbosity java results in.

by kapv89 13y ago

twic 13y ago
As a working Java programmer, I wouldn't have said that this was the main source of verbosity in Java. Could you perhaps expand on how this results in verbosity? Perhaps an example of some code in Java as it exists now, and a less verbose version of the code in a hypothetical Java-with-aliasing.
- thescrewdriver 13y ago
  I also don't see that as the primary source of verbosity in Java. In Scala I can do: import com.foo.bar.{Bar => FooBar} But that's mostly just useful for dealing with cases where you have to deal with classes with the same name in different packages. The verbosity in Java comes from a lack of type inference, lack of first-class properties (get/set naming convention doesn't count), and a whole basket of other missing features. Another large contributor to Java verbosity is sadly the the Java culture of over-engineering and resistance to change which has built up over the years (the latter partly in response to the glacial evolution of Java in the last decade).
grej 13y ago
Yeah I have to agree with twic on this one. Aliasing is nice no doubt, but any modern java IDE organizes imports pretty well for you.
iopq 13y ago
The verbosity of Java is because you have to take care of stupid low level details. All kinds of buffered readers, loops, internal class state juggling, etc. There is no support for first class functions, despite them tacking lambdas on awkwardly.
- Roboprog 13y ago
  E.g. - I personally prefer unchecked exceptions to error codes, but otherwise, compare C's "#include <stdio.h>" to Java's "import java.io....;". (markdown won't let me put in a star here for some reason) The FILE * type is so much more compact an interface than the zoo in the Java io package. Select an appropriate fopen/popen "factory method call", and off you go. Regarding exception types, the Java libs have too many exception types you either must catch in the wrong place, or redeclare as thrown, rather than how C# does it with unchecked exceptions.

As long as java doesn't support aliasing (ie: import com.tool.foo.Bar as FooBar) , its gonna be very hard to tackle the extreme verbosity java results in.

by kapv89 13y ago

As long as java doesn't support aliasing (ie: import com.tool.foo.Bar as FooBar) , its gonna be very hard to tackle the extreme verbosity java results in.

twic 13y ago

As a working Java programmer, I wouldn't have said that this was the main source of verbosity in Java. Could you perhaps expand on how this results in verbosity? Perhaps an example of some code in Java as it exists now, and a less verbose version of the code in a hypothetical Java-with-aliasing.

thescrewdriver 13y ago
I also don't see that as the primary source of verbosity in Java. In Scala I can do: import com.foo.bar.{Bar => FooBar} But that's mostly just useful for dealing with cases where you have to deal with classes with the same name in different packages. The verbosity in Java comes from a lack of type inference, lack of first-class properties (get/set naming convention doesn't count), and a whole basket of other missing features. Another large contributor to Java verbosity is sadly the the Java culture of over-engineering and resistance to change which has built up over the years (the latter partly in response to the glacial evolution of Java in the last decade).

grej 13y ago

Yeah I have to agree with twic on this one. Aliasing is nice no doubt, but any modern java IDE organizes imports pretty well for you.

iopq 13y ago

The verbosity of Java is because you have to take care of stupid low level details. All kinds of buffered readers, loops, internal class state juggling, etc. There is no support for first class functions, despite them tacking lambdas on awkwardly.

Roboprog 13y ago
E.g. - I personally prefer unchecked exceptions to error codes, but otherwise, compare C's "#include <stdio.h>" to Java's "import java.io....;". (markdown won't let me put in a star here for some reason) The FILE * type is so much more compact an interface than the zoo in the Java io package. Select an appropriate fopen/popen "factory method call", and off you go. Regarding exception types, the Java libs have too many exception types you either must catch in the wrong place, or redeclare as thrown, rather than how C# does it with unchecked exceptions.