not the side effects part, which has nothing to do with state
State is a side effect. In fact, that's basically the definition of side effect -- I think you need to revisit the basic principles of formal semantics.
State, as the OP points out, exists in reality but should be eliminated from programming
State is the entire point of programming. State shouldn't be eliminated, it should be corralled so effects are traceable and formalizable.
Objects rely on being mutable. An object-oriented language pushes objects everywhere. This pushes mutation everywhere. This is the opposite of corralled.
> State is a side effect. In fact, that's basically the definition of side effect -- I think you need to revisit the basic principles of formal semantics.
You're right, thanks for the correction. My line of thinking was that addressing the issue of side effects in programmatic functions was not the same thing as addressing state -- while not mutually exclusive, they're not the same thing.
> State is the entire point of programming. State shouldn't be eliminated, it should be corralled so effects are traceable and formalizable.
I won't go so far as state being the entire point, but it's simply another way to programmatically solve a problem. It absolutely should not be eliminated, but rather used responsibly -- just as with anything else in a programmatic environment.
I won't go so far as state being the entire point, but it's simply another way to programmatically solve a problem.
Writing to memory is stateful. Writing to a file is stateful. Printing something to the screen is stateful. Seeing the effect of your program is stateful. Would you say that the point of programming is to produce an effect?
Objects rely on being mutable. An object-oriented language pushes objects everywhere. This pushes mutation everywhere. This is the opposite of corralled.
As I said in another comment:
Note that you can have objects without OOP. Python has objects. Python is not object-oriented. Same with OCaml or Racket. I'm not arguing against using state. If you're programming a state machine, you may want to model it with state. That would be a pretty good choice. The problem is that OOP says everything is a state machine.
State is a side effect. In fact, that's basically the definition of side effect -- I think you need to revisit the basic principles of formal semantics.
State, as the OP points out, exists in reality but should be eliminated from programming
State is the entire point of programming. State shouldn't be eliminated, it should be corralled so effects are traceable and formalizable.
Objects rely on being mutable. An object-oriented language pushes objects everywhere. This pushes mutation everywhere. This is the opposite of corralled.