2014-10-26 1:23 GMT+02:00 Jeffrey Brown <jeffbrown.the@gmail.com>:
As opposed to the internal logic of monads, how they work, I hope to start a discussion about their external logic: how and why to use monads.

design
------
How do monads change the way one   
* thinks about a problem?   
* structures data?   
* refactors?   
* tests?
Should I always be giving the monads a lot of cognitive bandwidth, because they reorder the way everything should be, or is it an investment with a high initial cognitive cost but requiring little maintenance thereafter?
                                                    
what is their common framework?
-------------------------------
Monads let data reach farther than it otherwise would. Subjectively, they feel like a controlled way of violating encapsulation.

Are there other, deeper or more specific, commonalities that explain why monads are a good way to implement exceptions, output, state, and perhaps other services?

I made monads for execution state recovery, web navigation.. workflows,  long running transactions, backtracking, traceback and event chaining in web browser applications.  

I´m confident that the perspectives for monads to solve real IT problems are very promising. And when I mean monad I mean all the associated stuff : applicative, alternative etc.  

I´m confident that there will be a cloud monad (for chaining jobs and work distribution) an orchestration monad for orchestration of web services etc.

There are problems that are intrinsically procedural among them, almost all problems in IT. instead of using ad-hoc  data/control structures like events, handlers, configurations, routes, exceptions, logs, transaction compensations, promises ....the list goes on and on , the monad is the common control structure that can subsume all of them inside his programmable semicolon

So, once the monad is set up, the user of the monad code the solution for the domain problem in a clean EDSL with absolutely no plumbing, at the level of the problem. so anyone that know the problem can understand the code. 

Is the monad instance, and the applicative etc the ones that subsume under the hood the special data/control structure necessary for the domain problem.


Often if your code is general enough, it can be used in any monad. So you benefit from this. I think that in th future there will be a lot of surprises about the shareability of code between monads when the IT industry start to use them seriously. I think that we are just at the beginning.

I hope that some others of your questions are also answered here