4 ms·
The algebraic effect handler pattern is a much simpler mental model than monads. And is transferrable to other languages pretty easily. See something like https
by voat 1y ago
The algebraic effect handler pattern is a much simpler mental model than monads. And is transferrable to other languages pretty easily. See something like https://github.com/doeixd/effectively https://github.com/doeixd/effectively in Typescript
- epolanski 1y ago1. The effect data type admits an instance of monad, like arrays or option or result. Not sure why would you put those in competition, an effect is a supercharged ReaderResult. The only differences are in naming choices, traverse being called foreach, flat map being called "and then", etc. 2. There is a much more popular and robust implementation of effects for Typescript: https://effect.website/ https://effect.website/
- naasking 1y ago> The only differences are in naming choices Naming choices matter, as does syntax.
- mrkeen 1y agoI use effects to make guarantees about what the code will and won't do. When Option was retrofitted onto Java, the NPEs didn't disappear. We got Options that could be null, but more importantly, devs (and the standard library) continued to use null liberally. We never ended up at the tautological goal of "if I have a Person, then I have a Person". I am equally skeptical of bolting on effect systems after the fact. Even if one of these effect systems becomes 'the main one' and starts showing up in standard libraries, we'll still end up with declared-effectful code and undeclared-effectful code, but will again fall short of the goal, declared-effectful code.
- IshKebab 1y agoI agree, this seems like something where it really needs to be natively supported in the language from day one to work properly.
- sidkshatriya 1y agoThe impact of Effects are a bit less pervasive than null wouldn’t you say ? Effects can be used with code “in between” that knows nothing about effects. Performing and handling effects can be quite transparently
- gf000 1y agoDoing something a bit vs almost completely can have a significant difference in practice - having a way to maybe avoid nulls doesn't solve the million dollar problem, but making non-nullability the default arguably has (see Rust, Kotlin, etc). An even better example would be Rust's memory safety. Sure, there is still unsafe, but it being used very sparingly has reached its goal. So I think a new language where 'pure' is the default (with a few, locally scoped escape hatches), and effects are "mandatory" would actually be pretty effective at reaching its stated goals.