[Haskell-cafe] Monads: external questions

Alberto G. Corona agocorona at gmail.com
Wed Oct 29 09:48:05 UTC 2014


I know that I'm using a different language when talking about monads. The
language of the IT industry.

Many haskellers use the language for toy programming. Others are
professional academics. The few that use the language for commercial
purposes are too busy developing practical applications rather than
thinking deep about how to apply the haskell concepts to their problems.
As a result many of such problems remains essentially unsolved. These busy
developers try to transcode solutions from other languages that lack the
deep and expressiveness of Haskell.

This lack of interest in one side and the lack of time in the other is
disappointing. The symptoms are everywhere. Particularly, I find it in the
lack of support and interests for this ticket:

https://ghc.haskell.org/trac/ghc/ticket/7870

I though that there was definitively a shift from "avoid success at all
costs" a few years ago, for a commitment for the success, but still there
are many minds to change, especially the brilliant ones.

2014-10-26 2:02 GMT+01:00 Alberto G. Corona <agocorona at gmail.com>:

>
>
> 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
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20141029/28dbef7e/attachment.html>


More information about the Haskell-Cafe mailing list