Over the weekend, this post on choosing programming languages that are right instead of the ones that you can find programmers for. I have a bias in that direction, so it rang true to me. The author, José A Ortega Ruiz, has a startup with a backend that is written almost entirely in Clojure. A few relevant quotes:

During my previous professional career i had been repeatedly dissapointed by the lack of conviction, when not plain mediocrity, of the technical decision makers in what seemed all kinds of company, no matter how cool, big or small: one would always end up eaten alive by the Java/C++ ogre, with a couple testimonial scripts (or perhaps some unused scheme bindings) to pay lip service to the hipsters around.

Deep down, the people in charge either didn’t think languages make any difference or, worse, bought into the silly “availability of programmers” argument. I’m still surprised anyone would believe such a thing. If i guy came telling me that he wanted to program only in, say, Java because that’s what he knows best and that he doesn’t really feel prepared or interested in learning and using, say, Clojure (or any other language, really), i wouldn’t hire him in a million years, no matter what language my project were using, and no matter how many thousands of candidates like this one i had at my disposal.

Give me programmers willing to learn and eager to use Lisp or Haskell (or Erlang, ML, OCaml, Smalltalk, Factor, Scala...) any day, even if we happen to be using C++, for goodness sake! Those are the ones one needs, scanty as they might be.

From where my mouth is
Referenced Mon Sep 16 2013 11:41:07 GMT-0600 (MDT)

I remember when Java was new. I think part of Java's appeal was that it let people try a new programming paradigm (object oriented programming) in a familiar, ALGOL-like syntax. Smalltalk has a very different feel to it, even though both are "object oriented."

Interesting that José says nothing about Ruby. Ruby (and others) have many of the things that make Clojure cool without being so different that people shy away from it. Of course, the feature that no language that is not based on S-expressions can duplicate is macros. Macros are the feature of Lisp-like languages that I always wish I had. Once you know what macros can do, it's painful to not be able to use them.

I've got a lot of history with Scheme, ML, and Haskell. They've all shaped my thoughts about what makes a program elegant and how the choice of language contributes to that. I started teaching introductory programming in Scheme at UC Davis using SCIP in 1988. Dick Walters, the department chair, was daring enough to let me, a graduate student, completely redesign the introductory courses to use Scheme.

Of course, I've got a non-mainstream language of my own—KRL—that I'm promoting. I even wrote a book about it. The reasons I give in the book and elsewhere for using a new and different language are still important:

Tools shape how we think and work. I learned long ago that the best way to think differently about a problem is to create a nomenclature that describes and illuminates the new domain. KRL is a rule-based language that is custom built for the domain of event-based applications that operate on real-time data in the cloud. KRL was designed from the ground up with events and the cloud in mind.

Obviously, I'm banking on overcoming the "there aren't enough programmers that know KRL" argument with the power of the notation and engine that executes it. I firmly believe that languages matter. Languages have the power to push us out of familiar ways of working and into new ways of thinking.