6 ms·

This guy is brilliant! Excerpt: 16:08 "And locks don't compose... I can't take two arbitrary pieces of code that each do locking, and then combine them toget

This guy is brilliant! Excerpt: 16:08 "And locks don't compose... I can't take two arbitrary pieces of code that each do locking, and then combine them together without knowing the implementation details. Which means that the entire notion of reuse in OO is broken." Never thought about that before, but it makes a lot of sense... Now, in thinking about it, I'd change that sentence, slightly, to "the whole notion of reuse in OO is broken in objects which depend on databases and specific locking strategies or objects which depend on other objects that do", but the idea is still a very valid one... To-do: Rewatch this video in the future...

cryptonector 7y ago
This is a well-known problem...
- hinkley 7y ago
  One of the things I know Simon Peyton Jones spent a great deal of time looking at during his time at Microsoft Research was Software Transactional Memory, and in all of the videos I saw he emphasized the composability problem. I don't think it would be particularly wrong to assert that he spent about ten years thinking about this problem. Might still be for all I know. Interesting that his wikipedia page doesn't seem to mention it. I'm a little sad that STM didn't seem to pan out, but maybe someone will try again someday on top of a Rust-like object ownership semantics (some sort of escape analysis for shared stated).
AnimalMuppet 7y ago
OK, but what does compose in that circumstance? FP? The locking is an external effect, can you just compose two arbitrary functions that each do locking? I suspect it's more true that the entire notion of reuse or composability is broken in code which depends on databases and specific locking strategies or code which depends on other code that does. It doesn't have anything to do with objects.
- cryptonector 7y ago
  Transactions compose. And yes, purity composes (because it requires no locks), and since FP pushes you to purify, FP helps. You don't have to do FP to have composability, but FP has great composability. > I suspect it's more true that the entire notion of reuse or composability is broken in code which depends on databases and specific locking strategies or code which depends on other code that does. It doesn't have anything to do with objects. Mutable objects impose locking requirements, and locks don't compose easily because lock-taking order matters (to avoid deadlocks). Yes, you can add deadlock detection and rollback and retry/abandon on deadlock, but it's a complication you have to handle because OOPs generally don't provide all of that.
  - AnimalMuppet 7y ago
    > Transactions compose. But they compose in OO too, right? > Yes, you can add deadlock detection and rollback and retry/abandon on deadlock, but it's a complication you have to handle because OOPs generally don't provide all of that. But FP doesn't provide all of that either, does it?
    - cryptonector 7y ago
      Within pure paths, you just don't have this problem. You only have this problem at the boundary with the storage system (where, indeed, you might have to retry, e.g., if you have SERIALIZABLE transaction semantics). So FP gains composability if you can express your program as purely as possible as compared to an OOP w/ ORM system. And if you have transactions, you can compose FP programs that construct them because transactions compose. But if your ORM deprives you of transactions, you won't have that composability in your ORM.
      - AnimalMuppet 7y ago
        OK, that's fine for "within pure paths". But even in FP, you have to take the lock somewhere, right? And now it's not pure, right? And now you have to pay attention to lock order, right? If your ORM doesn't give you transactions, then you don't have transactions. But FP needs some kind of layer to talk to a database, too, doesn't it? And if that layer doesn't give you transactions, you're in the same place, aren't you? Am I missing something? Or are you missing my point?

cryptonector 7y ago

This is a well-known problem...

hinkley 7y ago
One of the things I know Simon Peyton Jones spent a great deal of time looking at during his time at Microsoft Research was Software Transactional Memory, and in all of the videos I saw he emphasized the composability problem. I don't think it would be particularly wrong to assert that he spent about ten years thinking about this problem. Might still be for all I know. Interesting that his wikipedia page doesn't seem to mention it. I'm a little sad that STM didn't seem to pan out, but maybe someone will try again someday on top of a Rust-like object ownership semantics (some sort of escape analysis for shared stated).

AnimalMuppet 7y ago

OK, but what does compose in that circumstance? FP? The locking is an external effect, can you just compose two arbitrary functions that each do locking? I suspect it's more true that the entire notion of reuse or composability is broken in code which depends on databases and specific locking strategies or code which depends on other code that does. It doesn't have anything to do with objects.

cryptonector 7y ago
Transactions compose. And yes, purity composes (because it requires no locks), and since FP pushes you to purify, FP helps. You don't have to do FP to have composability, but FP has great composability. > I suspect it's more true that the entire notion of reuse or composability is broken in code which depends on databases and specific locking strategies or code which depends on other code that does. It doesn't have anything to do with objects. Mutable objects impose locking requirements, and locks don't compose easily because lock-taking order matters (to avoid deadlocks). Yes, you can add deadlock detection and rollback and retry/abandon on deadlock, but it's a complication you have to handle because OOPs generally don't provide all of that.
- AnimalMuppet 7y ago
  > Transactions compose. But they compose in OO too, right? > Yes, you can add deadlock detection and rollback and retry/abandon on deadlock, but it's a complication you have to handle because OOPs generally don't provide all of that. But FP doesn't provide all of that either, does it?
  - cryptonector 7y ago
    Within pure paths, you just don't have this problem. You only have this problem at the boundary with the storage system (where, indeed, you might have to retry, e.g., if you have SERIALIZABLE transaction semantics). So FP gains composability if you can express your program as purely as possible as compared to an OOP w/ ORM system. And if you have transactions, you can compose FP programs that construct them because transactions compose. But if your ORM deprives you of transactions, you won't have that composability in your ORM.
    - AnimalMuppet 7y ago
      OK, that's fine for "within pure paths". But even in FP, you have to take the lock somewhere, right? And now it's not pure, right? And now you have to pay attention to lock order, right? If your ORM doesn't give you transactions, then you don't have transactions. But FP needs some kind of layer to talk to a database, too, doesn't it? And if that layer doesn't give you transactions, you're in the same place, aren't you? Am I missing something? Or are you missing my point?