
Why I Like The Verbosity of Java - fogus
http://techblog.bozho.net/?p=742
======
abarringer
This line of thought from the 2000's

PHP was very easy to use.... So I didn’t bother to understand the underlying
mechanics. Java forced me to.

Same line of thought circa 1996

"Java was very easy to use.... So I didn’t bother to understand the underlying
mechanics. C forced me to."

Same line of thought circa 1990

"C was very easy to use.... So I didn’t bother to understand the underlying
mechanics. Assembler forced me to."

Abstraction layers are not the problem, however understanding what do to when
they start leaking is the solution.

[http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...](http://www.joelonsoftware.com/articles/LeakyAbstractions.html)

------
floppydisk
When I write code, I want to solve a problem, not write a book--that's what
documentation is for.

Whenever I code in Java, I always feel the language ends up working against
me. To get from point A --> point B, the end result usually consists of having
traveled through points C and D as well as having written a corpus of code
whose length might rival that of War and Peace -- when working on a major
project. Writing similar code in other languages, my LOC clock in at a
fraction of the Java code. Personally, I've found the less LOC I have to deal
with, the easier project maintenance gets, but that could just be me.

~~~
bozho
And I always prefer self-documenting code. Because no one bothers to write or
update documentation

~~~
floppydisk
I don't think the practice of self documenting code limits itself to Java. If
I choose descriptive names for my files, functions, classes, variables, etc.,
I can still convey the meaning of individual blocks of code and the entire
project regardless of language.

Hopefully the people reading my code would be able to grok that a method
called "openXMLConfigFile" exists to open the XML config file and all the code
contained within does just that, hopefully.

------
jiggy2011
A few things that annoy me about Java:

Lack of an echo keyword. When I don't want to use the debugger but just print
a few things to console, System.out.println("x = " + x) is a real mouthfull.

Exceptions: I end up with too many layers of indentation sometimes because of
exceptions that I know will never be thrown anyway.

For example let's say you want to SHA1 hash something, you have a
NoSuchAlgorithmException incase you are running on a JVM without a SHA1 hash
function, which is something I know will _never_ happen with my program.

------
PaulHoule
Yikes.

I'll be leaving PHP as soon as PHP gets "Unicode Support".

The thing I hate the most about Java is that 2/3 of the time a junior
programmer will write the wrong incantation when they open files, so Unicode
characters will get scrambled. This gets missed by
TimewastingDogmaticDevelopers (TDD) because they never write JUnit tests that
read real files because they're too busy making mock objects. Instead, this
problem gets discovered weeks or months after the fact.

I've never had Perl or PHP apps double-encode text that gets written to the
database, but now it's on my checklist to check for double encoding whenever I
smell a "bad smell" named Java.

------
mebassett
While I can appreciate the author's experience - that learning lower-level
technology gives on a great appreciation for the full stack and an ability to
deal with leaky abstraction - I think he gets confused when he ties the lower-
level implementation he's discovering with java's verbosity.

C is a lower level language that exposes a lot of stuff that's hidden in Java,
but I've not read much C source code that makes me think it's too verbose. My
experience with Java has contained far too many
AbstractErrorCorrectingModalDialogueFactory classes for me to enjoy using it.

~~~
bozho
I agree the naming conventions / practices also contribute to the verbosity,
but you would name the AbstractErrorCorrectingModalDialogueFactory the same
way in any OOP language, if this name describes it best.

~~~
mebassett
I don't mean to get into a language war here. the point here isn't that bad
names make java into a poor language. My point is that the lower-level details
the author is seeing are not due to java's verbosity. They're due to java
being a lower level language than php.

though to respond to your assertion, I actually think @floppydisk got to my
point in a much quicker manner than I could. I don't think I'd need to express
such a thing in a more expressive language. I'm not talking about the naming
convention, I'm talking about how Java forces you into a version of OOP that
requires you to use a litany of "design patterns" get anything done. A more
expressive language would be able to capture the same idea without the litany
of java classes, interfaces, and generics that come with java.

------
samirahmed
I agree with the argument that more detail is conveyed in its verbosity.

But I fail to understand how type inference (like that seen in Scala, C#
etc... doesn't clean up the verbose)

for example,

    
    
        HashMap<String,ArrayList<String>> map =  new HashMap<String,ArrayList<String>> (); 
    

versus

    
    
         val map = new HashMap<String,ArrayList<String>> ();
    
    

The latter conveys just as much information

~~~
MatthewPhillips
Yes but

    
    
      val map = GetMap();
    

does not.

~~~
samirahmed
As the programmer, you wouldn't call getMap if you didn't know the return type

As the reader, this situation would be analogous to looking up the what map
is, assuming it was declared earlier ... is a datamember etc. something that
might as well arise when typing..

    
    
         private HashMap<Integer, String> map ;
    

then 30 lines later

    
    
         this.map = getMap();
    
    

You would have to check javadocs or function header some time

------
jinushaun
If I wanted to see how everything works, why would I need the abstraction of a
higher level language? Why not just code in direct assembly? Abstraction has a
value and I think it's a waste of time that it takes so much boilerplate code
to do _routine_ things in Java.

------
dchest
You don't need the verbosity of Java to get good I/O or to understand how
servers work. See: Go.

------
petrichor
after doing some ruby work recently which required reading a lot of
undocumented code that could have used some major refactoring, i really began
to appreciate java's verbosity. even the most poorly written java leaves
behind tons of clues as to what is happening. with ruby, if there is no
documentation and no tests, you're SOL.

that said, there are still tons of things about java that really get on my
nerves...

