james mckay dot net
because there are few things that are less logical than business logic

Programmer jargon: Blub

About a month or so ago, elite C# gurus such as Eric Lippert and Jon Skeet were discussing the new async and await keywords that are forthcoming in C# 5. Eric Lippert introduced them with a series of blog posts on continuation passing style programming that I haven’t yet got round to reading properly.

People who are into continuation passing tend to wax lyrical about it, portraying it as the latest cure for cancer. But I’m wondering just how much of my time I should spend on it. To me, it looks a bit whacked out — isn’t it just some kind of nonlocal goto, and aren’t goto statements considered harmful? How will it help me write code to keep the Great British Public informed about what their elected representatives are discussing in Select Committees?

You never know. No doubt in a few years’ time, I too will be passing continuations around like sweets at a children’s party. I had similar thoughts a few years back when I first read about LINQ. Why would anyone want to embed SQL statements in their C# code, I thought? It sounded a bit like the bad old days of tag soup in classic ASP. But nowadays I use LINQ all the time and I’ve long since figured that LINQ is not LINQ to SQL. In fact, I don’t see how you can get anything done without LINQ. It’s just so much cleaner than writing a whole bunch of for loops. And it gives you lazy evaluation, which can give you massive performance benefits if you use it properly.

This is a common paradox in programming. Once you get to grips with a new programming language feature, concept or tool, you wonder how on earth you managed to write any code at all without it. But on the other hand, when you look at all the concepts, features and tools that people are waxing lyrical about in those terms, they all look weird, if not completely scary. And when you wax lyrical about something or other, as sure as eggs are eggs, someone will tell you your tool is the weird and scary one.

In his essay, “Beating the Averages,” Paul Graham calls this the Blub Paradox:

Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.

And in fact, our hypothetical Blub programmer wouldn’t use either of them. Of course he wouldn’t program in machine language. That’s what compilers are for. And as for Cobol, he doesn’t know how anyone can get anything done with it. It doesn’t even have x (Blub feature of your choice).

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he’s looking down. Languages less powerful than Blub are obviously less powerful, because they’re missing some feature he’s used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn’t realize he’s looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn’t even have y.

I guess the best definition of “Blub” is the collection of programming language features, concepts and tools that you know and understand — or at least, that you can see might come in useful, so you really ought to get round to learning about them. It’s what makes sense from your vantage point. But when you look up and see someone waxing lyrical about something unfamiliar, don’t just write it off as weird. They may quite possibly be right.