Joel Spolsky has an article in which he states
All non-trivial abstractions, to some degree, are leaky.
This is overly dogmatic - for example, bignum classes are exactly the same regardless of the native integer multiplication. Ignoring that, this statement is essentially true, but rather inane and missing the point. Without abstractions, all our code would be completely interdependent and unmaintainable, and abstractions do a remarkable job of cleaning that up. It is a testament to the power of abstraction and how much we take it for granted that such a statement can be made at all, as if we always expected to be able to write large pieces of software in a maintainable manner.
There are really two separate statements here, (what does 'leaky' mean, anyway?) The first one is -
All APIs contain artifacts of what they're built on top of.
As I said before, this is overly dogmatic, but mostly true. The example given, however, is extremely curious. TCP requires quite a tangent to explain ('look how smart I am, I know about TCP') and is one of the most robust, useful, and widely deployed abstractions in existence. I've spent a huge amount of time using TCP in very novel ways and haven't set a socket option in my life. Furthermore, Joel cites TCP's failure mode as an artifact of IP, when it is in fact an artifact of wires and electricity, and an extremely well done and clean one at that. Whether the connection drops due to network outage or the counterparty machine going down, you still get a single well-defined failure, with clear semantics as to what might have arrived on the other end.
TCP actually has plenty of real artifacts, such as slow start and high latency during bulk transfers, but these would clarify the distinction between the statement about artifacts and the one Joel is really trying to prove, which is -
All APIs are Broken
As I explained, the TCP example doesn't prove this at all - if a failure mode is defined in the API, then that doesn't mean that the API breaks when it gets invoked. But this statement does apply to most of the other examples Joel goes on to cite - NFS is a mess, C++ strings aren't real strings, COM internals aren't properly hidden, ASP.NET doesn't have proper string mangling code to make GET parameters properly, etc.
You may notice that all the Microsoft tools are left to the end, right before the claim that the law of leaky abstractions is dragging us down. This essay isn't about API design, it's about software apology, an attempt to claim that all software is inherently bad hence it's okay that Microsoft's is bad. Like any good microsoftie, Joel starts with the assumption that the (very flawed) tools he uses are completely acceptable, and works backwards from there.