Your Favorite Language Sucks

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.

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 cons³, 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.

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.

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:⁴

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.