What Makes a Good Programming Language?
What makes a good language? It depends on what you like in a programming language, of course. If you enjoy functional programming, you probably won’t be happy with Java. If you dislike managing memory, certainly you should avoid C. But there are some features that are shared by a large family of languages, and they make a good case of what might be good features for all of them.
Conciseness is a good case. There are extremes in conciseness that have been observed throughout the short history of computing. For example, it is hard to imagine something more terse then APL, or one of its modern equivalents, such as the J language.
On the other hand, the extreme verbose languages have always been among us. COBOL was predicated on the assumption that more was better — and it ended up that any reasonable COBOL program is machine generated.
I am the kind of person that likes to err on the side of terseness. In my mind, programming ideas are terse anyway; I am always trying to reduce algorithms to its simplest form. And when you learn a language well, it is better to read less than more — most professional programmers agree with this.
Another issue I have is with languages that don’t give you options when a common problem happens. Programming languages should be designed to be flexible, not the other way around — it is in the spirit of programming. For example, Java requires you to write code that is spread in as many directories as you can create. The designers of the language tied access to symbols to the directory where the symbol lives. This is the kind of thing that makes a language to look amateurish, even though there is a huge amount of work done in Java — every one has to bow down to a wrong and inflexible decision.
The other thing about inflexible languages is that they need tools to be used. The same way you need a code generator to use COBOL, you are required to use an IDE to generate boilerplate code in Java, as well as to navigate its complex tree of source directories. No wonder why the industry loves this kind of languages: between virtual machines and IDEs there is a huge market to be explored.
As for me, when I have a choice, I always try to avoid languages that make me repeat the same old mistakes. If you don’t have the ability to define a behavior directly in the programming language, then you are condemned to repeat the same mistakes (or at least required to protect against them in some way).
Similar Posts:
About the Author
Carlos Oliveira holds a PhD in Systems Engineering and Optimization from University of Florida. He works as a software engineer, with more than 10 years of experience in developing high performance, commercial and scientific applications in C++, Java, and Objective-C. His most Recent Book is Practical C++ Financial Programming.
