I don't know that he's wrong, but there's a major premise in there that's easy to miss if you aren't watching for it: "Whatever language I come up with there sh

I don't know that he's wrong, but there's a major premise in there that's easy to miss if you aren't watching for it: "Whatever language I come up with there should be a way to efficiently evaluate it, that's pretty important if you're a systems person." It makes me think that he mis-stated his case slightly. In an ideal case, SQL's encapsulation supports its declarativity. In practice, it's riddled with holes. Some of them, like micro-managing the indexing scheme, aren't part of the basic idea behind relational databases (Codd's paper doesn't even mention them, IIRC), but have become so deeply engrained in our expectations of how a relational database should work that we don't even recognize them as a compromise on the idea behind the relational calculus anymore. But they're generally either deeply non-declarative, or lay bare some pretty deep implementation details of the system, or, in the case of index optimization features, both. So, what I'm guessing is really going on here is an incomplete observation that there's a "pick two" situation here: You can only have two of performance, declarativity, encapsulation.