Language criticism

6

I read @codahale’s “leaked” assessment of Yammer moving some code from Scala back to Java with great interest today. I post about it somewhat hesitantly because it is a private thing that became public but I have lots of thoughts and I need to dump them somewhere. I am going to write this quickly and it will likely be twice as long as it should be. Sorry.

First, I think there is a great temptation to point at this particular note and use it as evidence that “Scala is bad” or whatever. While I know and respect Stephen Colebourne a tremendous amount, I have not particularly enjoyed the tone of his recent Scala criticism (which is not to say that I don’t think he makes valid points in some cases). I winced to see him waving the flag in this way.

I would say instead that this is an incredibly valuable evaluation of a young and promising language and I hope and believe that it will be taken that way by Odersky, etc. It is easy to find drive-by criticism of a language but much rarer to find someone that has lived in it for a long time and is able to deliver precise, detailed feedback of where the pain was greater than the value. I found Coda’s criticism to be exactly that and also written in a highly respectful tone.

I am unabashedly a fan of Clojure (if you follow this blog, my tweets, my conference talks, my nascent Clojure/West conference, this is no surprise). I believe some people might perceive Scala and Clojure as enemies and thus suspect that the Clojure community likes seeing Scala bashing.

Much the opposite. We all want the same thing – a way to write programs that allows us to be more productive, make fast flexible systems, and write cool stuff. I find much to respect and envy in Scala and its ecosystem. I see some of the smartest programmers I know loving Scala and finding it productive. I believe that Clojure and Scala (and all the other languages I’m not talking about) want a better way to do programming. In that, I see allies, not enemies.

Going back to Coda’s gist, he is honestly evaluating his choices and deciding where his team can do their best work *right now*. In the end, you’re balancing forces of time-to-market, performance, quality, future maintenance debt, on-ramping new people, etc. I don’t hear Coda saying “Scala is bad”; I hear him saying “Scala is not the best balance of our needs at this time”. Other people will make a different choice. They will make different choices at other times. That’s just being smart at running your business. Being able to coherently say “…because X, Y, Z” is very helpful so the language can evolve.

I saw some questions floating around about whether people using Clojure have hit this part of the hype cycle. Since we’ve been doing Clojure full-time at Revelytix for a couple years now and have hired people, done maintenance, etc, I think we’re as qualified as anyone to judge that. In general, I’d say that we certainly have encountered painful aspects of the language or the tools – when you are using tools in anger, you find things that suck. We have hit serious pain around AOT (ahead-of-time) compilation. We’ve seen some nasty classloader problems (linked to AOT). We’re having a more painful time than I expected moving from Clojure 1.2 to 1.3. Debugging sometimes sucks due to laziness, large stack traces, confusing error messages, etc. I yearn for refactoring tools as good as what I had in Eclipse with Java. Sometimes I want a static type. :)

On balance, we are not clamoring to change back to Java (or anything else) though. All of the painful things above are things we have worked through. By choosing a young language, you are implicitly accepting consequences like immature tooling or buggy libraries. I think we’ve tried to hit a good balance of powering through issues and giving back fixes or filing bugs where appropriate. Clojure is such a dynamic language that there is almost always a way to address a problem (even in the core libraries or the language) from your own code. Encapsulation (of data or code) is not held in particularly high regard in Clojure. The upside is that the engine is laid bare if you need to swap out a piston or something. In general, we have found our resulting code to be vastly preferable to what we could do in Java. Clojure gives you a set of composable tools that allow you to build systems to talk at the level of your problem and that is what I want in any language. For us, right now, Clojure is still a big win in that set of forces.

Comments are closed.