Programming in a Vacuum
August 2006 (master's student)
I've read my fair share of Internet rants and raves about programming, and many authors seem to be obsessed with one thing: programming languages. Their articles obsess over topics such as what programming language is the best, why certain mainstream languages (Java) lack certain features (closures) that other languages (Common Lisp) have had for decades, why certain languages are for smart people while other languages are for the dumbed-down office drone masses, and so on and so forth. The authors typically use 10-line toy examples to illustrate how language X (<insert your favorite functional language here>) can do something that language Y (<insert some popular object-oriented language here>) cannot do or can only do awkwardly, and then it's like BAM! A HA! Language X is far superior to language Y, and people only program in language Y because their pansy training hasn't taught them how 'real programmers' tackle 'real problems'. Although I agree with many of these rants (e.g., I do feel that certain languages are more expressive or powerful than others for performing certain tasks), I think that they all make one misguided implicit assumption: that we are all programming in a vacuum.
In the real world, we write programs for a purpose, and we are constrained by our purpose—What is this program supposed to do? What is the target operating system or hardware? How much effort can the user be expected to invest in order to install and to run this program? Most importantly, what libraries are available to assist me in writing this program? Libraries are key. Think about it: most programming tasks involve organizing and gluing together library code; most programming tasks do not involve the creation of novel algorithms that compel the use of sophisticated programming language constructs (emphasis on most—I do admit that the benefits of a more powerful or applicable language are greater when one is trying to solve harder problems).
Before I begin a programming project, the first question I ask myself is not what programming language I should use, it's what environment I am targeting. Is this application going to be for Windows, Mac OS X, Linux, all three? Is this going to be a server-side web app? Client-side? AJAX? Other buzzwords? What libraries can I expect users to have available on their machines, and would my users know how to install additional libraries if necessary? Then I need to choose my development platform, taking into consideration the libraries available on both my development and target platforms that can perform tasks that I don't want to (or, more likely, don't know how to) hand-code myself.
No matter what, though, the decision of what programming language to use comes last; it is a consequence of the environment, not the initial motivation for programming. Of course, there are exceptions; when I am learning a new language, it is the motivation for me to program. For example, I might want to "write a GUI app. using Python in an object-oriented manner" or "learn about functional programming using OCaml by writing an address book app." In the real world, however, if programming is your job, your boss will never tell you, "Go ahead, Dilbert. Choose your favorite language first, and then we'll tell the customers what environment (e.g., OS, hardware, application style) they are restricted to because it might be too difficult to support certain environments using the language you're going to choose due to a lack of libraries, etc."
For example, some say that Common Lisp is the most powerful programming language ever, and I accept that statement on faith alone because really smart people tell me that it's true. But if someone wanted me to write a customized GUI calculator program for Windows XP, I couldn't even begin to imagine how to do it in Common Lisp simply because I have no clue whether there are Windows GUI widget libraries with Common Lisp bindings (even if there were, it would probably take me days of fiddling in order to figure out how the damn thing worked, and I don't know how to make my users install those libraries on their machine). However, it's almost trivial to write this program in Visual Basic using the Microsoft-provided IDE—drag some widgets on a form, add in chunks of VB code for event handling, and BAM! Out pops an .exe file! I can even add a pretty icon if I want. My friend can double-click on that icon and have his calculator execute with no hassles! I don't have to worry about library issues because everyone running Windows has the libraries required to run an executable built using the Visual Basic IDE. Does this mean that Visual Basic is a more powerful or expressive language than Common Lisp? Of course not! In a vacuum, Common Lisp crushes Visual Basic bar none, but for this particular application, VB got the job done much quicker with more reliable results.
If certain languages are theoretically superior to others, then why do so many people use inferior languages? The snobs would like you to believe that it's because most programmers are dimwits who can't handle the power of lambda (or something along those lines). Most programmers today only know Java and have their heads filled only with Design Patterns. Most programmers couldn't write elegant recursive solutions to neato toy math problems using higher-order functions. etc., etc., etc. However, the truth is that so many people use so-called inferior languages because they have already attained critical mass in the market. It's positive feedback—when a language begins to grow popular, more people will write libraries, toolkits, and development environments for that language, then more programmers will use it because it's now more convenient and easier to perform common tasks thanks to the increased tool support, and then the language gets even more popular, even more people write libraries, and so on and so forth. This shouldn't be news to anyone. It happens all the time in other products. What's the dominant personal computer operating system today? Hmmm ... positive feedback? Critical mass?
If we are all programming in a vacuum, then of course we should always use more powerful languages over less powerful ones, but the truth is that when programming in the real world, the environment (not one's own abilities or lack thereof) is the primary factor in dictating one's choice of programming languages. Ask uber-stud hackers working together to build a boring database application for a financial company whether they like using whatever language or environment their company made them use, and most will reply "no way, man, this major suXoR! I'd rather be writing one-liners in awk or Perl d00d!" But they have no choice but to use major suXoR languages because the libraries, infrastructure, and toolkits are available to facilitate them in building the kinds of applications they get paid to build. Of course, being the industrious hackerz that they are, they could just write this damn thing from scratch using an uber-powerful language that's supposed to make them 100 times more productive than the lame-ass language they're forced by their pointy-haired boss to use, right? Wrong. Libraries. Libraries. Libraries. For most programming tasks, if the appropriate libraries aren't available, then there is no plausible way that you could just 'roll your own' from scratch. Even uber-hackerz must stoop down to using whatever inferior language has the appropriate libraries for their programming task.
Ok, time to wrap this up. My main take-home message: The programming environment (development/target platforms, intended audience, and most importantly, available libraries) is the primary factor in determining one's choice of programming language. This article is not a defense of so-called inferior languages, it's just trying to raise a point that I have not seen others address. So, if you are planning to rant about language X or feature Y or syntactic element Z, try to at least think about the fact that most people don't care to know about X, Y, or Z because they are not even able to choose the programming language they work in ... their environment chooses for them, and they simply have to make the best of what they are given.
My other take-home message (crap, this turned out to be longer than my first message): Programmers should not define their skills primarily by the languages they know how to program in. Rather, they should define their skills primarily by what kinds of programs they have written. How many times have you seen on people's resumes (including my own, I must admit) a laundry list of programming languages that the candidate supposedly knows? But what does it mean to know C++? Or Java? Or Python? Does it simply mean that one understands the language syntax, semantics, and some programming paradigms that the language fluently supports? Does it mean that one has done a class assignment using that language? What use is knowing a dozen programming languages if one has never used any of them to write programs that weren't for class or for examples in an instructional book?
Languages by themselves are not programming skills; the skills arise from the experience of writing software for particular applications. The kinds of programs one has written are far more important than the kinds of languages one knows. For example, job candidates' skill descriptions such as "I've written programs for Pocket PCs using Microsoft tools, and the language happened to be C++", "I've performed lots of network and system administration tasks, and the language I found most pleasant to use for those tasks was Perl", or "I've written an e-commerce system for Acme Widget Co., and I happened to use PHP and Java" are much more convincing than "I know C++, Perl, PHP, Java, and a bunch of other stuff ..." The language should almost be an afterthought, a mere consequence of the application that one must create.
In a vacuum, the only thing that should matter are the languages themselves, but nobody (except for those who are learning to program or trying to make cute toy examples) programs in a vacuum, so we should always strive to seriously take the environment into account when thinking about programming.
Last modified: 2006-08-09