a companion discussion area for blog.codinghorror.com

All Abstractions Are Failed Abstractions


You say all abstractions are leaky. This is true but some abstractions are more leaky than others. You don’t explicitly say it, but SQL is in itself a very leaky abstraction, too leaky. It’s the big mistake of backend web development. Why was one seemingly identical query much worse than another? SQL is an abstraction over imperative code, using SQL as an api over a database abstract decades of algorithm theory away from the user. If databases are the bottleneck of web development then the api to access this bottleneck should have as little leaks as possible meaning that if our computers are imperative machines with imperative instructions then the api should be imperative as well. Who in there right mind decided that the api should be an SQL expression? Of course it’s going to be leaky.

Then someone tries to be smart and put another abstraction (LINQ) over SQL to try to make it imperative again. Genius.

The solution to fix the problems with LINQ is of course to put another query/expression based abstraction over it.


SQL is in no way an abstraction; it’s a domain specific language designed specifically for sets and databases.


Computers are imperative von neuman architectures. They do step by step ALU operations on things stored in memory slots. A DSL designed for sets and databases on a von neuman machine is an abstraction because a computer is not a machine that does sets and databases on the instruction level. SQL will need to of course translate machine instructions into higher level Set and database operations.

This is the problem.

The SQL DSL is leaky because you cannot just understand the database in terms of Sets. You have to understand what lies beneath in order to use it effectively. The speed of the query is very very dependent on what this high level language compiles into… Hence the EXPLAIN keyword. This is essentially a leaky abstraction.