I expect this one will upset a lot of people. It’s also a lie. But not as big a lie as you might think.
Fighting the Language
When I was starting out in programming, there was a statement that was pretty popular: “A bad programmer can write Fortran in any language.
” This was not really meant to suggest that Fortran was the worst language you could use, or that anyone programming in Fortran was a particularly bad programmer.
It was really a statement about certain kinds of programmers who write in any language as if it is the language that they used first or are most comfortable with. They never learn to write in the idioms and style of the new language. This makes any code they write hard to read and maintain. This is not an indictment of the language in question, it’s a mistake on the part of the user. In other contexts I have found it more useful to describe this as an accent (e.g. writing Ruby with a Java accent).
Working With the Language
A good programmer can write good code in almost any language. If the programmer is new to the language, they may not write idiomatically at first. Over time, a good programmer will learn the idioms of a new language and write code in a way that is more natural in that language.
I don’t want to say that anyone who fights the new idioms at first is a bad programmer. We tend to stick with what’s comfortable when we can. But, a good programmer will see the constructs that work particularly well in each language and begin to incorporate them into the code they write. It means you are fighting the language less, and it will be easier for others to read your code.
Turing-Complete
All general purpose programming languages are Turing-Complete. So, anything that can be expressed in one language should be expressible in another. In general, languages don’t differ in what they make possible, they differ in what they make easy.
When someone designs a programming language, they tend to have certain problems in mind or a particular approach to solving problems in mind. They will tend to focus that approach or solving those kinds of problems. Naturally, what the language designer focuses on will be more thought-out and easier to do. Problems or approaches that the language designer wasn’t as interested in may be made a little harder or more awkward, because they weren’t the designer’s focus.
Some decisions will limit the kinds of problems that a reasonable to solve in a language. Any language with a large run-time component, including languages using garbage collection would not be suitable for low-level or resource constrained environments. Simply because the run-time cost is too high. It is very hard to build large systems in a language without namespaces, because of accidental name collisions and the difficulty of localizing memory access.
Community
Another way that languages differ is community. Some languages develop a larger community of other users. This may be because of the personality of the language designer, or the kinds of problems that the language often is used to solve, or because of a big company or group funding resources for the language.
The philosophy behind the language (or its designer) can also help to distinguish a language. Sometimes the philosophy is just the programming paradigm, but often there is something more gut-level.
- Ruby: “optimize for programmer happiness”
- Perl: “there’s more than one way to do it”
- Python: “There should be one — and preferably only one — obvious way to do it”
- Many languages: “everything is an object”
This philosophy may resonate with a programmer on an deep emotional level. If it does, the language may seem “right” and morally better than other languages. Unfortunately, that is subjective, not objective. It’s also the cause of many language holy wars.
Beauty
Of course, no rational programmer would ever make a decision on the beauty or ugliness of a programming language. Honestly, it’s just that that language is “write only”. (smirk)
Most of the time that people claim that a language is hard to read or “write only”, the issue boils down to familiarity. Most people in the United States would find text written in the Greek alphabet or Cyrillic as completely unreasonable. Programming languages that use very different conventions than you are used to are harder to read, until you become accustomed to them. They may never be as comfortable as your favorite, but that doesn’t prevent them from becoming usable.
Language Doesn’t Matter
There are some cases where some fundamental technical requirement prevents the use of a language. Examples like a large run-time for an embedded systems project, interpreted language for a hardware device driver, etc.
In most other cases, the language doesn’t really matter. Tooling or library support may have a bigger impact. As we stated earlier, some languages may make solving your problem easier, but you could still solve it in another language. The more important issue is how does the language fit with how your team develops software, and whether it conflicts with requirements by your company.