3 ms·

> I know that's not the side effects you were talking about, but when I'm changing my OOP stuff, that's the kind of side effect I'm most worried about. That's

> I know that's not the side effects you were talking about, but when I'm changing my OOP stuff, that's the kind of side effect I'm most worried about. That's not a "side effect"[1] at all. It's a logical bug in the implementation that only affects the function's return value. You absolutely still have to worry about those sorts of bugs in FP, which is why you still need tests or a fancy enough type system to prove the bug cannot happen (for your example that is unlikely to be practical). "Without any fear of side effects" doesn't mean you don't have to fear anything at all, but it's one less thing to worry about. [1]: https://en.wikipedia.org/wiki/Side_effect_(computer_science) https://en.wikipedia.org/wiki/Side_effect_(computer_science)

magicalhippo 5y ago
> That's not a "side effect"[1] at all. Yes, like I said. Point is, in my imperative OOP code, I'm relatively seldom worried about actual side effects, and more worried about introducing bugs due to me not fully grasping all the interactions of the code I'm changing. Did someone somewhere make an assumption about how this code works (sums all numbers), and am I breaking that assumption when I'm making this change (summing every other number)?
- Tainnor 5y ago
  > I'm relatively seldom worried about actual side effects I'll give you one concrete example: In a number of ORMs, I have no idea when database calls actually happen and this can lead to a) subtle logic bugs (inconsistent state), or b) bad performance (N+1 queries). I've had such problems both with Ruby's Active Record and Hibernate, two of the most popular ORMs. I've even deployed code that had subtle bugs, even though I wrote tests, because while my tests verified that the correct state of the object was written to the DB, the updated state was not reflected in the JSON response object. I'm sure similar things happen in other frameworks as well. A PFP can prevent that sort of craziness from happening.
  - magicalhippo 5y ago
    Fair point, though I'd say such ORMs are broken by design by the sound of things.
    - Tainnor 5y ago
      I agree that Hibernate in particular is broken by design, but it is what it is...

magicalhippo 5y ago

> That's not a "side effect"[1] at all. Yes, like I said. Point is, in my imperative OOP code, I'm relatively seldom worried about actual side effects, and more worried about introducing bugs due to me not fully grasping all the interactions of the code I'm changing. Did someone somewhere make an assumption about how this code works (sums all numbers), and am I breaking that assumption when I'm making this change (summing every other number)?

Tainnor 5y ago
> I'm relatively seldom worried about actual side effects I'll give you one concrete example: In a number of ORMs, I have no idea when database calls actually happen and this can lead to a) subtle logic bugs (inconsistent state), or b) bad performance (N+1 queries). I've had such problems both with Ruby's Active Record and Hibernate, two of the most popular ORMs. I've even deployed code that had subtle bugs, even though I wrote tests, because while my tests verified that the correct state of the object was written to the DB, the updated state was not reflected in the JSON response object. I'm sure similar things happen in other frameworks as well. A PFP can prevent that sort of craziness from happening.
- magicalhippo 5y ago
  Fair point, though I'd say such ORMs are broken by design by the sound of things.
  - Tainnor 5y ago
    I agree that Hibernate in particular is broken by design, but it is what it is...