Complexity is in the Eye of the Beholder

I just read through David Pollak's blog Yes, Virginia, Scala is hard. Now David has much more contact with developers in the trenches than I do, but I was a bit perturbed by his perspective.

He doesn't paint a pretty picture of the “center-of-the-mean” company. He has unkind comments about people with a 9-to-5 work week or people who don't know Zed Shaw. Now I would like to have a 9-to-5 work week, and I think I could get there if I wasn't frittering my time away writing blogs.  And I had to Google for Zed Shaw to realize that he is the one who writes those “Learn X the hard way” books. (I glanced at a couple—I am not crazy about the Ruby one...way too chatty...but the C book has some really good ideas.)

It may well be that the “center-of-the-mean” company prefers to use a language that makes the easy things easy, like Cobol or Java-together-with-a-bunch-of-point-and-click-tools. It's always been like that. Not so many years ago, I was stunned to find out that more people programmed in Visual Basic than in C++ and Java together. Now, Visual Basic isn't looking so hot, and its annointed successor, C#, is getting to be way more complex than Java, so we'll see where that's headed.

I used to love C++. I used to come up with ever more elaborate uses of templates and smart pointers in C++, and had a low opinion of programmers who used C++ as “C with cout instead of printf”. Then I ditched the whole thing and moved to Java. Now, when I look how C++ is used, it's advanced a bit. People do use classes, like in Java, and they use simple templates. But most of real life C++ stays away from the complex features. That is actually very reasonable. Not every C++ programmer has to be a template guru. Not every Java programmer has to grok wildcards. Not every Ruby programmer has to understand metaprogramming. Not every Scala programmer has to comprehend higher-kinded types.

The C++ programmers have made peace with this state of affairs. A few wizards produce libraries that every one else uses. Most Ruby programmers never knew it any other way. Rails provides the framework, and one follows its one true way. So why this hangup about Scala complexity? What's wrong about using the easy parts and letting the experts worry about the hard parts? By the way, David  is the first to point out that Scala is easier than Java when you stick to the plain OO features.

What's the alternative? Just use Java? We all know it doesn't have enough mojo. Add IDE code generation, XML configuration, dependency injection, annotations. Now we are talking. Ok, but how simple is that?

Use Ruby/Groovy/JavaScript? How cheerful is it if just about everything is a hash map and all your errors are found at runtime?

David has this list of bullets:

• There are too many debates about OO vs. FP. — David thinks that developers should just embrace functional because it's better. I don't know about that. Sure it's better, except when it isn't. Why fight it? Scala is a better OO language than Java, so that's a great start. Scala makes it easier than anything else I know to explore functional programming and gradually succumb to its temptations.
• Scala IDE support will always be weak. — Really? All I want is autocompletion, global rename, and organize imports. I don't care about “hoist method” or whatever other refactorings there are in Eclipse, and judging from the IDEs that support C++, Ruby, PHP, etc., neither do most people. Ok, in Scala, it's nice to have “reveal implicits”, which IntelliJ does. And of course “don't crash” and “don't flake out”. But I think those all are within grasp. I mean, if Ensime can do it, it can't take forever to stabilize the IDE plugins.
• The Scala type system is in your face too much. I couldn't agree more. There simply must be a way to hide

  flatMap [B, That] (f: (A) ⇒ Traversable[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That

  from innocent bystanders. It'll happen.

• “Junior developers who are asked to maintain code written by senior developers have to understand the idioms and patterns in the code. ” That's where it is useful to look at what happened in C++. When I was a dangerous C++ programmer way back when, inflicting smart pointer templates on an unsuspecting public, this fear was prevalent too. But regression to the mean wins out here. In the end, idioms and patterns will survive if they bring utility to the majority of programmers, as the idioms of Spring and Rails have. The “center-of-the-mean” programmers don't know all the ins and outs of C++, Java, or Ruby, and won't know all the ins and outs of Scala. Give them better tools to do their job, and they'll love you. Give them lectures about functional programming or monads, and they won't love you so much.

In the end, Scala will win if it gives programmers what Java, Ruby, or Lua gave them—a better way to do their job. People loved Java because it didn't make them deallocate memory, and because it let them put up a GUI and connect to a database. People love Ruby because of Rails. Ok, I don't know why people love Lua, but TIOBE tells me they do. If you love Scala, go and write that framework or library that makes them love it too.