The idea of abstractions as lies which you must maintain using ever more clever lies is an interesting analogy I'd never used before, but it makes perfect sense.

It really also ties in with John Osterhout's views on "deep modules." A perfect example of an interface that is deep (in Osterhout's sense of the term) is the Unix file I/O API. Another, albeit to a lesser extent, would be #Forth's block storage wordset.

But, comparing the two is enlightening. Forth's blocks provides only the barest essentials for accessing mass storage devices in a device independent manner. You assign a range of 1KiB blocks to a specific device, and now you have full access to that storage. It works like demand paging, except with 1KiB pages and "demand" is driven by software explicitly, not implicitly. The interface is really deep: BLOCK, BUFFER, UPDATE, FLUSH, and EMPTY-BUFFERS. That's it (and 99.999999% of the time you will only ever use BLOCK and UPDATE).

But, in exchange for this simplicity, you lose the notion of a filesystem. You're managing space on a volume explicitly. I've found that, for most applications, you can get away with this no problem. It is actually pretty rare that one needs anything more than this.

The moment you introduce character stream support, though, this interface suddenly becomes inadequate. Now you need a completely new abstraction, where Unix's I/O calls fit more naturally. But, that is unarguably a more complicated stack of software to maintain, with many more interface points to maintain (open, read, write, close, seek, mkdir, unlink, mknod, etc.). But, it's a useful abstraction; that's why it (in some form or another and with varying degrees of completeness) has become so universal across different platforms. Including, ironically, in Forth itself.

But like all lies, you can only support them with more clever lies. Hence, why we have libraries that abstract other libraries, sometimes several layers deep. (Looking at you, SDL!) And while each claims to simplify some aspect of programming, I find usually it's just the opposite; they actually (sometimes greatly) complect the software as a whole.

This is one of those "I don't have the answer" type of posts. I'm not sure how one could arrive at the ideal "deep modules interface" for, say, something like SDL. I'm not even sure it's possible. But, maybe, just maybe, I can inspire someone somewhere to think about giving it a try for their software architecture. If you insist on making a lie, at least make it a good one.