Scala Creator Answers Critics of Language Roadmap

For those interested in Scala,  SIP-18, which plans to modularize language features, has caused a lot of controversy. So much so that Scala's creator, Martin Odersky, has been compelled to explain himself to the critics of Scala's roadmap.

The proposal seems to have good reasoning:

 Not every Scala programmer needs to make use of every specialized tool in Scala’s arsenal to write libraries or DSLs. I therefore propose a scheme where some of the more advanced and contentious language features have to be enabled explicitly, using an import from a new language enumeration object. 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.

The critics have had lots to say about this - in particular claiming that  primary purpose of SIP 18 is to pander to naysayers. Odersky claims that he always tried to make Scala a powerful language while remaining relatively simple. The point some have made about the language is that it's just another huge language, and not as simple or concise as it advertises.

I believe the criticisms are overall very unfair. But they do contain a grain of truth, and that makes them even more vexing. While
Scala has a simple and consistent core, some of its more specialized features are not yet as unified with the rest as they could be. My
ambition for the next 2-4 years is that we can find further simplifications and unifications and arrive at a stage where Scala is
so obviously compact in its design that any accusations of it being a complex language would be met with incredulity.

In his response, Odersky explains some simplications that he would like to see make their way into Scala - moving XML processing into libraries and unifying type parameters and abstract type parameters. 

In response to the SIP 18 critisisms:

First, while we might be able to remove complexities in the definition of the Scala language, it's not so clear that we can remove
complexities in the code that people write. The curse of a very powerful and regular language is that it provides no barriers against
over-abstraction. And this is a big problem for people working in teams where not everyone is an expert Scala programmer. Hence the idea
to put in an import concept that does not prevent anything but forces people to be explicit about some of the more powerful tools that they
use. I am certain there is no way we can let macros and dynamic types into the language without such a provision.

Second, the discussion here shows that complex existentials might actually be something we want to remove from a Scala 3. And higher-kinded types might undergo some (hopefully smallish) changes to syntax and typing rules. So I think it is prudent to make people flag these two constructs now with explicit imports, because, unlike for the rest of the language we do not want to project that these two concepts will be maintained as they are forever. If you are willing to keep your code up to date, no reason to shy away from them. But if you want a codebase that will run unchanged 5 years from now, maybe you should think before using complex existentials or higher kinded types.

Of course the docs for these two feature flags will contain a discussion of these aspects, so people can make an informed choice for themselves.

My own option from reading both SIP 18, and Martin's response, is that he's got it right. The modularization makes sense to me. It will be interesting to see where things go for Scala in the future.