10 ms·
Abstractions work by restricting the domain of what you can do, then building on those restrictions. For example, raw hardware can jump anywhere, but structured
by jerf 3y ago
Abstractions work by restricting the domain of what you can do, then building on those restrictions. For example, raw hardware can jump anywhere, but structured programming constrains you to jump only to certain locations in order to implement if, for, functions, etc. It is precisely those restrictions that bring the benefits of structured programming; if you still frequently dipped into jumping around directly structured programming would fail to provide the guarantees it is supposed to provide. CRUD frameworks provide their power by restricting you to CRUD operations, then building on that. Immutable data is accomplished by forbidding you from updating values even though the hardware will happily do it. And so on.
Escape hatches under the abstractions are generally there precisely to break the abstractions, and break them they do.
Abstractions necessarily involve being irreversible, or, to forestall a tedious discussion of the definition of "irreversible", necessarily involve making it an uphill journey to violate and go under the abstraction. There's no way around it. Careful thought can make using an escape hatch less pain than it might otherwise be (such as the ORM that makes it virtually impossible to use SQL by successfully hiding everything about the SQL tables from you so you're basically typing table and column names by dead reckoning), but that's all that can be done.
One thing to do about this is that just as in the past few years the programming community has started to grapple with the fact that libraries aren't free but come with a certain cost that really adds up once you're pulling in a few thousand libraries for a framework's "hello world", abstractions that look really useful but whose restrictions don't match your needs need to be looked at a lot more closely.
I had something like that happen to me just this week. I needed a simple byte ring buffer. I looked in my language's repos for an existing one. I found them. But they were all super complicated, offering tons of features I didn't need, like being a writethrough buffer (which involved taking restrictions I didn't want), or where the simple task of trying to understand the API was quite literally on par with implementing one myself. So I just wrote the simple thing. (Aiding this decision is that broadly speaking if this buffer does fail or have a bug it's not terribly consequential, in my situation it's only for logging output and only effectively at a very high DEBUG level.) It wasn't worth the restrictions to build up stuff I didn't even want.
- cloogshicer 3y ago> It is precisely those restrictions that bring the benefits [...] Wouldn't it be possible to say "ok, I'll take those restrictions as long as they benefit me, but once I notice that they no longer do, I'll break them and drop down to the lower layer. But only for those parts that actually require it"? > Abstractions necessarily involve being irreversible, or, to forestall a tedious discussion of the definition of "irreversible", necessarily involve making it an uphill journey to violate and go under the abstraction. Why? Not being snarky, I'm genuinely trying to understand this better.
- jfoutz 3y agoI added 2 numbers and came up with 5. What numbers did I add? You can’t know, because the abstraction (add) destroys information. A “good “ abstraction destroys information that doesn’t matter, or maybe matter in a given context. You can hang on to all of that extra detail, but it seems like that extra detail slows down drawing inferences. When I claimed adding resulted in 5, you probably didn’t care if it was 5 apples or 5 skyscrapers. The addition results of 5 are the important part. Kinda hand waving, but what is included and what is left out is the heart of abstraction imho. And when it’s left out, you can’t get it back.
- deleted 3y ago[deleted]
- s_m_t 3y agoI think there is something to the nature of your addition example that is counter to your point. Addition being an "abstraction" doesn't make it destroy information it's just an algebraic property of addition. If you instead took multiplication of prime numbers as your "abstraction", no less abstract than addition, then every product would have a unique factorization in the primes. Whether either of these operations makes sense for your problem and thus whether their limitations apply doesn't have anything to do with what "abstraction" you choose. They are either isomorphic to some aspect of your problem or they aren't.
- ulbu 3y ago