Algebraic Effects in Practice with Flix • Hacker News Board

Re: Algebraic Effects in Practice with Flix

#51

Post by kephasp » Thu, Sep 11, 2025, 11:14 AM UTC

LudwigNagasena wrote: post #41

I think it is a cool feature, but I see some practical issues. For me, encapsulation is a feature. I would like to see that a function uses a network call deep down, but only in a static analysis sort of way. So I don't want to mark something as potentially using a network until it actually uses it. And at the same time I wouldn't want to change every effect of every intermediate function just because I made somethin…

First, you can write a function that's generic on the effects used, so you could write use it in a way that calls an LLM and use it elsewhere in a way that cannot, with the same logic.

But I see the need to change the code as a good thing when it is necessary: I don't want a dependency, inside or outside my codebase, to suddenly add network calls without me knowing it. Same goes for code that was pure and has become stateful. Not knowing this kind of fundamental change is a recipe for a nightmare.

It should be especially apparent with the recent supply chain attacks.

Re: Algebraic Effects in Practice with Flix

#52

Post by kephasp » Thu, Sep 11, 2025, 11:18 AM UTC

artemonster wrote: post #11

thfuran wrote: post #9

Earlier quoted context omitted.

It seems to me like a pragmatic compromise and very much a real solution. What would you consider a real solution that isn’t overinsisting on beautiful design choices?

putting strong static type system into optional compiler pass. yes, I know this may be null is some cases, let me run my program for now, I know what I am doing. yes, there are unhandled effects or wrong signature, just let me run my test. yes, that type is too generic, i will fix it later, let me run my god damn program.

This is basically what we already have in Haskell. Debug functions that sidestep the typing system can be annotated with a warning and you can make this one an error while compiling for production.

And in a more general sense, you can ask the compiler to forbid escape hatches altogether.

We already have a pragmatic, reliable solution.

Re: Algebraic Effects in Practice with Flix

#53

Post by kephasp » Thu, Sep 11, 2025, 11:21 AM UTC

artemonster wrote: post #3

I really want effects to shine and thrive, but since this is a very academic topic, only academic people engage with the research and it comes with academic pedantism, perfectionist worldview, strange attraction to beautiful consistency, etc. This automatically places effect research FAR from any practicality and grounded realism. 2 points, as examples: 1. Ever tried adding a simple print statement for debugging purp…

Resumable code is extremely helpful and I'm pretty sure you're describing a chicken and egg issue: if resumable code was readily available in general, people would use it a lot more and it would look like a very normal tool that is often the best.

But when it's only a feature available in niche languages or many languages make it unsafe or unreliable, then very few people will get to the point where it naturally pops up in their mind as a solution to their problem.

Re: Algebraic Effects in Practice with Flix

#54

Post by saviorand » Fri, Sep 12, 2025, 7:59 AM UTC

vjerancrnjak wrote: post #50

vips7L wrote: post #19

Maybe I’m not getting it, but isn’t this just interfaces and implementations from the OO world? For example their movie one is: interface MovieApi { List getPopularMovies(); } What are effects providing over this?

Flix does not have generic effects, yet it has generic traits. This hints that effects are not meant to deal with data variability. Effects are allowing variability of control flow. Abstracting `try/catch/finally` or `async/await`. For example, something like "durable workflows" is just a specific effect implementation, code stays the same.

True, although I think they're working on support for generic effects

Re: Algebraic Effects in Practice with Flix

#55

Post by LudwigNagasena » Fri, Sep 12, 2025, 2:46 PM UTC

kephasp wrote: post #51

LudwigNagasena wrote: post #41

I think it is a cool feature, but I see some practical issues. For me, encapsulation is a feature. I would like to see that a function uses a network call deep down, but only in a static analysis sort of way. So I don't want to mark something as potentially using a network until it actually uses it. And at the same time I wouldn't want to change every effect of every intermediate function just because I made somethin…

First, you can write a function that's generic on the effects used, so you could write use it in a way that calls an LLM and use it elsewhere in a way that cannot, with the same logic. But I see the need to change the code as a good thing when it is necessary: I don't want a dependency, inside or outside my codebase, to suddenly add network calls without me knowing it. Same goes for code that was pure and has become…

In the real world you usually want to extend datatypes and provide new implementations without recompiling let alone rewriting old code (The so called expression problem). This is the raison d'être of complex DI and IoC enterprise patterns and various monkey patching techniques.

I am not sure how flexible the effect approach is. It took decades before static typing became painless enough for rapid agile development. Properly typed DI with safeguards sounds wonderful, but can algebraic effects actually deliver that?