I came across an article the other day that was praising the fact that Java becomes less and less verbose due to the recent changes to the language. And I have a confession to make: I don’t think that this is necessarily a good thing.
I think the craft of programming has in general a lot of problems that come from its roots in mathematics and the genius myth. Programmers have grown up to be these mythical creatures that sit in the basement, don’t like the sunlight and write cryptic codes on white on black screens. And are, all of them, geniuses. That needs to go away.
One of the things that I usually say about programming is that you usually do it when you are well rested and the best of yourself, after a full night of sleep, the necessary coffee (or water in my case) provided and in general able to do deep concentrated work. The problem is that you do emergency maintenance at 4 a.m., when you just caught an hour of sleep after a long night out, slightly drunk, with a cold coming and usually the worst of yourself. So you should aim at this level of mental capacity. That’s a variation of the theme that one should write code for the future self, slightly more radical.
And here comes my problem with the verbose is bad myth. If you get a very verbose explanation of something that is usually a good thing. If the information you get is very verbose that is usually also a good thing. Only in code verbosity becomes a bad thing.
One example of this reduced verbosity is type inference. In general it has its use-cases, but if you have type inference throughout your whole code base you often lack necessary local information. Sure my IDE helps, but that is somehow hindering my flow while reading code. I have a runtime in my head that can understand Java code, but obviously I can’t hold the whole program. So I need local points to start my reading and understanding and if that is interrupted too much by looking up things it becomes just to hard. I know that the compiler is super clever and can infer all those types, but can I? The answer is no in a lot of places.
Another example is mutability. Of course it is annoying to write final in front of everything, but it conveys so much of the original authors intention, what she had in mind when she wrote that piece of code that it is a very helpful piece of information. That programming (be it object-oriented or functional does not matter) is mostly about reducing the amount of possible stats is a whole article in itself, but sometimes those verbose parts of the Java Programming Language are actually good.
In general I would expect anyone to put as much information in the few lines they are writing as possible. Of course that is more to type, but typing speed is in general not the limiting factor of programmer productivity. And yes, code is read a lot more times than it is written, and even if it is slightly more to read it might help the reader to understand all the state and all the implications faster, more efficient and with fewer errors. Verbosity in code has to become a positive aspect again.
blog.thiesen.org 
While I do agree generally that verbosity is not in itself a sign of good code (but merely a reflection of the programming language), I disagree with your examples.
I think that languages should endorse safe and easy-to-reason-about code.
There always is an amount of language specific knowledge you need while reading code. Usually, this is stuff like implications wet mutable state, possibility of null values etc.
While reading code, safe code should be easy to spot, and easy to read. Which often does imply: it should not have to be verbose in order to convey it’s safeness.
Only if there is something to be aware of, it should be verbose IMHO.
So, making stuff mutable should be long with extra keywords. Immutable should be short. Not allowing null should be short, allowing null should be verbose.
And repeating types over and over again does slow down reading, So I do enjoy type inference – within one module. APIs should be typed explicitly though.
LikeLike