Java is too verbose! Who didn’t stumble on such a rant on the Internet previously? And the guy bragging about [Insert expressive language there], that which soon replace Java because it is much more concise: it can replace those 10 lines of Java code with a one-liner. Ah, the power!
Unfortunately, in order to correlate conciseness with power (and verbosity with lack of power), those people take many shortcuts that once put into perspective make no sense at all. This article aims to surgically deconstruct such shortcuts to expose their weaknesses. And because I like a factual debate - and because there are not only trolls on the Internet, this post will be linked to Andy Petrella’s different point of view.
Verbose is not bad
Having more data than necessary prevents messages corruption by indirect communication. Here are two simple but accurate examples:
- In network engineering, there’s a concept of DBIt or Delivery Confirmation Bit. It is just a summary of all 0 or 1 of the current sequence and guarantees the delivered packet has been transmitted correctly, despite not-so-adequate network quality.
- In real-life, bank accounts have a 2-digits control key (at least in most European countries I know of). Likewise, it is to avoid wiring funds to a erroneous account.
It’s exactly the same for "verbose" languages; it decreases probability of understanding mistakes.
More concise is not (necessarily) better
Telling that one-liner are better than 10 lines implies that shorter is better: this is sadly not the case.
Let us take a code structure commonly found in Java:
public List<Product> getValidProducts(List<Product> products) {
List<Product> validProducts = new ArrayList<Product>();
for (Product product : products) {
if (product.isValid()) {
validProducts.add(product);
}
}
return validProducts;
}In this case, we have a list of Product and want to filter out invalid ones.
An easy way to reduce verbosity is to set everything on the same line:
public List<Product> getValidProducts(List<Product> products) { List<Product> validProducts = new ArrayList<Product>();
for (Product product : products) { if (product.isValid()) { validProducts.add(product); } } return validProducts;}Not concise enough? Let’s rename our variables and method obfuscated-style:
public List<Product> g(List<Product> s) { List<Product> v = new ArrayList<Product>();
for (Product p : s) { if (p.isValid()) { v.add(p); } } return v;}We drastically reduced our code verbosity - and we coded everything in a single line! Who said Java was too verbose?
Expressiveness implies implicitness
I already wrote previously on the <a title="Dangers of implicitness" dangers of implicitness: those same arguments could be used for programming.
Let us rewrite our previous snippet à la Java 8:
public List<Product> getValidProducts(List<Product> products) {
return products.stream().filter(p -> p.isValid()).collect(Collectors.toList());
}Much more concise and expressive. But it requires, you, me and everybody (sorry, I couldn’t resist) to have a good knowledge of the API. The same goes for Scala operators and so on. And here comes my old friend, the context:
- The
+operator is known to practically everyone on the planet - The
++operator is known to practically every software developer - The Elvis operator is probably known to Groovy developers, but can be inferred and remembered quite easily by most programmers
- While the :/ operator (aka
foldLeft()) requires Scala and FP knowledge
So from top to bottom, the operator requires more and more knowledge thus reducing more and more the number of people being able to read your code.
#Code is read much more often than it is written: code for #readability!
— Nicolas Frankel 🇺🇦🇬🇪 (@nicolas_frankel) September 2, 2013
As you write code to be read, readibility becomes the prime factor in code quality.
Thus, the larger the audience you want to address, the more verbose your code should be. And yes, since you will not use advanced features nor perfect expressiveness, seasoned developers will probably think this is just average code, and you will not be praised for your skills… But ego is not the reason why you code, do you?
Summary
In this article, I tried to prove that Less is more does not apply to programming with these points:
- Verbosity prevents communication mistakes
- Spaces and tabs, though not needed by the compiler/interpreter, do improve readibility
- Expressiveness requires you and your readers share some common and implicit understanding
I will be satisfied if this post made you consider perhaps verbosity is not so bad after all.
Now is the time to read Andy’s post if you didn’t already and make your own mind.