Do you have any evidence to back this up?
In my experience working in the largest Haskell team in the world, dealing with various applications and services in production: none of what you said is close to reality.
In my experience working in the largest Haskell team in the world, dealing with various applications and services in production: none of what you said is close to reality.
You've recounted your experience and detailed that you have seen issues with things in Hackage, and I won't claim your experience is invalid. I just won't let you claim your experience is that much more valid than someone else's without proof.
Especially point 4 sounds very painful. I frequently have to add logging or special case handling at different places in our code base.
It's all about how much do you isolate sideeffects from each other. If you go nuts with isolation, you loose flexibility. If you write all your code in IO monad (that means any code can have sideeffect), you are as in other languages where you can do sideeffect anywhere you want.
I'm still curious as to how to introduce variations though.
Frequently we find that we have to introduce "if (settings['special_x']) then DoSpecial else DoCommon" deep in the business logic to handle special cases that arise.
Assuming the existing function did not depend on the settings, how does one best introduce this dependency on the settings? In our code base we can cheat by effectively having the "settings" dictionary as a global variable, though we try to minimize this obviously. But in a pinch at 4am, that might be enough.
How about Haskell, is there a way to "inject" such settings without refactoring all the way to the top?
Source: 3 years of pure FP Scala in prod