All the evidence is out there in Hackage. I backed up my points with some argumentation at least, and you dismissed it based on personal experience that we have no way of verifying. So, not changing my mind yet.

You have hardly backed anything up, I don't see any links in your original post. From my perspective, your thoughts are as anecdotal of that of the other poster.

What links do you need? If you know anything at all about the Haskell ecosystem, you already know where to find all these papers/sites/presentations about arrows, pipes, lenses and what not.

Yes, I know where to find descriptions of language features. That doesn't prove to me that they're often misused or that I might commonly have a problem with code that others have written because of it.

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.

Maybe you could shed some light on how to deal with the issues mentioned?

Especially point 4 sounds very painful. I frequently have to add logging or special case handling at different places in our code base.

In case you need to add logging, you can always close your eyes and use unsafePerformIO anywhere, since from the view of the application, logging is just write-only side-effect.

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.

Thanks for the response. Logging doesn't seem to be an issue then, nice.

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?

If you're injecting your settings at the root of your reader monad (which almost all Haskell applications are structured around), how many function calls are you between your monad stack and where you need to thread settings to? 3? Maybe 4? This isn't an issue in practise. It's a 4 line diff.

Source: 3 years of pure FP Scala in prod

unsafePerformIO will work. But again, why bother with side effect isolation, if you need to break it to do trivial stuff.

Of course you can sneak in Debug.Trace everywhere if you don't compile with -XSafe. But by doing this you basically break your own rules.

At which company is the largest Haskell team in the world?

StanChart, the Cortex team. Equivalent to the Slang/SecDB team at Goldman.