Verbosity is not Java’s fault

The call to action is worth pondering. Can Java's verbosity be eliminated? Maybe not. Can Java programs be made to be less verbose through better design? Yes!

It isn't the author's fault, but reading articles like this make me feel like Java supporters want it both ways. They point to Java's tooling and vast herds of libraries as benefits, but when you point out flaws in some implementation they say the language isn't the fault, it's that particular library.

On the other side, when criticizing languages like Ruby they are quick to point to practices like monkey-patching as examples of how Ruby permits abuse in practice.

Well, which is it? Do we compare languages on the basis of the actual libraries and programs people write? Or do we compare them on the basis of the libraries and programs they could write if they took advantage of the language's features and also had a keen sense of design?

Clojure code uses the same APIs all the time, but manages to be much shorter.

Java's verbose APIs are Java's fault, because Java doesn't provide metaprogramming tools to make the boilerplate go away.

It is, to some extent, Java's 'fault' although it's fuel for endless flamage how much that is a fault.

Some stuff is just plain verbose, in part due to lack of type inference -

  EndlessParametrizedType foo = new EndlessParametrizedType()

As to the APIs, some of it is due to excessively baroque APIs. But even with a well-designed API, in order to provide a reasonable amount of flexible functionality, a lot of the internal structure of the implementation is often exposed so it can be accessed. This is a consequence of static typing - in a dynamic language, you're more likely to just reach into the bowels of an object and pull out, change or replace bits you want. This isn't an option in Java and a flexible API ends up being a composition of a lot of smaller APIs. In the standard library, it's often left to others to provide a simple layer on top that covers the base cases - for instance, Apache Commons mail for Java Mail.

This post has quite possibly the worst name ever. I mean really: who cares whose fault Java's verbosity is? I think it obscures the author's true intent: to show that Java could be made much less verbose given a less verbose standard library.

Note: I'm not necessarily saying that I agree with the author.

Lies. Java is intrinsically verbose. Say I want to make a class with a read-only attribute "Foo".

CLOS:

   (defclass class () ((foo :reader get-foo :initarg :foo)))

Moose:

   class Class {
       has 'foo' => ( is => 'ro' );
   }

Java:

   class Class {
       private String foo;

       public Class(String foo) { // named initargs are clearly for losers
           this.foo = foo;
       }
   };

Notice how a common high-level task requires a manual error-prone implementation, every single time. Java provides only the concepts of "class", "field" and "constructor", while the other languages provide the high-level concept of an "attribute", which is what the programmer actually wants. (The first concept is easy for the language implementor, the second concept is easy for the practicing programmer.)

I should also point out how the verbosity exists only for the sake of being verbose, not for creating more reliable software. Perl and CLOS assume I want named initargs, making use of my class self-documenting:

   (make-instance 'class :foo 42 :bar 123)

   Class->new( foo => 42, bar => 123)

That's verbose, but it makes the code very easy to read and write. No guessing about what slot is being set to what value.

With Java, though, it's anyone's guess as to what's going on:

   new Class(42, 123);

The only way to know which field gets set to which value is to Read The Fine Source:

   public Class(int bar, int foo){
      this.foo = bar;
      this.bar = foo;
      System.Utils.delete_users_pr0n_stash();
   }

foo does get set to 42, but only by accident... and there are unexpected side effects.

So much less typing though! cough.

Another common programming pattern is reusing code. (I hear people like doing that.) Say you have classes representing numbers, and you want to add a "not equals" method to each type. That's easy, you can just write a generic role like:

    role Eq {
        requires 'equal';
        method not_equal($a: $b){
            return !$a->equal($b);
        }
    }

Then I can easily reuse that extremely-complex "not_equal" method:

    class Int with Eq {
        has value => ( is => 'ro', required => 1 );
        method equals($a: $b){
            return $a->value == $b->value;
        }
    }

   Int->new( value => 42 )->not_equals( Int->new( value => 123 ) ); # True

In Java, I can still maintain a similar interface:

   interface Eq {
       public bool equal(Eq that);  // Eq is not really the type I want, but whatever.
       public bool not_equal(Eq that);
   }

But the implementation can't be shared:

   class Int implements Eq {
       private int value;
       public Int(int value){ // didn't we just say "int value" like one line ago?
           this.value = value;
       }

       public bool equal(Int that){
           return this.value == that.value;
       }

       public bool not_equal(Int that){
           return !this.equal(that);
       }
   }

This is both verbose and error-prone. (I will also point out that Java calls Eq "Comparable" and uses the "implements" keyword instead of "with". But this is petty. I'm surprised they were happy with "implements" and didn't choose the clearer expression "implementsTheInterfaceThatIAmAboutToTypeRightAfterIAmDoneTypingThis". Your editor can type that for you, after all...)

But wait, we can use the strategy pattern to save us!

   class NotEqualStrategy {
       public bool not_equal(Eq a, Eq b){
           return !a.equal(b);
       }
   }

   class Int {
       private NotEqualStrategy not_equal_strategy;
       private value;

       public Int(NotEqualStrategy nes, int value){
           this.not_equal_strategy = new;
           this.value = value;
       }

       public bool equal(Int that){
           return this.value == that.value;
       }

       public bool not_equal(Int that){
           return not_equal_strategy.not_equal(this, that);
       }
   }

At least I don't have to cut-n-paste the logic anymore, but it's still very verbose. Imagine you had to delegate more than one method -- you can do it, but it involves a ton of meaningless code.

In Perl, I can just say:

   class NotEqualsStrategy {
       method not_equal(Eq $a, Eq $b){
           return !$a->equal($b);
       }
   }

   class Int {
      has 'not_equals_strategy' => (
          is       => 'ro',
          isa      => 'NotEqualStrategy',
          required => 1,
          handles  => ['not_equal'],
      );

      has 'value' => ( is => 'ro' );

      method equal(Int $a: Int $b){
          $a->value == $b->value;
      }
   }

Notice how I didn't have to type the cut-n-paste delegation; the language did it for me. I didn't have to type it, I don't have to look at it, and I can't accidentally fuck it up. That's what programming languages are supposed to do for you, and that's what Java doesn't do.

In conclusion, Java is verbose, and verbosity is harmful.

Conveniently ignoring the fact that Java, by default, includes lots and lots of unnecessarily verbose APIs, and in many cases you're stuck using them - then yes, verbosity is not Java's fault.

Response myResponse = new Response();

ResponseType myResponseType = responseTypeFactory.CreateNewDisagreementResponseType();

responseManger.SetResponseType(myResponse, myResponseType);

return myResponse;

True. Most of the time I end up making a very thing wrapper over the original API, just for the sake of brevity. I honestly thought that's what I was meant to do: the API should be optimized for power, and the local wrapper for usability in the local context.

But it's also a matter of style. I just wrote a function the other day to do the equivalent of:

    Map m = makeMap( "key1",  "value1",
                     "key2",  "value2", 
                     "key3",  "value3" );

It's perfectly ok to write something like this in java using varargs, but because of ... I don't really know, habituation I guess, it took me learning Clojure to actually think of writing it.

These attempts to deny the obvious are so futile. The lack of object literals, list comprehensions, parameter default values, keyword parameters, generators (yield), first class functions, property syntax, type inference, macros, etc clearly make Java exceptionally verbose.

The author's argument seems to be that Java the language cannot possibly be criticised for being verbose as the verboseness of the language clearly pales in comparison to its outrageously verbose APIs. Not a good line of defense in my view.

Of course it's Java's fault ... sure, you can design clean and easy-to-use APIs but it takes a considerable amount of effort and Java doesn't help you.

I simply don't get some of its design choices ... operator overloading is not harmful if implemented right, checked exceptions were a bad idea, and why can't it have local type inference or proper closures and why can't developers define their own stack-allocated primitives? Where these really that hard or dangerous to blend in?

Interesting points on library design to do the heavy lifting (especially the HTML document regular expression example). Still, the main point of the article is not right: Scala is much more concise than Java (as is Clojure). Article was worth reading however.

Isn't it the case, that most places will require an application in java and with most people knowing only the official API, noone will write code for some custom one that is company-specific? IMO yes - it is Java's official API, it is Java's fault.

Bad programmers create real verbosity. Language choice is largely irrelevant to that.

And by verbosity I mean real verbosity. Not the ill advised measure of 'lines of code' or 'tokens'.

A good programmer can write extremely concise well written Java.

Don't waste too much time on this sort of fluff, or chasing the next 'hot' language. Spend it learning how to become a better programmer.

I'd say the main reason Java is wrongly associated with verbosity is two things - It's widely used in corporate environments, where people are taught to do things inefficiently and in the most number of lines possible, and secondly, the use of IDEs, leading to lots of verbose automatically generated crappy code.