Home > Articles

  • Print
  • + Share This
From the author of

What Is a Good Programming Language?

So is it the programming language itself that is spoiling my heaven? Before addressing this point, let us step back and consider how we should evaluate the relative merits of different languages.

There are several measures of a programming language's effectiveness. First, it must be fit for purpose; it must have access to the machine resources that it needs to do the job. Languages designed in a university for students have often failed in the commercial market simply because they didn't have access to all of the system software facilities required for the job at hand. But "purpose" is wider than just functionality. If the purpose is to provide a high-performance graphics system, then you need a language that is capable of generating high-performance code.

As I noted earlier, COBOL is a perfectly capable language for writing commercial transaction processing applications, but it's not a good language for writing system software.

A second test of a language's effectiveness is the lucidity in which it can express a solution. Lucidity is about how long it takes from picking up a piece of code to understanding what it does. Lucidity is a combination of conciseness and readability. Conciseness by itself isn't enough. There was a language (perhaps still is) called APL (standing for "A Programming Language"). APL was fantastically concise and almost unreadable, mainly due to the use of a wide repertoire of special characters. (It helped the programmer if you had a special keyboard). The joke doing the rounds at the time was that APL was a write-only language.

A third test of a language's effectiveness is the likely ramifications of change. By that I mean that, if you find you have to make a change, how much code do you have to change, how dispersed is this code, and how hard is it to find the code?

A fourth test of a language's effectiveness is its "accident proneness." This measure is about bugs. A language can help prevent you from writing bug-ridden code; that's what type-checking is all about. A language should also help make it easy for you to find the bugs, although this is probably another manifestation of lucidity.

For businesspeople, these tests might look rather abstract; what they are after is speed of application development and ease of learning. I contend that application development using a language that does well in my four tests will be faster and more accurate than a language that does badly in these tests. There is one simple reason: In programming, you write code once and read it many times. But you have to remember that a language designed for a narrow range of problems can always be simpler, more concise, and easier to learn. This is exactly the strength of 4GLs such as EAE from Unisys and Natural from Software AG.

  • + Share This
  • 🔖 Save To Your Account