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"
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 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.
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
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.