5 ms·
> Verbosity matters for reading and maintenance far more than it does for writing. I would argue that on average verbosity improves readability. Yes it may tak
by frostmatthew 12y ago
> Verbosity matters for reading and maintenance far more than it does for writing.
I would argue that on average verbosity improves readability. Yes it may take you slightly longer to read the code, but verbosity often results in the code conveying more information or expressing it clearer (or both).
- lmm 12y agoJust repeating the same thing twice doesn't help with anything. The standard examples of Java verbosity - repeating variable types, getters and setters, anonymous classes instead of lambdas, using the visitor pattern to emulate pattern matching - don't make anything more readable or clearer (indeed many people find the Java version more confusing to read). What features does Java have that you're saying help code convey more information or lead it to be expressed more clearly? I find that my more concise Scala code usually both is clearer (there's just less irrelevant clutter e.g. braces) and conveys more information (because e.g. error handling with Either and for/yield makes it clear which parts of a function could have errors, whereas with try/catch all you know is "there's a function somewhere in this block which throws").
- frostmatthew 12y ago> Just repeating the same thing twice doesn't help with anything. I completely agree - but not all (or even most) of Java's verbosity is from repetition. The traditional example of `Foo foo = new Foo();` as repetition ignores the fact that `Foo` will not always be repeated as the first will often be an interface (or superclass) and the second will be an implementation, e.g. `Set<String> set = new HashSet<>();` > What features does Java have that you're saying help code convey more information or lead it to be expressed more clearly? My comment regarding verbosity wasn't in comparison to Scala, I was thinking of Ruby, Python, Lua, et al (I'm a huge fan of Scala btw, but the post was on the benefits of Java versus dynamic languages). Anyway to answer your question with a few examples: * Java's method signature gives me a lot of information, looking at `public int doStuff(String foo)` tells me the visibility, what it will return, and exactly what I can pass it - even to someone completely unfamiliar with the language. Looking at `def doStuff foo` tells me nothing other than how many arguments it takes (if you're familiar with Ruby you'll also know the visibility). * Similarly when you see `return foo` you know (even knowing nothing about Java) that it's returning `foo` and that `foo` is the intended return value. * Someone who's never read a line of Java in their life can look at `Map<String, Integer> foo = new HashMap<>();` and know that `foo` is a map (and will most likely conclude it has Strings for keys and integers for values). If you've never coded in Lua and you see `foo = {}` you have no idea what that is (if you've seen similar in other languages you can make a good guess, but you don't know).
- opinali 12y agoI would rewrite that as "_explicitness_ improves readability". When I read Java code, I rarely have trouble to know what the code is doing (at least at a local scale). Not all static-typed languages are readable because they're not all explicit. In C++ for example, even the most trivial snippet of code can be obfuscated by all sorts of abuse: operator overloading, implicit calls to copy constructors, preprocessor macros, etc. Scala suffers the same problem, perhaps even worse, doing tons of stuff automatically i.e. in a way that's not obvious by just staring at a code fragment such as an individual method. Organizations that have success writing large-scale code in such languages [I can speak for Google here], typically have careful style guides that ban the bad stuff and are strongly enforced by code review process; but in that case you're not using language X anymore, you're using some "safe subset" of X. Of course you can't have any high-level abstraction without some tradeoff of maximum explicitness; virtual calls for example make hard to know which exact code is invoked by "just staring" at an invocation. The trick is striking a healthy balance between power and readability. Java is not perfect in this criteria (it errs a bit in the side of caution), but it's certainly much better than any dynamic-typed language.