It's done a lot, it's used for mocking in FP.

For example, I hace a monad that saves to a database using effects. I change the effect to update an array instead and I have code that I can use in a unit test.

I'd argue this is incredibly common if you write a codebase without a specific, concrete effect stack. In Haskell, the mtl library offers constraints on types mandating that they support at least some effect. These compose together and then are executed by a custom effect "stack" that inhabits all of the constraints.

So, you might have a piece of code which can fail at using some User properties to compute a score of some sort

    computeScore :: MonadError Error m => User -> m Score

and also a piece of code that pulls a given user from a database

    getUser :: MonadDatabase m => UserID -> m User

and we can compose them

    getAndComputeScore :: (MonadError Error m, MonadDatabase m) => UserID -> m Score
    getAndComputeScore id = do 
      user <- getUser 
      computeScore user

In some sense, each of these three functions operates in a different (abstract) effect stack and the calls to getUser and computeScore were transparently "upgraded" to a more comprehensive effect stack when they were called in getAndComputeScore.

This is the basis for "effect tracking" where each piece of code is written to the minimal, necessary effect specification. Their ability to compose and operate within other compatible (abstract) effect stacks is used regularly to compose small programs into bigger ones. Then, finally, you just make a big type

    data ConcreteEffects a = ConcreteEffects ...

    instance MonadError Error ConcreteEffects where ...
    instance MonadDatabase ConcreteEffects where ...

which instantiates all of your abstract effects concretely. You might even make two, one for testing

    data ConcreteTestEffects a = ConcreteTestEffects ...

    instance MonadError Error ConcreteTestEffects where ...
    instance MonadDatabase ConcreteTestEffects where ...

These will look like compositions of the basic effects from this article. For instance, if you imagine a type of DatabaseHandles, you might have

    data ConcreteEffects a = ConcreteEffects (DatabaseHandle -> Either Error a)

which you can stare at and recognize to be Either and Reader combined together.

The example often used is something like the Reader monad, which is basically used like dependency injection. Run your code in an isolated environment to test, and connect it to the real application just by swapping the environment (effects/monad).

A more interesting example could be monads as used in Haxl, which give an alternative monad in which to run database queries, which can perform complicated batching of requests behind the scenes with no change of business logic code.

I replaced one type of Future for another in a large Java codebase. Not productive.

I had a colleague who wanted to rewrite the same piece of code using Observables instead.

Later in a different company I met someone who was working on the exact opposite, i.e. taking Observable code and rewriting it as Futures because "observables are confusing".

Just extract these things behind an interface and call it a day.

futures have a lot of gottyas that make them hard to replace. for example, where and how you initialize them matters

>how often does it happen, that you'd want to swap effects without changing program code?

Anytime you want to test (and e.g. don't perform the actual side effects but mock them)?

Or change from e.g. logging to a file to logging to a DB or syslog?

And lots of other cases!

Is this fundamentally different from simply providing different implementations of a “Logger” or “Database” interface? Why does the involvement of side-effects result in the machinery being so different?

That's what the OP is about: hiding implementations behind an interface.

Effects are different because side effects are impure which is not allowed by default in a pure language. Machinery is needed to hide the effects in effect-managing containers so they don't contaminate pure code.

I understand that, what I’m trying to understand is if there’s a claim being made that such machinery is especially desirable in this circumstance... is this claimed to be “the way you have to do it in pure languages” or “a really nice way of doing it, which is enabled by language purity”?