Your Favorite Language Sucks

I know you like it, but sorry, insert-favorite-computer-language sucks. They all do. Sure, some less than others, but most certainly your’s is the worst.

Language designers are smart, but limited foresight and compromises invariably introduce the inevitable gasping wut.

Old man rants are seldom helpful, and I try to keep this “blog” positive. Besides, as Brian Goetz’ mentioned in his 2014 talk1, languages are like biological organisms that emerge from the genetics of their ancestors and survive in specific ecological niches.

Fair enough.

However, I would like to perch on Paul Graham’s shoulders and extend his essay on the Hundred-Year Language 2 to tell the next generation of language designers my perspective.

Simple Syntax

I’m a polyglot programmer. I don’t have the luxury of spending even a full day in a single language. Think of one of your slightly-known language, and think how to get the length of an array or list. This could be:

  • A function
  • A property value on the array or list
  • A method on the array or list
  • A method on some utility class

Of course, the name could be size, length, or even len, which gives about twelve possible permutations. Perhaps this is why most programmers need large monitors…one for their IDE and another for the browser pointed to StackOverflow.

You know those parenthesizes in Lisps? They’re lovely. The syntax is so simple…almost to the point that a Lisp doesn’t even have a syntax. This is also why I prefer teaching younger students Scratch or other graphical (syntax-less) language, instead of Ruby or Python.

Limit the Operators

One of my frustrations with most languages, especially Scala, is the plethora of operators. I don’t care of operators. You must memorize a lot about operators, like precedence rules and side effects (can you imagine operators that alter the values it operates on?).

The worse part about operators is, unlike a function, you can’t do a simple web search on it.

Oh, and don’t get me started about overloading operators, for this requires more mental resources than I care to give, not to mention the ambiguity associated with + being both addition and concatenation in most languages. Since the << operator in Ruby is both the “here document” and array cons3, you need to make sure that the left side of that operator doesn’t come across as a list, or you might get the wrong operation.

No More Optional Code

I really don’t like optional features in a language. If the keyword do is truly optional, then it should never be used, and therefore should never have been added to the language. If the semi-colon or the return keyword is sometimes needed, then it should always be used. I really don’t want to waste mental bandwidth with keeping track of the language’s rules. I have a problem to solve.

Oh, and a return needed in a function, but not in a lambda expression. As a functional programmer at heart, many of my bugs are resolved with a return on the last expression.

Limit the Choices

I remember when I first came to Perl back in the early nineties, I loved the adage of “more than one way to do it”. Back then, I must have been smarter…or didn’t write code as part of a team.

Multiple choices for the same outcome just means I have to know all ways, including side-effects and other behaviors, since some teammate will choose the “other way.”

For the most part, I like Ruby, but I take exception with Steve Yegge’s description of Ruby, when he said:4

For the most part, Ruby took Perl’s string processing and Unix integration as-is, meaning the syntax is identical, and so right there, before anything else happens, you already have the Best of Perl. And that’s a great start, especially if you don’t take the Rest of Perl.

But then Matz took the best of list processing from Lisp, and the best of OO from Smalltalk and other languages, and the best of iterators from CLU, and pretty much the best of everything from everyone.

I guess the good part of this, is that I can write pretty good functional code in both Python and Ruby.


Yeah, my complaints are a bit silly for most engineers, and are mentioned here with an air of facetiousness, but I do enjoy discussing these with colleagues who are also polyglot programmers who know multiple languages, since the more languages you know, the least you like (and the more you appreciate) all of them.



See: Stewardship: the Sobering Parts, spoken at the 2014 ClojureConj in Washington, DC.


The Hundred-Year Language and other essays were published in his book, Hackers and Painters.


The cons operation allows you to append things to list, e.g.

[1, 2, 3] << [4, 5, 6]


[1, 2, 3, [4, 5, 6]]

Quote from his Tour de Babel as he describes his perspective on some popular languages. Another good quote:

Familiarity breeds contempt in most cases, but not with computer languages. You have to become an expert with a better language before you can start to have contempt for the one you’re most familiar with.

So if you don’t like what I’m saying about about C++, go become an expert at a better language (I recommend Lisp), and then you’ll be armed to disagree with me. You won’t, though. I’ll have tricked you. You won’t like C++ anymore, and you might be irked that I tricked you into disliking your ex-favorite language. So maybe you’d better just forget about all this. C++ is great. Really. It’s just ducky. Forget what I said about it. It’s fine.

Date: 2014 Nov 25

Created: 2024-01-12 Fri 17:05