In this post I want to address (and express my opinion) some of the concerns described in fhil’s comment to my previous post about Scala Complexity vs Book of Magic Spells.
Conceptual Surface Area
First, I want to agree on concerns about language complexity, but I want to look at bigger picture. Scala the language has more concepts in it and from the language perspective it’s more complicated than Java. From my experience, every project bigger than HelloWorld involves heavy usage of libraries (including standard library). In my previous post I tried to take more higher-level view of the language, so I would like to keep this aspect in scope of our discussion. The problem with Java is that many libraries like Spring, Hibernate, EJB, AspectJ, etc. add completely new concepts which are pretty unique to each of them. And believe me, If you are creating real-world Java project (even small) you are expected to learn and understand a lot of new concepts introduced by these libraries (just try to search job sites for Java position and I assure you, most of them, of not all, require you to know a lot of libraries like Spring or Hibernate). I see Scala as product of evolution of other languages that absorbs new concepts in a language level that has proven to be useful or even essential. So Scala libraries can actually express themselves in terms of these concepts. Your real-world project becomes more simple, regular and consequent in terms of conceptual surface area. Just take a look at Unfiltered web framework, and how elegantly it leverages pattern matching, if you want to see an example. As application developer I care much more about project’s conceptual surface area rather than language’s conceptual surface area because language is common knowledge and if you invested some time and learned the Scala language you can jump in any Scala project and be very well prepared for the concepts you will face. It’s often not the case with Java because knowledge of reflection API and Annotations or even Java the language itself would be of little help in understanding new concepts that project or libraries introduce.
This reminds me of difference between Ant and Maven/Gradle/SBT/Leiningen. In Ant you have very small conceptual surface area. The result of this is that in order to understand what ant script actually does you need to look in it and understand all new concepts that it introduces (on top of ant). Maven, from the other hand, introduces much wider conceptual surface area, and yes, you need to learn it if you want to work with Maven. But as advantage, I can take namely any Maven project and run
mvn install or
mvn package on it without even looking in pom.xml. I even can run
mvn jetty:run because most of the plugins reuse concepts introduced by Maven and stick to them. Concepts like project, dependency, project’s version, project’s name, etc. are proven to be very useful and even essential to most (if not all) Java projects. So I also see Maven and similar build systems as product of evolution where common and useful practices, patterns and concepts are introduced directly into the core system itself.
Also I don’t expect non-scala developer to maintain Scala project in the same sense, that I’m not expect Java developer, who knows nothing bout Spring or Hibernate, to main Java project that uses these libraries. Still in case of Scala I at least can be sure that IDE and compiler can really aid him and guard him to some extent from failure (to much greater extent than Java compiler does).
And lastly, I would like to avoid discussion of highly subjective topics like language syntax. I believe that it’s comparable to personal taste and is the matter of habituation. And we just can’t expect all general purpose languages in this world to have the same syntax, especially the one you personally prefer.