Programming language snobs are penny pinchers. That’s a tough sentence to write for some that just finished holding a workshop to help people learn Lisp of all languages. Why would I make such a bold, inflammatory statement? (No, not to troll. Most of the criticisms in this article are aimed at myself, based on my own actions over the last few years.) I had an unpleasant realization after listening to two excellent talks that developed this idea planted in my head by Raganwald with this post he quoted a few months ago:
“…you can count the number of games written in a purely functional style on one hand. Is it that language tinkerers are less concerned about writing real applications? That they know you can solve any problem with focused grunt work, but it’s not interesting to them? That the spark and newness of a different language is its own reward? Either way, the BASIC programmers win when it comes down to getting projects finished.”
â€”James Hague, Slumming with BASIC Programmers
The gist of the post is that uber-languages like Lisp, Erlang, Ruby, and even C are worlds ahead of BASIC, but somehow a group of Neanderthals put down their clubs and wiped away their drool long enough to write a slew of various and impressive computer games using BASIC. OK, he didn’t say that, his exact words were “…largely written by people with minimal programming background.” I was just translating for the language snobs out there. But then, mid-gloat, he hits them, you (even me) with that damning quote above about getting projects finished.
Ouch. I was looking back at what I’ve produced over the last few years (both personally and professionally) and the list is pretty short. Maybe it’s a byproduct of too much school, or not being able to take things apart as a kid, but I tend to default to waterfall mode. Research, plan, gather as much knowledge as possible to build a mental model so complete that the perfect solution will fly from my fingertips like a glorious winged Viking ship sailing off to enjoy another toasty Greenland winter. Alas, I usually just end up learning enough useful knowledge about a subject to write and converse about it but not enough to work with it. Hence my dusty portfolio.
Take my involvement with Lisp, for instance. I’ve become a slightly respected name in the (admittedly small) Lisp community because of what I’ve written about history, Emacs and SLIME, how to learn Lisp, how to setup an environment, access documentation, and the right mindset for developing in Lisp. Heck, I even organized a workshop to help other people learn Lisp! Notice all the working software on that list? [Cricket, cricket, cricket...]. What does all that have in common? It’s all preparation for the day when I’m going to write all this great software in Lisp. Oops.
So why, when I’ve been using C# and .Net at work for 5 years now, am I so worried about having the perfect Lisp environment and knowledge of how to use it? So that when I finally get around to writing something, I will be able to do it quickly because of all the power at my disposal. That’s right, I don’t have a lot of time to spend, so I’m very, very, very gradually building up my ability to write software quickly. That certainly makes more sense than writing a little software at a time, right?
Where was I? Oh yeah, OOPSLA.
The ACM SIGPLAN Conference on Object Oriented Programming, Systems, Languages, and Applications (OOPSLA) is one of the premier conferences on software development, and despite the title, doesn’t have much to do with object-oriented programming anymore. Twenty years or so when it started, OO was hot, cutting edge stuff, and as time marched on, the conference people decided that rather than stick with objects, they would stick with the hot, cutting edge. For the highly regarded 2007 conference, they recorded their keynote speeches and made a podcast out of them. What outstanding marketing! (The Singularity Summit did this too.) I was interested in OOPSLA because of what Dan W. and others had written about it, but getting to hear the actual speeches put this year’s conference in Nashville at the top of my wishlist.
[Note: if anyone is looking for a way to feel really good about themselves, why not sponsor my trip to OOPSLA 2008? No, really, please! I promise to take pretty pictures and write lots about it.]
Two of those keynotes made a huge impression on me, to the point where I’m scared what will happen if I listen to the 5 remaining talks. First, in Second Life: The World’s Biggest Programming Environment (download 40.5 MB mp3), two Second Life employees gave a similar argument to Hague’s above. They started out by trashing the Second Life scripting language (LSL) and sharing details of its sordid past. For instance, all scripts have to run in a 16K virtual machine. This virtual machine was written in one week, replacing the first version that was written in one night. There is no IDE, no debugging, no tracing – all editing happens in-world. Most appealing language features are missing, and the language isn’t even pretty. Bleak, huh? Well, there are hundreds of thousands (millions?) of people writing scripts in LSL, with over 2 million simultaneous scripted objects and over 2.5 billion lines of code in this terrible language. Why do people put up with it?
Because the payoff is so rewarding – there is a whole world full of animated objects scripted by participants. People love to write in it since there’s immediate, tangible feedback for doing so – you literally change the world your character lives in!
The second talk was by Kathy Sierra, called (no surprise) Creating Passionate Users (download 38 MB mp3). I’m a confessed Kathy Sierra fan, so I looked forward to getting reacquainted with old Kathy. Her remarks enlightened and expanded the points made by the Second Life people – people want high bandwidth experiences, they want feedback, they want their effort to produce results! Why was that such a revelation to me? I mean, I got it, but I didn’t get it until I heard her say it. There are so many examples of this principle:
- people use PHP because it’s installed on every web host in the multiverse, so they don’t have to muck around much with deployment
- people use Ruby on Rails because they can make a blog in 15 minutes
- people use Agile because they always have working software and can see changes immediately
- people don’t use Lisp because there’s no easy download
- and people use BASIC and LSL because they want to get stuff done
That brings me to the two parts of my inflammatory title:
Language Snobs stress the superiority of one programming language over others. Some languages are extremely guilty of this (Lisp, SmallTalk, Python, Ruby, Scala, Haskell, etc) while others aren’t (Java, C#, VB, BASIC, PHP, Perl, C, etc). The snob languages talk about why they’re so great, and the other languages just point to what has been written in them as proof that they’re great (or at least good enough). Granted, this definition isn’t perfect; Lisp has everything on my Lisp Companies page to brag about, but it seems small in comparison to the hot air that gets circulated (including by me) in its favor. I think Ruby is crossing over into the non-snob category, based on the massive popularity of Rails and all of the sites written in it.
The important point is that the language snobs aren’t wrong! There is no denying that abstractions are useful, that more powerful tools help, and that a sharp, well-trained mind can accomplish things that a simple one can’t. The dearth of machine language and assembly written nowadays is proof of that. But the language snobs are working in the realm of what’s theoretically possible, what can be accomplished in the best possible conditions. This could be in small startups founded on the best principles, or on large companies like Google and ITA that have kept that environment as they’ve grown. But most people and most business don’t operate anywhere near that theoretical maximum, so the bulk of the software gets written by the competent mean, by the bulge in the middle of the standard distribution. Language snobs are also working in the future, since advanced topics tend to trickle down over time (hence the rebranding of OOPSLA).
A penny pincher is someone who is frugal, who “knows the cost of everything and the value of nothing”. Language snobs know what languages are most powerful, so they are loath to use anything less than the best. They don’t want to endure the cost of code duplication, cut-and-paste, reading un-refactored code, leaky abstractions, etc. Everything has to be perfect, and when you add up those little bits of perfection, you get something great.
But life, business, and software are full of trade-offs. If you can accept a little imperfection here, some cruft there, and sloppy duplication there, they you can hire from a bigger pool of employees, deploy to a wider range of platforms, hit more markets more frequently. The key point that the penny pinchers miss is that while using inferior tools has a cost associated with it, so does not using those tools. The important thing is to Always Be Shipping.
It’s not only language snobs that are guilty of penny pinching. A classic example of the non-snob language fans pinching was in reaction to Fog Creek’s Wasabi programming language. For anyone who missed it, here’s the first mention:
This simple comment set off a crazed irrational firestorm of criticism, cataloged here. People even thought it was a joke! These people were pinching pennies because they didn’t realize that writing a compiler where you control both the input and the output isn’t that hard if you have smart people working for you. Joel wrote a response to the Wasabi firestorm explaining all this:
Since we are not blub programmers, we like closures, active records, lambdas, embedded SQL a la LINQ, etc. etc. and so those are the kinds of features we put into Wasabi…
Most people don’t realize that writing a compiler like this is only about 2 months work for one talented person who read the Dragon book. Since the compiler only has one body of code to compile, it is much easier to write. It doesn’t have to be a general-purpose compiler. It doesn’t have a math library, for example…
And we have the ability to add any feature to the language that we want easily… this is the same power Paul Graham talks about in On Lisp, the power to invent new language features that suit your exact application domain. Lisp does this through a mechanism called macros…
He also explains the very sound business reason for it, balancing the cost of developing the Wasabi language and compiler (smaller than people think) against the support cost of setting client servers up with .Net, Mono, or PHP on Windows (larger than people think) and the lost opportunity cost of people that won’t even consider buying your product because they don’t support your language (MUCH larger than people think). 37signals at least acknowledges this foregone opportunity, but 37signals has WAY more business savvy than people give them credit for. And despite the bashing Joel gets for writing “a crappy bug-tracking program for stupid windows programmers” or something like that, he has managed to increase his revenue by 17x since September 2003. There’s a very important lesson to be learned from two very successful companies – make balanced strategic decisions, but make sure you understand the consequences of doing so.
It turns out that this wasn’t much about languages at all; languages was just the topic that springboarded the idea. The real message is about people, passion, results, business, and most importantly, balance. If you find yourself focusing too much on one single aspect of your product or your business, there had better be a good reason. If you love your language because you can mold it (Lisp), or because strict functionality and a strong typing system prevent errors (Haskell, OCaml), those features had better be extremely important to the problem you’re trying to solve. If you’re running a software business and all you do is code, you’d better be getting your first version ready to release as soon as possible. All successful companies are balanced companies. If you’re too focused on one area, you’re guilty of premature optimization and unless you are ready to make some painful adjustments, you should get comfy on your local maximum.
UPDATE: Joel and Jeff at the stackoverflow podcast had a strikingly similar discussion in Episode #8. Joel said that for the niche tools (that’s how he characterized what I called “snob languages”), there are two reactions to the pain that the limitations (documentation, fewer programmers, less mature tools, etc) cause: admitting that your platform just isn’t that good yet, or convincing yourself that your platform is so good that it’s worth the pain because it makes you so much more productive. Choosing the first option causes jarring cognitive dissonance whereas the second choice feels good, so these niche languages and platforms have vocal, fanatic followers who have convinced themselves that they are using the Good Lord’s Own tools. If you’re using a snob language but still think you’re rational and open-minded, listen to it or read the transcript (not finished yet but will be soon). It’s between 6:57 and 16:56.