&gt; I was saying that it brought no great advances with respect to side effects,<p>Really? I work with a bunch of languages that does not have controlled side effects, and controlled side effects is the single biggest thing I miss from Haskell. The uncontrolled side effects I swear over daily, if not hourly.<p>The fact that the order in which I call functions can – undocumentedly – decide whether my program works or crashes is a ridiculous concept. The fact that if I share the wrong piece of data with another part of the application my program starts behaving erratically from having invalid data is odd.<p>Sharing data should not feel unsafe. Changing the order of method calls should not be a threat.<p>As long as a function gets the data it wants through explicit parameters, it should work. It shouldn&#x27;t matter at which point in time I call it, because managing time is really difficult. Managing data is easy.<p>The controlled side effects in Haskell give you a way to encode these things to give you guarantees and self-documenting code. It gives you opportunities to deal with these problems in sane ways.<p>Refactoring Haskell code is mostly a matter of symbolic manipulation. A huge chunk of the process doesn&#x27;t even require me to think about what I&#x27;m doing, because I have much more freedom when I don&#x27;t have to worry about side effects myself. This is good, because I&#x27;m bad at thinking and I would like to do it as little as possible. Every single bug that have appeared in my problems have been because I&#x27;m bad at thinking.