January wears on, and you may already have applied your first nicotine patch, ordered your first no-alcohol beer, or jogged — PUFF, *]GASP[*, lung to legs, we have a problem, over — your first throat-burning mile, before concluding that the self-improvement gain just is not worth the pain. So I hope I'm not too late. I'm following Mark Nelson's everybody their own Jon Erickson resolutions about best practice in writing English. But where Mark dealt with a natural language, I'll deal with the artificial; and that gives me an advantage. Because although I can't decide not to write in English for Dobbs Code Talk, I can decide what not to program in. Let me, then, explain to you my New Year's resolutions on how to choose a programming language.
Because I like to write vector arithmetic as a linear algebraist would, I shall only program in a language that has overloadable and user-definable operators.
Because I don't wish to waste my time debugging storage allocators, I shall only program in a language that implements garbage collection.
Because, yoking thing-ness to process, Janus-faced function is the most important concept in all of mathematics, I shall only program in a language where functions are first-class values.
And where, in order to abstract the application of action, I can define higher-order functions.
Or any function. (Which rules out Java.)
Because sometimes I need to hack out a data structure really really quickly, and then I don't care about efficiency or the security given me by type-checking, I shall only program in a language that gives me lists with dynamically typed elements. [ 'And', a, 'built-in', notation, for, list, constants, '.' ]
And, although this is not at all part of the language, an XML parser that I can point at a file and yell: "Go! In one statement, parse this file, put the result into a list, and pretty-print that list!"
Because Fun Boy Three got it back to front when they sang T'aint What You Do (It's the Way That You Do It), I shall only program in a language that separates implementation from interface definition. This does not include languages that use classes for modules, because classes are not modules. Classes are for simulating physical objects: things with worldlines, gadgets with parts you prod, rocks you pick up and drop and stub your toes on, entities David Bowie can mean Ch-ch-ch-changes about. To use them as modules is a category-mistake that would keep Gilbert Ryle in book contracts for the rest of his life, were he alive. It's like asserting that colourless green ideas sleep furiously, that death rides a white horse and carries a scythe, that our winter snows are treacherous, or that a database can be intelligent. It's a type-violation attack on the concept of modularity. It's me staring at a Science Museum cutaway model car engine and looking for a lever that will fire from the cylinders books of instructions on calculating petrol consumption in Ford Edsels, drunk-driving penalties as a function of blood alcohol, and how to dig your wheels out of a snowdrift.
Because 2=2, even when one two is in my pocket and the other is in the Crab Nebula, I shall only program in a language in which two equal mathematical entities are equal. Indeed, in which two equal anythings are equal. Location in core is not identity, and numbers don't have worldlines.