Jens Schauder is software developer since 1997. He loves software development for the constant challenges and constantly changing environment. A great chance to learn and teach. He is also blogger, author of various articles and speaker at conferences. Jens is a DZone MVB and is not an employee of DZone and has posted 84 posts at DZone. You can read more from them at their website. View Full User Profile

Scala Improvement Proposal 18: Why?

03.21.2012
| 2824 views |
  • submit to reddit

SIP-18 is a Scala Improvement Proposal. Its intent is … well … to be honest. I don’t get it. But the plan is to introduce a feature in Scala which would disable some of Scalas features. In order to turn these features back on you would have to import them with statement like these:

import language.macros
import language.{structuralTypes, existentials}

So this feature is rather simple and kind of obvious to understand. But what is its intent? The proposal itself says:

The hope is that this will provide a good balance between the wish to provide the most powerful abstraction facilities possible and the wish to control of these features by making their usage more explicit.

Smart people say when looking for the real reason for anything one shouldn’t stop at the first answer to the question “why?” but instead ask again: Why does anybody whish to make the usage of these features more explicit?

Knowledgeable people seem to agree that you can use these features without actually wanting to with quite unfortunate side effects:

It’s quite easy for structural types to creep into a public API unintentionally [..] To give you an idea of the magnitude of the problem, the textual representation of the inferred type was 225kb. Yes, kilobytes.

So there is actually good reason for a way disable some features for those that don’t want punch holes in their feet. We have a problem and we have a solution so everything should be fine, right? I don’t think so.

Lets look at possible alternative solutions first.

  1. code reviews and proper education of developers … mmh, ok that won’t work in most cases.
  2. tools separate from the the language. I think Scala has a perfect setup for this. It allows compiler plugin and naive as I am I would think it should be perfectly feasible to write a tool or a compiler plugin that checks for usage of certain features. It would easily enforceable by a continuous integration setup which by now everybody should use who is working on some serious code.
Lets look at the consequences of the proposed solution second.
  1. It is another language feature, so it makes the beast that is so difficult to tame for many even more difficult. And it is a bad kind of feature in itself. It uses an existing Feature (Imports) in order to do something completely different than the normal usage does (enabling of features vs. managing of namespaces)
  2. It is zero protection for those not understanding the risk or willing to take it or both, even when they are only the minority of the team (note this is not possible with a compiler plugin or a separate tool used in the CI build)
  3. It makes usage of the existing features even more difficult, because now all the little hints and tips found in the internet fail to mention that from version X on you have to make an import to use a certain feature. I’m already waiting for the stackoverflow questions “I want to do Y and do just as described HERE and it doesn’t work”

There is a never ending discussion going on if Scala is complex or complicated or difficult. I think this SIP acknowledges this to be true. Which is a good thing (the acknowledgment). After all you don’t make guns saver be telling everybody these things are harmless.

Martin Odersky, Scala to stay a lean language:

In the future my ambition is to make Scala an smaller language, not a larger one.

Why would he want to introduce such a weird feature of dubious value?

As said before: I don’t get it. Anybody wants to explain it to me in the comments? Serious, it would be welcome.

Published at DZone with permission of Jens Schauder, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)