Tuesday, March 27, 2012

Programming language as amplifier, or not

Studies have shown that different programmers perform at different levels. Not all programmers are alike, not even programmers with the same job title. The difference between a really good programmer and a really poor programmer has been measured to be a factor of twenty-five!

What I have not seen is a study of programming languages and their role in these differences.

I believe some programming languages to be equalizers and other programming languages to be amplifiers. Some programming languages can make programmers better, or at least allow them to be more productive. Other programming languages limit them, bunching programmers together.


I noticed the difference in programming languages when I shifted from C to C++. The C++ language was more than a "better C" or even a "C with classes" arrangement. It allowed one to use more sophisticated constructs, to develop programs that were more complex. As some folks said, "with C you can shoot yourself in the foot, with C++ you now have a machine gun".


C++ is a powerful language, and good programmers can use it to good effect. Poor programmers, on the other hand, frequently end with messy programs that are difficult to understand and maintain (often with defects, too).

C++ is an amplifying language: good programmers are better, poor programmers are worse.

But that does not hold for all languages.

FORTRAN and COBOL are equalizing languages. (That is, the early versions of these languages were equalizers.) They reduce the difference between good and poor programmers. The structure of the languages constrains both types of programmers and the code is pretty much the same, regardless of the programmer's skill. (Later versions of FORTRAN moved it closer to an amplifying language.)

Some other programming languages:

Assembly language is an amplifier. While the "trick" to good programming in assembly language is understanding the processor and the instruction set, assembly language programming is such that a good programmer is really good and a poor programmer has a very difficult time.

Pascal is an equalizer. It has enough "guardrails" in place to prevent a poor programmer from making a mess. Yet those same guardrails prevent a good programmer from truly excelling.

Perl is an amplifier. Python is an amplifier. Ruby is an amplifier.

Java and C# are equalizers, although they are shifting towards the amplifier end of the spectrum. Sun changes Java and Microsoft changes C#, and the changes add features (such as lambdas) which become the machine guns for shooting yourself in the foot.

Viewed in the light of "amplifier" or "equalizer", one can assess programming languages for risk. An amplifying language can allow programmers to do wonderful things, but it also allows them to create a  horrible mess. When using an amplifying language, you have to take steps to ensure the former and prevent the latter. An equalizing language, on the other hand, limits the possibility of mess (while also limiting the possibility of something wonderful).

But if you don't care about something wonderful, if you want to deliver a known quantity on known schedule (and the quantity and schedule are reasonable), then an equalizing language is better for you. It allows you to hire not-so-great programmers and you know that they will delivery something of reasonable quality.

If my reasoning is true, then we can expect small shops (especially start-ups) to use the amplifying languages. They have to, since they need above-average results. In contrast, large conservative shops will use equalizing languages. They will (most likely) be unwilling to hire top talent and will opt for mediocre (but available) personnel. They will also (most likely) be unwilling to educate and develop

Capabilities of the language are one factor among many. The C++ programming language become popular not because it was an equalizer (it's not) nor because it was an amplifier -- it became popular because it was the way to develop applications for Windows and Microsoft supplied good tools for it. That is no longer the case. The primary language for Windows applications is now C#. The primary language for iOS applications is Objective-C. The primary language for Android applications is Java. Yet programs for all of these platforms can be developed in other languages.

With today's multi-language market, expect companies to select the tool that suits their needs. Companies that need top-level performance will pick the amplifying languages. Companies that need certainty and want to avoid risk will pick the equalizing languages.

No comments: