Programming with Effects(matfournier.com)
matfournier.com
Programming with Effects
http://www.matfournier.com/2019-07-25-effects/
16 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.
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.
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
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
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
getUser :: MonadDatabase m => UserID -> m User
getAndComputeScore :: (MonadError Error m, MonadDatabase m) => UserID -> m Score
getAndComputeScore id = do
user <- getUser
computeScore user
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 ...
data ConcreteTestEffects a = ConcreteTestEffects ...
instance MonadError Error ConcreteTestEffects where ...
instance MonadDatabase ConcreteTestEffects where ...
data ConcreteEffects a = ConcreteEffects (DatabaseHandle -> Either Error a)
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.
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.
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!
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.
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”?
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.
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.
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?
Because a news site is only for "typical" things?
> 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.
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.