4 ms·
The author is correct that, as a language "in the small", Scala offers many more ways for a programmer to create hard-to-understand complexity. Though many thi
by stephenjudkins 16y ago
The author is correct that, as a language "in the small", Scala offers many more ways for a programmer to create hard-to-understand complexity. Though many things have been conceptually simplified (the distinction between primitives and objects has been abstracted away so that most developers don't have to worry about, for example) there is a whole lot more stuff that make it easy to hang yourself with. (See implicit conversions and parameters, destructuring and pattern matching, and the power of the type system). Most of these things can be used to make code more readable, concise, and flexible, but can also be used to great ill effect.
When it comes to programming "in the large", like the author seems to be describing, I couldn't disagree more. Here it's Java--the culture and ecosystem--that tends towards over-abstraction, huge frameworks that obscure rather than illuminate intent, ridiculous class names that include "FactoryFactory", and so on.
I would argue that the second phenomenon--the hugely complex frameworks that have arisen in the Java world--is a direct consequence of the lack of power offered by Java, the language. Complex frameworks that do dependency injection through bytecode generation and XML configuration files really aren't necessary in the Scala world, where 90% of what you're actually trying to do can be done using compile-time mixins. The factory pattern can be replaced with anonymous first-class functions, with a net increase in clarity and conciseness. Most things that makes Scala more complicated in the small can be also be used to replace even more complicated, ad-hoc patterns and frameworks that make big Java projects such a pain to work on.
That said, it could be true that introducing Scala into existing codebases that already have thousands of lines of Spring XML config might simply introduce additional complexity, without offering a realistic path to removing all of the nonsense that supports the legacy Java code.