Programming with Effects | Hacker News Reader

Programming with Effects

matfournier.com

70 pointsluu16 comments

Although, I'm familiar with the concepts; I posit that the examples in the post are too general. Due to the generality of the examples, the concepts may be difficult for beginners to pick up, or to see any benefit. I suggest the (free) book Scala with Cats as an alternative.

how often does it happen, that you'd want to swap effects without changing program code? I don't think it is a strong selling point.

As someone who is interested in FP, but still at the beginning of the journey, I found the blog post interesting to read, especially intuition for every Monad.

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.

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”?

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.

What's the value in paying the cost for an HTML rendering but rendering text in a monospace typewriter format? This "techie" affectation farms readability.

In a typical PL context "effects" is always short for algebraic effects, and this article doesn't address those at all. Downvoted due to misleading title.

> In a typical PL context "effects" is always short for algebraic effects

The word "effects" has a long and storied history in programming language theory that predates algebraic effects/handlers by decades. The study of effect systems includes algebraic effects but also monads and other type and effect systems. In some situations the lines between these are blurred, for example with "extensible effects" which are algebraic effects implemented by a free(r) monad combined with "data types a la carte"-style open unions.

Algebraic effects are a popular subclass of effects, but not all effects of use in programming (or worthy of study!) are algebraic.

The simplest example is the continuation effect. It's not immediately clear why this effect isn't algebraic (it's not even immediately clear what "algebraic" means) but suffice to say continuations are very weird and behave very differently from other effects.

At the same time, they're very useful and are a useful part of someone's programming vocabulary.

You are downvoting because the article is about what it said in the headline and not something else?

Because a news site is only for "typical" things?

Reply on news.ycombinator.com