In Pursuit of a Good Language

You’ll never find a programming language that frees you from the burden of clarifying your ideas.

But I know what I mean!

– xkcd 568: Well 2

I have been a programmer for over half of my life. This irreparably damaged me in too many ways to count, but it does mean I am pretty fucking good at writing code. But programming is a co-operative activity, between a human (at least, for the most part) and a programming language. Whilst it all ends up as ARM instructions in the end, there’s a lot going on between my keyboard and the long chain of heat-generating numbers being executed by the billion.

As with any skill (as much as programming can be considered a skill) I’ve grown and evolved my abilities over the years, and with that I’ve also grown in my opinions. How I felt about what a language should be has changed from since I was eleven, from since I was sixteen, and from when I was 21. A lot of people talk about using “the right tool for the job” - that’s bullshit. You can hammer the wrong language into the right place if you believe hard enough, and you can pass over the right language because nobody but you knows it.

But what is the right language? There’s a few things I consider “good to have”. The languages I use

• the languages I will continue to use - don’t meet these criteria, but my hypothetical Perfect Language would.

• Statically typed. Static types stop errors. I am not writing type checks inside my functions, I want the compiler (or something else in the pipeline) to do it for me!

• Good support for async/await. No, I don’t want threads, or green threads; I want to see exactly when a function suspends (at the await point). I want to see if a function is pure or not (if it’s async). I want to have good support for cancellation. And I don’t want fucking futures.

  Most of what I do is related to I/O (clients, servers, et cetera) so it ideally needs to have good support for that too.

• Robust error handling. This has become a sticking point for a lot of people; it’s not good enough anymore to have a function explode if it doesn’t like its environment. I want to know if it can return an error, I want to be able to handle it nicely without requiring try/catch scoping.

• Good IDE support. I mean actual, functioning autocomplete, errors that show up when typing and not when I hit compile and my entire window explodes into a fine red mist, real refactoring, and real source navigation.

• A solid, expansive standard library. As much as I get a disgusting sense of pure psychosexual joy from inventing my own libraries, I really do have better things to do than invent a standard library. I also really do not want to depend on ten trillion packages maintained by half-sentient web developers that are one day away from disappearing their online presence slash putting worms in their code for a hundred bones.

Languages I’ve used

I’ve used - and continue to use - a few languages over the years. When I say “used”, I mean “wrote something substantial”, something more than a thousand lines of code; not “used for a single experiment then cast into the bottom rows of Recently Opened forever”. But none of them really fit the Ideal Language that I want.

Python

Python is my native language. I understand Python on a deep level. I have most of the standard library memorised, I can explain the object model in detail, and I have actually used the two-argument iter() form in real code! (Enough so that it’s annoying aiter() doesn’t have the two-argument form.)