Why Your Programming Language Must Suck

This is an essay that enumerates some trade-offs in the design of programming languages, and why some people who have to learn or use the language will always be unhappy.

All programming languages of the world suck. If you require people to declare variables (like in Pascal, C, Scheme or Perl 5 with strict), then some people will be inconvenienced by the need to declare, and will tell you they like variables to spring up upon first use. Without variable declarations, then you get various weird side-effects of the implicit scoping. If you use curly braces for scoping, then you'll have to type more and there's more clutter. With indentation-based scoping (like in Python), you'll find it hard to introduce multiple-expression lambdas and will have some other problems.

Rob Pike and Paul Graham hated object-oriented programming (OOP) and so they didn't introduce it in their "Go" and "Arc" languages, well after OOP has become mainstream. And guess what? Many people, including me, think that OOP is still a good thing (and no, in my opinion, C++ did not do OOP very well) and so gave up on Arc quickly and did not look closely at Go. Many people who oppose OOP claim that it mashes together many separate features, such as typing, capability of being instantiated, and polymorphism which belong as separate features in the language, but naturally it is convenient to have them integrated as one, because they are often useful together.

Dynamically typed languages (like Perl 5, Python, Ruby, or most dialects of Lisp) possibly suffer from many subtle errors; Statically typed languages (such as Haskell) are less flexible, and sometimes require going into many hoops to write quick-and-dirty code. Furthermore, it seems that about one third of the language design papers published on Lambda the Ultimate are about various funky extensions to the Haskell type system to allow for better expressiveness.

Purely functional languages have no assignment and most people find them harder, in part because the world around us has a lot of state, and they also need to do funky compiler tricks to make you feel like you don't need assignment. Non-functional languages have side-effects and so are prone to many errors.

If you have goto or goto-like statements (such as exceptions or Perl 5's "last LABEL;" or "next LABEL;"), then you encourage code to not be factored correctly. If you don't have such stuff, then some programmers will hate you for having to go through many hoops to write quick-and-dirty code.

Perl 5 has a dedicated regular expression syntax, which is treated magically by the parser. PHP and Java use strings for them, and require weird escaping and backslashing rules to interpolate the sub-regexes inside them. And if you incorporate a first-order syntax for regular expressions, then people will want similar first-order syntaxes for XPath, for XML (like some recent versions of Visual Basic .NET have), and for all other grammars you may need to embed.

Many people absolutely hate all the clutter created by the leading sigils of Perl 5 (the $, @, etc.), and similar languages, but they allow for much better backward compatibility, facilitate the so-called "interpolation" (= embedding inside strings), and also give some important visual cues when skimming code (even without syntax highlighting).

Finally, while most modern languages use lexical scoping, I have found dynamic scoping to be somewhat advantageous when writing Bash / Zsh and Perl 5 code (which also has lexically scoped variables).

You are damned either way, whatever you do.

I could have gone on, but I think I got my message across. The point is, when designing a programming language, you need to make a lot of design decisions - what to include, what to exclude, etc. However, many of these design decisions are not 100% advantages or 100% disadvantages, but in fact trade-offs, and many people will question them and be unhappy. You can never please all the people. So make a design decision, and stick with it, and realise that your programming language must suck, but that it may suck less for some tasks, or for some people.

Joel on Software refers to the book Small Things Considered: Why There Is No Perfect Design, which I have not read, but I've concluded it holds for programming language design. Moreover, even when writing code, we run into many trade-offs. For example, if our methods or functions are very short, then they are easier to over-ride and re-use, but, in that case, the code would be harder to follow and will perform worse than code with longer methods.

• Original version - as a post on my tech blog.

• Programming Language Checklist - funny! Also see a Reddit discussion.

• My Tweet - The solution a friend wrote in Haskell for Euler630, and I tried to optimize, while using ghc -O2 is currently slower than cpython and PyPy runs it 4 times faster. Optimizing Haskell code seems like a dark art..

• Compilation Speeds Conversation.

• "Your Language Sucks because…" - lists shortcomings of several languages.

• "Never Try to Please Everyone" - a list of links and quotations on my wiki, about the more general, non-programming-specific, theme.

This document is Copyright by Shlomi Fish, 2011, and is available under the terms of the Creative Commons Attribution License (CC-by) 3.0 Unported (or at your option any later version of that licence).

For securing additional rights, please contact Shlomi Fish and see the explicit requirements that are being spelt from abiding by that licence.