3 ms·

I find that there's two core points that help me figure out where I'm missing some form of abstraction: the body of a function should only operate on a single l

by pdpi 8y ago

I find that there's two core points that help me figure out where I'm missing some form of abstraction: the body of a function should only operate on a single level of abstraction, and it should only know technical details about one thing. If you're writing some database code, having high-level fetchMyEntity() calls mixed with connection/resultset/cursor logic is bad news. If you're writing something that reads from a message queue and stores the message in a database, the place where the two meet shouldn't know much of anything about either the message queue or the database. Obviously, exceptions exist where these rules need to be broken, but I find they're fairly few and far between.

wwarner 8y ago
Yes. I look for something I can measure when I make this decision. Will it result in less code? Will it improve performance? Will users/customers care?
base698 8y ago
The "Simple Made Easy" talk describes this as the root of complexity in an application. Mixing and tying various subcomponents that shouldn't have to know each other exist.
- taneq 8y ago
  > Mixing and tying various subcomponents that shouldn't have to know each other exist. And this is the real trap when dealing with abstractions - maybe the implementations of two different operations are the same, but if the semantics are different then de-duplicating them creates an unnecessary dependency between the two. The more cross-links in your application structure, the harder it is to do anything without breaking everything.
  - pdpi 8y ago
    > And this is the real trap when dealing with abstractions - maybe the implementations of two different operations are the same, but if the semantics are different then de-duplicating them creates an unnecessary dependency between the two. One of the truly remarkable things about Haskell is that its approach to structural abstractions allows you to break out of this problem (though you end up paying a different cost for it)

by pdpi 8y ago

wwarner 8y ago

Yes. I look for something I can measure when I make this decision. Will it result in less code? Will it improve performance? Will users/customers care?

base698 8y ago

The "Simple Made Easy" talk describes this as the root of complexity in an application. Mixing and tying various subcomponents that shouldn't have to know each other exist.

taneq 8y ago
> Mixing and tying various subcomponents that shouldn't have to know each other exist. And this is the real trap when dealing with abstractions - maybe the implementations of two different operations are the same, but if the semantics are different then de-duplicating them creates an unnecessary dependency between the two. The more cross-links in your application structure, the harder it is to do anything without breaking everything.
- pdpi 8y ago
  > And this is the real trap when dealing with abstractions - maybe the implementations of two different operations are the same, but if the semantics are different then de-duplicating them creates an unnecessary dependency between the two. One of the truly remarkable things about Haskell is that its approach to structural abstractions allows you to break out of this problem (though you end up paying a different cost for it)