(I started this post about halfway through the Year of New Programming Languages, and wrapped it up in December.)

At the midway point I was most excited by Common Lisp, but with doubts I'd be using it for anything real. By the end of the year my favorite new language was probably D.

Icon was fun, but impractical: no real libraries, no ecosystem, no way to deploy anything, no tools, etc. It's dead. Nothing more than a historical interest.

I don't see what the big deal is about Go. To be fair, I was trying to do a lot of string processing, which seems to be cumbersome in Go. There are probably other areas where it shines.

Scala is neat, but it's big -- it needs much more than a month to be able to do anything worthwhile with it, and you have to learn your way around the Java ecosystem if you aren't already familiar with it. And in the end, you're on the Java ecosystem, which... well, it is what it is, you take the bad with the good. (I'm prejudiced against it.)

It's hard to get excited about Java, which I'm only using to make a little game for my Android tablet. I'm trying to keep an open mind and fight the prejudice. On the bright side, there are lots of tools, which brings me to the point of this post.

1. Your language can suck (at least somewhat), but if it has a lot of high quality tools, it might be more usable than a theoretically superior language with crappy tools. In my opinion, this is Java: I don't care much for writing Java, but it doesn't completely suck and those guys have some really nice tools.

2. My goal when I start a programming project is to deliver some value to someone. Frequently, this is ultra-short-term value for myself (e.g. a one-off bash script). I also hack a lot on longer-term projects for personal use or by groups which I have a relationship with (e.g. small Flask/Python website). If I can't deliver the value, then what is the point?

   I'm looking at you, Common Lisp: I couldn't figure out a way to reliably deliver a simple desktop app. Icon is in the same boat. On the other side of the coin, Java and Python can be really easy to deliver -- there are tools to generate desktop installers, and deploying web apps can be really simple. In the old days of the web, this was the beauty of Perl CGI scripts: to deliver it, you just drop myscript.pl into your cgi-bin. (I figure it's also why PHP, which is a crime against humanity, is so popular: deployment is trivial on almost any web host.) And Javascript has historically been more or less the only obvious choice if you want something to run in a browser, though with Dart and some of the new languages that compile to JS we can see that changing.

   Languages like D or Chicken Scheme that compile to native binaries are easy to ship as well. (They're somewhat harder to 'ship' if you're a FOSS project and the 'product' is your code, only for the fact that your users are less likely to have the necessary compilers and libraries available.)

   So normally the first question I ask myself is, "How am I going to ship this?" That really drives the choice of language.

3. Are there tons of libraries? If I can grab libraries that do 80% of the work my project needs, it makes me strongly consider using the language. This is a huge strength of Perl and Python: there are libraries for everything.

   In today's world, just having libraries isn't even enough: they have to be discoverable. The modern languages with which I'm familiar all have some kind of package discovery and download tool: Perl has CPAN, Python has pip, Dart has a tool that I only interacted with through the IDE, etc.

4. What is the testing experience like? Does the language have a way (preferable one standard way) to set up and run tests? Does it not suck?

   D has perhaps the best language support I've seen for testing -- you can declare unittest { ... } blocks right inline with the functions you're testing.

   My limited experience with Perl gave me a taste of that ecosystem's good handling of testing. There are established patterns for how to do it The Right Way, and useful tooling set up around those patterns.

   I'm most familiar with Python, where there isn't really a Right Way, but there is a unittest module in the standard library, and some popular tools like Nose that make unit testing not painful.

   C on the other hand, is annoying for unit testing. There are libraries, but the quality varies, and mostly my experience has been that you have to roll your own support for testing, pretty much every time.

5. Programs written in the language need to be debuggable. Especially when I'm learning the language, because I'm going to do stupid things. If debugging is painful (or worse, if I can't even figure out how to get past compiler error messages -- I'm looking at you, ghc), then the frustration just makes me want to walk away and find a better tool.

   Part of debuggability is making it so that I can seamlessly walk through library code. The Dart IDE provided a nice experience here. (Yes, I know it's Eclipse, but amazingly it didn't suck like Eclipse usually does. Not a single crash.) When I did dumb things in my code, I got a backtrace from the library code where I could see the incorrect argument I was passing down.