[jfmengels1]

In pure functional languages (at least in Elm), what happens is that you have data that describes what should be done, instead of doing it directly.

is talk called "Effects as Data" describing that idea: https://www.youtube.com/watch?v=6EdXaWfoslc

[nerpderp82]

I often use a pattern where I do a batch and group a bunch of operations baked into a tuple that describes the computation. Instead of do_thing(on_data), the intermediate pass would emit a data structure full of list([("operation_do_a_thing", on_data), ... ] and then a command executor can do the actual scheduling of the operations, serial, parallel, batched, try/except with backpressure, etc.

Separate the thing you want done from the doing it, because when you intermingle the doing-the-thing it greatly complications the scheduling logic. Think of it as a working programmers io monad.

[brundolf]

I'm aware; I'm not sold on this most extreme version of pure-functionalism. I think it's unintuitive, syntactically clunky, and hard to reason about, despite the benefits of purity. I'm a believer in the functional core/imperative shell approach.

[Latty]

I thought similarly until I committed to working on an Elm project.

I developed an open source game in Elm, and I've been very impressed with the benefits of the pure functional approach. It takes some getting used to, for sure, but it makes things really simple to reason about once you get used to it.

There are definitely rough edges still: Elm in particular is just missing a lot of stuff, but I was surprised how much value the pure functional approach gave me.

[closeparen]

This is exactly how I understand functional core/imperative shell. The functional core returns a structure describing what should be done and the imperative shell goes out and does it.