[Haskell-cafe] Monads: external questions

[Alberto G. Corona]

2014-10-26 1:23 GMT+02:00 Jeffrey Brown <jeffbrown.the at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20141026/7dc7f5c5/attachment.html>