There’s a lot to disentangle from this tendency, which seems to continue unabated even today (and at CDG, &c). I think there are two beliefs that are often confused when advocating a “4GL” or similar. The first is the belief that computers are fast and compiler theory is improving, so the programmer need not be responsible for squeezing in every “ounce” of optimization. It’s sad that, still, that doesn’t seem true for many common domains—it’s disheartening that in 2014 I need to be careful with memory/CPU/bandwidth when doing simple a/v manipulations. But there’s a second belief, which is often implicit and which is more troubling in my view, which is that we will be able to dismantle the ladder of abstraction, if you will, once we’ve reached the top, because everything we need will be in the attic. Or, to mix metaphors:

I love in Bret’s essay how often the ladder is used in both directions and the “spirit of abstraction” is beautifully characterized as “[omitting] some details in the interest of exposing patterns.” When you put it that way, it seems obvious: (1) that abstractions are great, useful, quotidian, &c; and (2) that you’ll usually want the details back eventually. Open source is appealing, at least in theory, because the abstractions provided are “descendable.” Unfortunately it’s painful to go down into the Linux kernel, &c. I find that HLLs, DSLs, dataflow block environments, and the W3C/WHATWG all tend to assume that they’re making a binary break with the past: ascent! I keep looking for a way to design for descent—start “high” and rough, get into the details as needed—but don’t have many good examples where that’s encouraged by toolsets.