The problem with arguments about the best programming language is that any claim you could possibly make in favor of one language is fraught with innumerable exceptions that water down the whole argument and make it irrelevant. Context effectively kills any best programming language argument. As a result, the arguments for or against a language tend to be vague and allude to nebulous ideas of features, productivity, expressiveness, speed, safety, or simplicity. Once the debaters try to get into specifics, it's easy to find exceptions and counterpoints that poke holes in every argument.
When programmers bring up language features in an argument, it's generally safer to stick to the argument that a language is better because it has more features or better features. As soon as you try to point to specific features, those features expose the reality of trade-offs. Is it better for a language to have garbage collection or direct control of memory? Is dynamic or static typing better? Should the language be primarily procedural, functional or object-oriented? What about concurrency support, first-class functions, metaprogramming, generics, blocks, or closures? Every additional feature adds complexity to the language and cognitive load to the programmers that use it. I like the quote in this poster of programming paradigms, "More is not better (or worse) than less, just different."
It's commonly taken for granted that high-level languages are better for programmer productivity, and we continue to pursue higher levels of abstraction. But sometimes programming in lower-level languages can be more productive. Even seemingly safe arguments like, "No one still codes in assembly," aren't always true. Assembly may seem like a dead language that is only useful as a good learning experience, but there are still real-world cases where it is necessary. I've coded in assembly recently, at least the TI DSP form of it, because when doing DSP embedded programming, sometimes I needed total control over the algorithm and the hardware it was running on to fully optimize it. Being able to drop down to assembly for tight algorithmic loops has a tremendous impact on performance for data processing.
Taking the slightly different tack of arguing that some programming language is more expressive or powerful than another language runs into the same issues. I've seen claims of every language in common use (and then some) being tremendously expressive. It doesn't matter if it's C, Ruby, Haskell, or LISP. Every language is really, really expressive. And everyone is right. Each language is expressive and powerful in the domains that it's good for. The bottom line is that it depends on the context.
Another favorite argument is the speed of a language, and it's also meaningless when taken out of context. If the program isn't fast enough it's most likely either because of a design issue with the architecture of the program, or it's a bottleneck in a tight section of code. If the problem is the former, it's not the language's fault, and if it's the latter, just write that loop in C and call it from your preferred language. For most of any code base, it doesn't matter what language it's written in when it comes to speed.
Of course, the argument that language speed doesn't matter doesn't hold up in all cases, either. If you're writing for an embedded system or HPC (high-performance computing), you may not be able to use an interpreted language and ever get enough performance. That's fair, but those programmers aren't debating about whether to write in Ruby or Python, they're debating whether to write in C, C++, or maybe Lua. I fear I'm getting into the kind of arguments that end up proving my point. There are a bunch of weaknesses to the speed argument, and it's very context dependent. Any smart programmer can easily poke a bunch of holes in it, and they'd be right for the cases they're thinking about.
Programmers also make a whole host of arguments that are generalizations of specific problems they've struggled with. Most of these arguments boil down to a language being safer than others, and if they had just used that language, they could have avoided a world of hurt. They end up trying to prove a general rule with anecdotes. While the pain of the experience that lead to thinking a particular language was unsafe was surely real, generalizing that pain to apply to more circumstances than it warrants doesn't prove that a given language is broken. Even bringing up examples of some project failing or a company going out of business because of a language choice doesn't prove that the language is not production-worthy. Any reasonably popular language also has numerous examples of successful code running in the wild. Bugs happen and good programming practices help in any language.
A particular example of an impossible-to-win argument is that it is impossible to write safe C code. There will be a group of programmers that will agree with this statement and then a group of programmers that will vehemently disagree. The latter group will point to one or more instances of safe C code and the debate will devolve from there. The whole argument ends up being pointless because of a variety of reasons. To name but a few of them:
- For plenty of programmers, C is one of a few options because they are working with legacy, performance-critical, or embedded systems.
- The people making decisions about which language to use sometimes aren't aware of the arguments against certain languages or are basing decisions on other factors.
- Programmers need to gain enough experience to write safe code in any language so language choice is only one, possibly minor, factor in writing safe code.
In the end a lot of these arguments seem to be implicitly claiming that if we could only get everyone to program in language X, then all of our problems would be solved. That mentality is both wishful thinking and missing the real issues. Programmers can and will write bad code in any programming language. At the same time, great software that adds tremendous value can also be written in (almost) any programming language.
With such a tremendous amount of overlap, why waste time debating what the best programming language is? With every new language, I learn new ways of solving hard problems and the debate about which language is better becomes less interesting. Discussing what the great features of programming languages are or how to make languages better or how to write better code in a given language are much more interesting points of discussion. The best programming language may not exist, but there are plenty of good ones out there for writing great software.
No comments:
Post a Comment