36 ms·

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 co

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
      You're assuming that transactions require locks. That's not necessarily the case with MVCC and SERIALIZABLE semantics, but you may have to retry the transaction (from scratch) if it fails. This looks a lot like what you'd get if you were using locks. Somewhere, though, there will be locks, indeed. Pushing the locking to the edges of the system helps keep the core composable. There's no panacea, of course. Also, an RDBMS can order locks because once you've decided what INSERTs/UPDATEs/DELETEs you're doing, they can be sorted and run in a different order than they were requested (after all, if the transaction is atomic, then the internal order doesn't matter). You can absolutely build all of that (transactions, lock ordering, ...) in any OOP (or FP or other) language of your choice. But that's essentially recreating part of an RDBS -- if you're after reuse, just use an RDBMS so you don't have to recreate its functionality. Using an RDBMS w/o an ORM helps you avoid all the issues raised by TFA. Further, using an EAV design gives you many benfits as outlined in TFA and elsewhere in the commentary here and on the web.
      - AnimalMuppet 7y ago
        Well, TFA was a video, so I've just been going off of the comments here. So, if I understand you correctly, the issue is with ORM, rather than with OOP or with the RDBMS. And you wouldn't use an ORM in FP, so you don't have the problem there.
        cryptonector 7y ago
        TFA also had slides. I'm not going to say TFV... :) > So, if I understand you correctly, the issue is with ORM, rather than with OOP Well, there is certainly an issue with ORM. But OOP even absent databases and persistence, when used as originally intended (with objects abstracting state and behavior), has concurrency issues.

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
    You're assuming that transactions require locks. That's not necessarily the case with MVCC and SERIALIZABLE semantics, but you may have to retry the transaction (from scratch) if it fails. This looks a lot like what you'd get if you were using locks. Somewhere, though, there will be locks, indeed. Pushing the locking to the edges of the system helps keep the core composable. There's no panacea, of course. Also, an RDBMS can order locks because once you've decided what INSERTs/UPDATEs/DELETEs you're doing, they can be sorted and run in a different order than they were requested (after all, if the transaction is atomic, then the internal order doesn't matter). You can absolutely build all of that (transactions, lock ordering, ...) in any OOP (or FP or other) language of your choice. But that's essentially recreating part of an RDBS -- if you're after reuse, just use an RDBMS so you don't have to recreate its functionality. Using an RDBMS w/o an ORM helps you avoid all the issues raised by TFA. Further, using an EAV design gives you many benfits as outlined in TFA and elsewhere in the commentary here and on the web.
    - AnimalMuppet 7y ago
      Well, TFA was a video, so I've just been going off of the comments here. So, if I understand you correctly, the issue is with ORM, rather than with OOP or with the RDBMS. And you wouldn't use an ORM in FP, so you don't have the problem there.
      - cryptonector 7y ago
        TFA also had slides. I'm not going to say TFV... :) > So, if I understand you correctly, the issue is with ORM, rather than with OOP Well, there is certainly an issue with ORM. But OOP even absent databases and persistence, when used as originally intended (with objects abstracting state and behavior), has concurrency issues.