Fork me on GitHub

Hacking Scala

#scala #hacking

April 28, 2013 at 2:13am

Conceptual Surface Area of the Project

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.

Maintenance Concerns

Now I would like to address concerns about maintenance - I actually disagree with points in the comment. I believe that in long run, Scala project can remain very maintainable. The reason for this is static typing and the fact that it’s very well accepted and practiced in Scala community. It’s much easier to maintain an application if you don’t even need to run and debug it in order to understand it’s behaviour and interaction/connection between it’s components. I don’t want to say that Scala completely eliminates necessity in debugging or running you application in order to understand it’s behaviour, but it can make it unnecessary in many cases. Let’s take perspective of new developer that jumps into the existing Scala project trying to understand it. What tools does he have in his toolbox? First and most important, from my point of view, is IDE - I can navigate code easily with the help of it. I use Intellij IDEA and I can use CTRL + Click almost everywhere. I can run search for usages and make complex refactorings without relaying on the wild guesses from the IDE based on the full text search and very very smart results analysis (which is the case with many dynamic languages and even with Java when you externalize part of your application’s logic in XML, text or any other non-java files). Scala aids your development with things like implicits but sill keeps this static link between application components that makes it possible to analyze code without resorting to full text search or debugging. I believe that static typing and generally static nature of the language plays very important role in ability to maintain and grow the project. I already faced problem several times when developers just fail or refuse to maintain (even good structured) JavaScript project because of dynamic nature of language and very poor tools support (and I doubt that these tools can improve any further). Nowadays Java project contain so many dynamic elements, that I’m really concerned about their maintainability.

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).

Subjective Stuff

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.