Keep Scala Sharp January 11, 2012
Background: I've coded in Java since v. 1.0. I've been writing Scala code for almost 2 years, and professionally for about a year. I'm very far from mastering all of the advanced features of the language.
Dhananjay Nene argues that Scala should have compiler flags or tools to protect developers against the advanced, "dangerous" parts of the language.
I appreciate his attempt to make a constructive suggestion to resolve the Scala complexity complaints. That said ... are we really talking about this? What developer would use a compiler flag that prevented you from using something? Are there really developers out there who are afraid that they might accidentally stumble into using higher-kinded types? Developers who say, "I'm really not experienced enough to use those features, so please turn them off in case I forget how little I know"?
Of course not. These solutions are targeted at team leaders and managers who are afraid that they might have developers on the team who might sneak some broken attempt to use advanced features into the code, or who might write code so sophisticated that the rest of the team won't be able to figure it out. Dhananjay says (paraphrasing), "lets give managers a way to hold back enthusiastic developers so that they can't introduce the rest of our team to something that might confuse or scare them." Or worse: "let's give managers a way to dull the tools of their developers so the idiots won't poke themselves in the eye."
I'll repeat what everyone else has said ad nauseum: Scala is not the right tool for every job. Nor is any language or tool. The question that we're all asking now is: Assuming you've decided that Scala is a good fit for your requirements, should the scary, advanced, confusing-looking features of the language scare you away from adopting it?
The answer is: absolutely not, and you don't need compiler flags.
If your development team wrapped its head around OO, it has the mental capacity to handle most of the Scala "terraces," up to and including the collections constructs. (Most of us forget, now, how unnatural OO was when we first learned it. Scala collections are easier than java.util.Date. You've just had to use Date longer.) If team members are too lazy or obstinate to do so, stick with Java. Or, preferably, get a new team. Kotlin or Ceylon won't be any easier.
How to deal with the advanced features? Well, until they learn how to use advanced generics, implicits and higher-kinded types, *tell your team not to use them*. Alternatively (and preferably), let them bang their head against them until they either figure them out or give up and do things the Java way. There's always the trap door of just writing Java-style code and getting the job done. (I still use that trap door frequently.)
I'm actually fine with having options and tools like compiler flags if others want them, but I don't think Martin or anyone else at Typesafe should be spending a moment of time thinking about or implementing them. (They've already spent too much time dealing with these silly posts as it is.) They should be focused on making Scala even more powerful.
If it has to be done, I like the idea of using a scala-lint tool to do it. Perhaps a scalacheck library to help manage it. Developers can set what terrace they want to use for themselves, and then the tests will fail for any code that steps beyond his or her terrace.
I'll also make another tool that scans the github repository and auto-generates "you're fired" emails to any of my employees that use the feature.