5 ms·

I think what we desparately need is a way to move between abstraction layers easily. For example, right now, when you pick a framework, you're kinda stuck with

I think what we desparately need is a way to move between abstraction layers easily. For example, right now, when you pick a framework, you're kinda stuck with it. Even if you could in theory move to a lower abstraction layer (by modifying the framework's source code itself), nobody does this in practice. So you're kinda locked into that layer of abstraction. Imagine how amazing it would be if it didn't matter what level of abstraction you start on. You could seamlessly move between layers and modify wherever seems reasonable. I don't yet see how we could achieve this. But I think this would require abandoning our current notion of abstraction entirely, or at least introducing some major constraints on it. If anyone has any thoughts on this at all, I'd love to hear them.

lmm 3y ago
Proper abstractions work. Look at what happens in the functional-programming world; if you provide an instance of monoid (say) for your datatype, you can use all the functions that work on monoids, but your datatype still retains its full detail and you can use your original datatype wherever you like. Avoid frameworks, use libraries, and use good abstractions that aren't going to "leak" - which usually means those grounded in mathematical laws.
- cloogshicer 3y ago
  I disagree. All abstractions are leaky, to a certain extent. The abstractions in FP circles are only not considered leaky because performance concerns are often secondary, and only correctness is considered. https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
  - lmm 3y ago
    I'm aware of that post and it's bollocks. None of its examples actually work, and even if they did they wouldn't be enough to prove a general law.
    - cloogshicer 3y ago
      I think they make a lot of sense - genuinely curious what you mean. Could you explain in more detail?
      - lmm 3y ago
        Writing your application using UDP rather than TCP doesn't mean it will continue to work when you unplug the network cable. That's not the abstraction leaking, that's the premises being violated. TCP is actually very specific about what it does and doesn't guarantee. That SQL example may have been a real bug in one database 20 years ago, but it's not something that happens in reality. Query planners work well enough that you can't generally beat the query planner - PostgreSQL won't even let you try, quite deliberately. And if you look at even one of the classic FP examples like monoid, not only do they not leak, but you can literally mathematically prove that they don't. If you have two lists of a monoid, sum(a) + sum(b) will always equal sum(a + b). The whole post is just a failure of imagination; rather than proposing that all abstractions are leaky because you can't think of any good ones, a better post would ask what it would take to constitute a valid abstraction and then try to figure out whether that's possible or not.
arghnoname 3y ago
I know of something in this area, but I was involved in it and prefer to maintain my pseudo anonymity. If you care to and email me at my username @ gmail I'll share over that channel.
- cloogshicer 3y ago
  Done! :)

lmm 3y ago

Proper abstractions work. Look at what happens in the functional-programming world; if you provide an instance of monoid (say) for your datatype, you can use all the functions that work on monoids, but your datatype still retains its full detail and you can use your original datatype wherever you like. Avoid frameworks, use libraries, and use good abstractions that aren't going to "leak" - which usually means those grounded in mathematical laws.

cloogshicer 3y ago
I disagree. All abstractions are leaky, to a certain extent. The abstractions in FP circles are only not considered leaky because performance concerns are often secondary, and only correctness is considered. https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
- lmm 3y ago
  I'm aware of that post and it's bollocks. None of its examples actually work, and even if they did they wouldn't be enough to prove a general law.
  - cloogshicer 3y ago
    I think they make a lot of sense - genuinely curious what you mean. Could you explain in more detail?
    - lmm 3y ago
      Writing your application using UDP rather than TCP doesn't mean it will continue to work when you unplug the network cable. That's not the abstraction leaking, that's the premises being violated. TCP is actually very specific about what it does and doesn't guarantee. That SQL example may have been a real bug in one database 20 years ago, but it's not something that happens in reality. Query planners work well enough that you can't generally beat the query planner - PostgreSQL won't even let you try, quite deliberately. And if you look at even one of the classic FP examples like monoid, not only do they not leak, but you can literally mathematically prove that they don't. If you have two lists of a monoid, sum(a) + sum(b) will always equal sum(a + b). The whole post is just a failure of imagination; rather than proposing that all abstractions are leaky because you can't think of any good ones, a better post would ask what it would take to constitute a valid abstraction and then try to figure out whether that's possible or not.

arghnoname 3y ago

I know of something in this area, but I was involved in it and prefer to maintain my pseudo anonymity. If you care to and email me at my username @ gmail I'll share over that channel.

cloogshicer 3y ago
Done! :)