4 ms·

Are you somehow not in control of how x is being changed? You seem to have said that literally any statefulness is "exhausting".

• gnuvince 11y ago
  Anyone, anywhere could modify x, which is what makes reasoning about this code difficult. When your entire program is a collection of mutable state that can be mutated by any piece of code, understanding what's going on becomes really difficult if not impossible. One thing that people are adopting from FP is to limit what is mutable, and when possible make state explicit.
  • pekk 11y ago
    That isn't true. I don't understand why you can't use a language that offers encapsulation.
• S4M 11y ago
  What convinced me that avoiding mutations as much as possible was having to deal with code like that (in java): public class MyBigClass() { private int a; private int b; //hundreds of lines of code private int calculateSomething() { //do something a = a+1; return b*b; } //hundreds lines of code private int calculateSomethingElse() { int c = calculateSomething(); return a+c; } //hundreds of lines of code public returnSomething() { return calculateSomethingElse(); } } In this example. It's hard because you have to remember constantly which functions are changing your classes before you use them, and if you haven't written the functions, it's very easy to introduce a bug by involuntarily modify the states using the function calculateSomething, just wanting its output and not the modification of a.
  • pekk 11y ago
    That demonstrates some design flaws of Java, yeah, because your "private" variables are effectively just globals anyway. The guy who is not using encapsulation at all this year will be making similar mistakes (massively long bodies, proliferation of unnecessary entities, etc.) if he switches to functional programming next year. It's not a panacea. I'm afraid this doesn't demonstrate that any tiny bit of statefulness is "exhausting."