Skip to main content

Complexity is in the Eye of the Beholder

Posted by cayhorstmann on September 3, 2011 at 6:52 AM PDT

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++ and Ruby 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. We 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. 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.

 

 

 

Related Topics >>

Comments

While I agree that Scala gives programmers some ease of ...

While I agree that Scala gives programmers some ease of use features over Java, it doesn't provide any draw for me. I spent about 6 weeks with it over a year ago and I pretty much became fatigued by all the additional syntax without feeling like I was gaining anything from it.

I've been programming large enterprise applications for the past 7 years and Clojure (dynamic and simple but also powerful) feels more like I'm moving in the right direction. Meta programming with macros is especially appealing since hiding implementation details would greatly reduce the chaos created when 150 developers start working on an app and 2/3 are in-experienced. Clojure syntax is about as simple as it gets; 2 weeks of learning and most developers will understand all the code they see. Full java interop so I don't lose the Java libraries I'm accustomed to using. Having said that idiomatic Clojure takes a bit of getting used to. Immutability is not something most Java programmers will find compfortable, but if you're interested in programming in a more functional style then immutability comes with the territory.

I hope both Scala and Clojure are successful since both languages will make you re-think how you program. If you any sparre time, give them both a try.

I agree with most of what you say, but I should point out ...

I agree with most of what you say, but I should point out that the anointed successor of VB is VB.NET, not C#. Judge VB.NET on its own terms (though be aware that we're striving to maintain feature parity between VB.NET and C# where it makes sense to do so).

I like Lua because of its garbage collection, tail ...

I like Lua because of its garbage collection, tail recursion, closures, fastest JIT, powerful tables, great community code and excellent integration with the bare bones C libraries.

But maybe what makes me really love Lua is its simplicity. Complexity is in the eye of the beholder, is simplicity in the hands of the language designer?