These are chat archives for jdubray/sam
I do like this comment:
Because the authors of haskell are sadomasochists and decided that you should do something stupidly complex to accomplish simple things, so you HAVE to learn monads to use haskell, not because they're in any way useful in themselves
For me monads are an indication that the "Functional Programming" programming model has something particularly flawed. But, I'll refrain from making that conclusion, just yet.
That other answer is pretty good too:
In essence, you're writing execution steps and linking them together with the "bind function". (In Haskell, it's named >>=.) You can write the calls to the bind operator yourself, or you can use syntax sugar which makes the compiler insert those function calls for you. But either way, each step is separated by a call to this bind function.
So the bind function is like a semicolon; it separates the steps in a process. The bind function's job is to take the output from the previous step, and feed it into the next step.
The best solution we found to the above is to use GraphQL and start with a normalized data model in the GraphQL Schema with performant, entity-mapped CRUD microservices corresponding by name and structure to user-defined data types (with id's being used as relational constructs) then de-normalize (with de-duping using the graphql-deduplicator library) using performant, async resolvers on the server, on-demand, according to the shape of the UI component to be rendered, then cache static data (only) in the UI.