More Rant

As my colleague Danny Cutts pointed out in a comment on my post yesterday, I criticized the status quo in software development without making any constructive suggestions for how language selection ought to be done.

The short answer to that question is that it is a topic that sorely needs research. There are, in fact people in academia all over the world that are investigating these issues. There are many interesting approaches. I have been impressed by the results obtained by using languages that enforce constraints against mutable data and encourage programmers to avoid side effects.

I am an admitted fan of Lisp and I think that Clojure has done the best job of all the modern Lisps of advancing the state of the art of Lisp like languages. Not only has it made data immutable by default, it has also unified the operations upon collections of all sorts. It has also baked in thread safety to the point that it’s hard to get concurrency wrong.

And the final aspect boosting Clojure over the top in the comparison of modern Lisp implementations is the fact that it is built on top of the JVM and provides direct access to all those incredible libraries available for the Java platform. It is truly the best of both worlds.

Another language that is oft maligned but is far better than it is widely thought to be is Javascript. It has long suffered from lack of respect due largely to being forced out the door prematurely for marketing reasons and then forced to live with its unfortunate choices due to its wide spread adoption as the universal web scripting language.

Modern implementations, Node.js on the server, and the evangelism of Douglas Crockford have all gone a long way toward improving Javascript’s reputation not to mention it’s attractiveness as a generic platform for application development.

Languages should be chosen to best address the needs of the problem domain. That is much easier said than done. We are suffering from too many options. People try to overcome that problem by artificially constraining the list of choices. Perhaps they would do better to use the prescription that the Unix community suggests (sometimes attributed to Kent Beck):

  1. Make it work.
  2. Make it right.
  3. Make it fast.

What that means is, first hack out a naive solution, sometimes referred to as the simplest thing that might work. Then, refine the solution to cover all the edge cases that you overlooked in the prototype. Finally, instrument the code to find out where it is spending most of its time and concentrate on optimizing that part of the code.


Sweet dreams, don’t forget to tell the ones you love that you love them, and most important of all, be kind.