| This article is a reminder to all of us programmers that there is a belief that is common among non-programmer intellectuals (especially the above-average-intelligence-but-not-genius types) but completely non-existent among skilled software engineers: Abstraction is inherently dishonest. If you're a good software engineer, you quickly build an understanding that abstractions are vital for detailed understanding of complex systems, but can leak or even fail entirely. Less quickly, software engineers build very good instincts at how to tell when an abstraction is leaking/failing (that's what debugging is, after all). Outside software engineering, this is not a skill that is consistently practiced. As a result, you end up getting takes like this one, in which the authors figure out that "money" is an abstraction over "all productive work and assets" and that this abstraction sometimes leaks. But because the authors aren't used to dealing with abstractions, they assume that the fact that the abstraction "money" leaks sometimes means that it's worthless and should be removed. In fact, the opposite is true: the abstraction "money" does leak (which can cause real serious problems), but in the cases it doesn't, it's essential to human flourishing in any economy more complex than "exchange bread for pelts" |
To come up with better abstractions, sometimes you need to strip away the abstractions and study what's being abstracted.