Wednesday, 11 January 2012

Compiler Flags In Scala

Recently this post triggered the age old debate over Scala complexity and resulted in a suggestion by Martin Odersky about adding compiler flags that enable features like implicit conversions. As someone who is beginning to get to grips with higher kinded types but generally comfortable with most things in the language this has interested me. Watching the conversation there's a series of thoughts I've had about it:
  1. There's an element of action at a distance, if I'm sat in my IDE how do I know that feature X is enabled for this project without just typing the code and then seeing the red line through it?
  2. Defaults are always difficult to choose, will all features be enabled by default to then allow people to discriminate as they please?
  3. Included libraries that expose something with a disabled feature will end up being nerfed or require a lot more work to provide sufficient functionality through multiple entry points. This troubles me as it seems like it would have the inverse effect on complexity for both consumers and producers of libraries.
  4. Depending on the choice of enabled features in two different projects, even with the same version of Scala, could end up with quite different "versions" of the language. Code that could easily be used in one would result in a compile error in another.
  5. From a different angle, there's the question over if this is even necessary, C# has implicit conversions and a whole variety of keywords in the mix but I've not seen suggestions that it's too complex. Java generics are a massive pain for just about anyone that has used them for more than just collections as you'll see here. If the majority of people complaining it's too complex aren't people that have used it, then it would seem to use the advice of those people to shape the future of the language is potentially foolhardy.
  6. Functional concepts aren't familiar to most programmers and can be a blocker for understanding. Better and more joined up documentation is one of the things that can help with this, the Twitter Scala School is a good example. In a certain sense it's not so much that Scala is complex as that its features don't exist in isolation unlike a lot of other languages, they tend to join up quite nicely. Which results in the potential need to understand several things to get the most out of say the collections framework.
Now, saying all this, I think there's an alternative to straight compile errors with various flags that is tools like CheckStyle. This then negates the need to complicate the language and the compiler and can potentially be more granular depending on the requirements. As a team gets more comfortable with a particular feature, when a feature is allowed it would then recommend that feature to be used in appropriate places, so that it nicely complements both sides of the equation. Maybe even a warning would be "Implicit conversions would assist in reducing the complexity of this code." if the applications of something reached a certain threshold.

I propose that rather than limiting and oddly fracturing the language, instead provide better tooling that allows programmers to increase their understanding naturally and assists them to do so.