[wredue]

I mean. It’s not like people pushing “side effects” (read: literally any change at all) aren’t also being overtly dogmatic, and writing utterly terrible code.

Uncle bobs book didn’t age well, but neither will the dogmatic stances on immutability and side effects.

[bc_programming]

In this case, By "side effects" I mean non-obvious changes to the static state, Where a seemingly simple function will both rely on static fields to evaluate it's result as well as make changes to various other fields that will subsequently change the result of that function going forward. I don't think one needs a dogmatic adherence to immutability and avoiding side effects to find that to be undesirable.

[wredue]

I agree. Just letting you know that, most likely, the people you are learning about “side effects” from don’t actually mean “side effect” in the colloquial sense of “state changes beyond the expectation”.

They mean literally any change at all. If your function is named addOne(&x), then they consider the result of x being one greater to be a “side effect”, whereas I suspect actually sane people such as yourself would not see that as a side effect.

This type of definition fuckery is one reason (among many), that I’ve come to fully disrespect functional programming communities.

One thing that also needs to be understood is that side effects (to your definition) are not explicitly bad things. Side effects ignoring boundaries, ignoring APIs, holding references, etc are probably mostly bad though.

In fact, in gaming, providing hooks to empower side effects is often explicitly good for granting designers mechanic freedom.

[Gibbon1]

My belief is the people you are talking about think of programs as batch operations where you take data transform it and then pass it to someone else's API calls. In that case state is sort of evil.

In embedded and gaming state changes in response to input is the point of everything.

[mrkeen]

I'm one such person!

"Side effect" doesn't have any useful meaning if it doesn't have teeth.

Nothing is a side effect if it's what the programmer intended to do.

[LorenPechtel]

What's especially important is non-obvious state.

I was trying to use a function. You had to create an instance of it to use it, but I was using one method that by appearances should have been static. You feed it an input, it gives you an output, there's nothing to remember. I was calling it from multiple threads--occasional corruption. There must have been something being stored into the object but I have no idea what or why.

[trealira]

Avoiding side effects as much as possible is not a new idea, though; it's been around since at least the 80s. You can just ask people who have worked on Haskell code written in the past 25 years to determine for yourself if the idea aged well or poorly. Opinions will probably be mixed, though, not clearly one way or the other.

[mrkeen]

The definition of "side effect" has to mean something, otherwise it defaults to the opinion of whoever wrote the code.

  // Not a side-effect (intentional)
  if(++i++) {
  }

[trealira]

I don't understand how this relates to my comment. I'm saying that avoiding side effects isn't a new idea, so it already has aged, either well or poorly.

[wredue]

I don’t really care about the opinions of Haskell coders, as they are probably the only programmers on earth that have more terrible dogmatic ideals than uncle Bob does.

[tome]

If you're open to challenging your preconceptions (dare I say dogma?) about Haskell programmers then I'm willing to share my opinions on good software development and how Haskell helps, based on over a decade of professional experience with Haskell. Free tidbit: I find effect tracking to be extremely beneficial to software engineering in the large.