[aeonik]

I feel like this is part of the problem, we keep trying to find the right abstractions, but it seems to me the ones that generalize well enough are tend to be very difficult for most to understand.

I've been down a rabbit hole for the last five years researching this, and I am converging on Clojure. I don't understand why transducers aren't used everywhere, they seem to solve a gigantic class of problems that I see everywhere.

I'm also getting the feeling that Haskell folks have really done a lot of great work, and plan to learn more about their typing system next. Monads seem to be a fundamental building block.

If I try to bring this up with engineering teams, I don't get any traction because nobody wants to learn any of this stuff. It takes too much time to ramp developers up, and management is skeptical because there aren't enough large-scale communities or companies built around the concepts from their perspective. Bottom line is, it takes too much investment for too much risk.

Instead we get a lot of half-baked and wrong abstractions incrementally invented for the latest pain point instead.

[marcosdumay]

> Monads seem to be a fundamental building block.

Sorry, but no. If that or transducers are the things you think about on this context, you are going on the wrong direction.

Not that those aren't useful. Whatever software solves the OP's problem will certainly make plenty of usage of interpreters and lambdas (what monads and transducers are), and any developers should be able to use both of those. But those are completely removed from the problem, they aren't an attempt to solve it.

[aeonik]

The apps that I write pull data, process it, and write it to another sink.

There are many different sources and sinks, but the processing pipelines tend to be the same.

Based on my research these abstractions are designed for this. Feel free to elaborate why I'm incorrect, or better abstractions.

I brought it up in the discussion relating to CRUD, because it's very similar to the code I used to write for straight CRUD. In fact both ends of the processing pipelines are identical to CRUD.

[marcosdumay]

> Based on my research these abstractions are designed for this.

Those two are general purpose abstractions aimed at organizing code. They can certainly be used for this, just like they can be used for anything.

[bruce343434]

I'm somewhat into FP concepts, and here is how I de-jargon these terms:

> transducers

Just a function composition operator. Notes: is aware of iterators like `reduce`, and merges multiple consecutive of such loops into one. (should optimizing compilers not strive to do this anyway?)

> monads

Literally just an "interface". For instance, you will be able to .map() it.

> algebraic effects

Resumable exceptions (you can go back to the "throw" with the corrected data)