The entire "monad" discussion is pretty hard to get your head around. Perhaps part of the problem is that it represents not just side effects, but also forced ordering of operations (albeit, largely to allow for those effect-full interactions with the outside world).
I think that maybe for "industrial" programmers, we need a language, perhaps something like Scala, where the default is pure functions and immutable data, but you can tag things (functions & data) as "mutants", er, "mutable"/"mutates", and those tags "taint" what those elements can be combined with. Call something with side effects from something that should be pure, and get an error, that sort of thing. Then, teach people to use mutable data as sparingly as possible. Maybe wrap database updates in some kind of (small!) message handling actor?
"Call something with side effects from something that should be pure, and get an error, that sort of thing."
If you enforce that, you get Haskell, where you have no choice but to wrap your head around isolating your IO layer from everything else. If you don't enforce that, you don't get very much material difference in practice.
I'm concerned that in practice, 99% purity isn't very useful. We shall see. (You get advantage from 0 - 50%, then I think a long plateau, then a sharp spike right at 100%. It can be hard to make the leap, since there's no way to ease into it.)
"The entire "monad" discussion is pretty hard to get your head around. Perhaps part of the problem is that it represents not just side effects, but also forced ordering of operations (albeit, largely to allow for those effect-full interactions with the outside world)."
Well, part of the problem is that "monad" doesn't mean any of those things. It's an interface (very much like the Java sense of the term) which has some implementations that enforce those properties, and other implementations that do not. Which is to say that yes, it is hard to get your mind wrapped around, but this is largely because of the spray of terrible, terrible explanations of the monad interface sprayed about by people who barely understand it themselves.
The best way to actually learn them is Learn You a Haskell; if you've already learned basic Haskell syntax you can leap straight to chapter 11[1]. (Do not jump straight to the Monad chapter 12. Start at 11. Start earlier if you don't know the syntax.)
OK, I still feel pretty ignorant about it. That said, perhaps the Haskell community would be better served by communicating about the various commonly used monad cases seperately, rather than mixing the discussion up around what seems to be a common "syntax" (approximately) to apply various traits. Again, spoken as an outsider who wants to find the baby in all that bathwater :-)
I did do at least some LISP back in the 80s in college, although it was limited to puzzles and mini expert system type problems (enough to see that pure functions were a good idea), but not to do what most people would think of as "applications" with any kind of data feed connectivity. By the late 80s, AI seemed to be moving to neural net ideas, so we didn't dwell on LISP much in the other AI related class I took.
The paying the bills in the real world forces you into a plethora of Turing tar pit languages :-)
OTOH, simply trying to explain the idea of "pure functions" to one of my Java programming coworkers a few years ago was stunning. Me: look, you can easily understand the workflow this way -- the routine is short, and all the data used is in the parameter list and the result returned. Him: hmm, I guess that might help with debugging.
I think that maybe for "industrial" programmers, we need a language, perhaps something like Scala, where the default is pure functions and immutable data, but you can tag things (functions & data) as "mutants", er, "mutable"/"mutates", and those tags "taint" what those elements can be combined with. Call something with side effects from something that should be pure, and get an error, that sort of thing. Then, teach people to use mutable data as sparingly as possible. Maybe wrap database updates in some kind of (small!) message handling actor?