Human beings love to argue. Whether the argument is about boxers vs. briefs, ketchup vs. mustard, or Ginger vs. Mary Ann, people will take a position and argue.

I don’t know if it is a uniquely human trait or a natural consequence of any intelligent beings that develop language. Some say that dolphins have sophisticated communication abilities. If so, they could be swimming around discussing all kinds of topics,

“Isn’t the water chilly, today, George?”
“Actually, I think it’s gotten a bit warmer due to that global warming I keep hearing about.”

Or they could be swimming around arguing, the way humans do.

“Herring.”
“No way! Anchovies!”
“I’m telling you, herring is way better than anchovies.”

This trait is particularly common among programmers. Classic arguments include big endian versus little endian, indexing arrays beginning with 1 or 0, and which language is best. While the other debates have subsided a bit, the argument over which language is best seems to have heated up.

I’ve read a lot of articles lately where the author compares two languages in an effort to show why his favorite is superior. Often, these articles make it clear that only an intoxicated moron would use the language he so clearly shows to be inferior to his. Often, this superiority is established by showing features lacking in the one language. Sometimes they try to demonstrate superiority by accusing a language of being verbose and showing how the same thing can be achieved in fewer characters in the other language.

Fundamental Theorem of Programming Languages
In order to analyze programming languages, you first need to understand why they exist. I offer my fundamental theorem of programming languages: Programming languages exist to make computer programs understandable to humans.

Modern computers execute machine instructions that are represented in binary. Programming languages were created to overcome limitations in human cognitive abilities. It’s just plain hard for us to look at 1s and 0s and make sense of a program. So we created abstractions that make it easier for us to express and understand the actions we want the computer to perform.

Any comparison of languages should examine the abstractions they provide to facilitate human understanding of the program.

Second Theorem of Programming Languages
The second theorem is closely related to the first: If programmers do not understand a piece of code, they will either break it or rewrite it.

More important than how quickly you could write the code is how quickly someone else will be able to understand it later. This principle can be called “obviousness”.

An example of this principle occurs in languages that don’t require variables to be declared before they are used:

How can I tell if this line of code is correct? Maybe this line was supposed to use “param” instead of “parm”. I can only tell this by reading the rest of the code. The compiler (if this was a compiled language) would be no help, since this is perfectly legal. This minor typo, which is easily caught in some languages, can be very difficult to find in others.

You might be surprised how many times you have to look at the code to even notice this problem, even when you know the problem is in this unit. A common problem in proofreading is that you see what you expect to see not what you actually sea (sic).

Third Theorem of Programming Languages
My third theorem goes as follows: No single programming language is equally suited to all programming tasks.

If all languages contained the exact same set of abstractions, they would differ only in minor syntactic ways. Then all languages would be equally applicable to all programming tasks, and we could analyze languages merely by comparing the effectiveness of the syntax chosen.

Things to consider when choosing the language to use:

• Normal stuff—performance, compatibility with existing code or libraries, …
• Size of the team—I can staff a large project with competent Java programmers much more easily than with similarly capable C++ programmers (measured in how likely the code performs the intended action without unintended problems).
• Size of the code—a short script allows you to forgo many of the heavy-handed mechanisms or processes that are helpful in larger programs. Some say that the usefulness of Perl decreases rapidly as the number lines in the code increases.
• Longevity of the code—if the code is to be used and maintained for a long period of time, coding in a language that clearly expresses intent is much more important. See the Second Theorem of Programming Languages.
• Domain—what does the program do? Certainly I would make a different choice in languages if I need to write a real-time operating system kernel versus writing a GUI-oriented web application.

Tool Support
One last thing to consider when choosing a language is tool support. The right editor can often make a bigger difference in your productivity than the syntax of the language. Can an editor readily provide completions for the language you are considering? If you are typing every character in your program, you aren’t nearly as productive as someone who makes effective use of completions. How easy is the language to parse? Can a program readily provide type analysis? This will determine how easily tools can be developed to support the language.

At SlickEdit, we’re in the business of helping you write code. I speak from experience when I say that some languages seem to go out of their way to make it hard on us. Whether you’re picking the language for your next project or designing a new language, please keep these principles in mind.

–Scott Westfall