Often when reading a forum discussion somewhere about the verbosity of Java and conciseness of some language X we meet people trying to convince us that Java is good as it is, because “I want to express everything clearly, and when reading I want to see what I get. No crypticts, no implicits”.
And when debating about that opinion, it often comes to productivity, which is then answered with the hint to “good IDEs”, so that Java expressions are typed almost as fast as code in more concise languages.
So what is this thing about expressiveness and conciseness?
Let’s have a look at other formal languages, say: mathematics.
Imagine the following term: 5*4*3*2*1
This is more than a chain of multiplications. It is a chain of multiplications starting from a given number (here: 5) counted down to 1 with stepwidth 1. And this concept has a specific name: faculty.
So “faculty” is an unambiguous, single word for the concept descibed above in more verbose words.
Likewise in symbolic language, you write this concept as: 5! (say: five faculty)
That this symbol is far better than the multiplication expression, can be easily seen when trying to write 100! in long form.
Now consider writing mathematical formulas without the symbolic abstraction of faculty, always only expressing it as multiplication chain. You can argue, that you can easily grok the pattern 5*4*3*2*1 as being faculty by reflex. But be cautious. Could you really always and immediately say, that it is faculty five?
Or isn’t it too easy to mistake it with 5*4*3+2*1 (as typo when writing, but more often when reading it in a more complex context)? Here you have a pattern-mismatch mistake.
The same now works for programming languages. When saying, that one wants to “express everything clearly”, it seems natural to write:
public static final
Indeed, it could be abbreviated to omit typing and “verbosity”, e.g. to:
pub sta fin
Easier to write, only slightly more cryptic to read.
Much more concise would it be, when we would introduce symbols, such leading to a more formal symbolic language.
Imagine + for public, ^ for static, _ for final, then the modifier chain above could be: +^_
Write this on a paper and read it three days later. You remember what the symbols mean?
So: Symbols are much more concise, perhaps even more precise, but maybe more cryptic for a reader, especially when trying to learn a language. You must not only learn the concepts behind public, static and final, but also their symbols.
But here it comes. The muttering about Java being to verbose is not about abbreviations or introduction of symbols. It is much more about abstraction of concepts.
Look: Combination of symbols construct patterns. And such patterns express more abstract
So when seeing the above pattern (+^_) you can immediately think of it as a “word” with unknown letters, and understand it as the concept “constant”.
And here we are! Faculty is a higher order concept, compiled and expressed by lower level terms. Always using the lower level constructs (the “How-to”) instead of the concept is not as easily grokkable like having a symbol for the concept itsself.
Likewise, when reading public static final in Java, you always have the effort to transform it to the implicit higher order concept of “constant”, much easier expressable by, for example: const .
This is what this verbose vs. concise debate is all about.
Could you imagine to write always “Small house with big entrance to shelter cars” instead of “garage”?
That’s what Java obliges you to do. And regarding IDE support: I do not believe you really want to advise a template+shortcut enabled word processor as the best solution to write texts, instead of creating better words for things.
In the end, Java expressions are not napkin-able, and are not suited for whiteboard development.
I’ve seen very different mail forum posts about this or that algorithm, and it was always PITA to read Java code out of an email, perhaps wrapped at 80 characters.
Not so in really expressive languages!
Coming back to the pattern mismatch mistake above:
I detected this problem when I refactored a good bunch of code from Java pre-5 while loops to the Java 5 foreach loop. In many many cases it was easy to exchange the loops. But I detected more than one place, where the loop construct was slightly different, and replacement did not work.
The point is: I was not aware of this differences, because browsing over the code, all loops seemed equally expressing the standard iteration concept of get iterator, while hasNext, elem = next.
Only the refactoring revealed the locations where the looping concept indeed differed.
Expressive? Or truth hidden by word flood?
So when talking about Java’s verbosity and new concepts for Java 7 or 8 or whatever, first remember the faculty example and cogitate if the new ideas don’t express abstract concepts more explicitly and thus clearer than the verbose forms, you considered being more “clear and directly” before.