User:Shlomif/Your programming language must suck

Introduction

All languages of the world suck. If you require people to declare variables (like in Pascal, C, Scheme or Perl 5 with strict), then people 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.

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.

Dynamically typed languages (like Perl 5, Python, Ruby, or Lisp) possibly suffer from many subtle errors ; Statically typed languages (like Haskell) are less expressive and 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;" (more like "break" in C) or "next LABEL;"), then you encourage code to not be factored correctly. If you don't have such stuff, then 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.

Finally, 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).

You are damned either way, whatever you do.

I could have gone on, but I think I got my message across. Thing 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.