[Haskell-cafe] Monads: external questions

[Jeffrey Brown]

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?

varieties

---------

In practice, are all monads either for exceptions, state or output? If not, what other goals are monads well suited to?

How should multiple contexts coexist? What's a simple Haskell program that uses more than one kind of monad in the same scope? Should, say, output and state be nestled in parallel into a three-attribute monad (the third variable being the type variable), or would it instead be better to create separate output and state monads? If each context should have a separate monad, is it a good idea to nest them, or somehow otherwise let them overlap, within a particular function or scope?

temptations to err

------------------

I have a vague sense that a common pitfall is to use monads to do things in a procedural way that eliminates the benefits of a functional language, but I'm not sure I would recognize it if I were making that error. I feel like I could learn from a comparison of code that works and uses monads badly to code that does better.

[John Lato]

A fairly short answer for now, that doesn't address everything.

I don't think monads necessarily change the way one things about a problem. I personally think of a monad as a way to structure a computation.  There's a bit of a hierarchy:
  1. functions model a computation from inputs to an output.
  2. Applicative functors model a computation from inputs to an output within some type of fancy context.  The computation can depend on the context, but it cannot change the context at all.
  3. Monads allow the computation to affect the context.

That's why a monad is a good model for mutable state: it's a very simple structure that allows for the computation to mutate the state (context).  Mutable state itself is a decent model for IO.

In practice there are other common users of monads.  Modeling coroutines is probably one of the most useful, although perhaps it's not used as widely as it could be.

Formerly one of the biggest pitfalls was using a monad when an Applicative would be sufficient.  Hopefully the AMP will help with this in the future.  Otherwise, I think generally monads are a good model when their power is required.

_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Alberto G. Corona]

2014-10-26 1:23 GMT+02:00 Jeffrey Brown <jeffbr...@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 G. Corona]

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. 

--
Alberto.

[Michael Jones]

When I took a Lambda Calculus class years ago in Silicon Valley, 90% of the students groaned and complained. They just wanted to learn Java and make money. Having a background in OO design and experience with Eiffel, I was intrigued and stuck with it, building some tools with ML, and later Haskell.

In the workplace it was near impossible to avoid the .Net culture, and most of my code has been C#. But the factors that mattered were:

- Continuity with past languages and tools

- Availability of programmers

- Third party libraries

- Inter langage operability

- Reuse of legacy code

etc

Best I can tell, there is no way to avoid the business context. I suggest that if you have freedom, you need to be multilingual. Many systems could benefit from applying the proper tool to the corresponding problem.

But I will say this, becoming proficient at Haskell really improved my designs by providing an alternative conceptual framework. But, it had a very substantial learning curve. All I can say is trust that even if your core language is procedural, you will be better at that for learning a functional language.

To make Haskell a first class citizen in the IT shops, I think focus would have to shift more to the business context and needs. And certainly more focus in the universities that are still dominated by procedural languages. Once that is drilled into ones head, it affects the way one thinks.

To give an example, I have these problems:

- Update to GHC 7.8.3 from 7.6 caused run time behavior changes breaking USB application

- Sandboxes are not completely isolated from the core library and often builds break

- Most new grads don’t even know what a functional language is

- Documentation gets out of sync with releases (where documentation means Wiki and web)

- FFI is difficult to use and debug

- Lack of books, user groups, etc

Mike

[Alberto G. Corona]

Michael:

You are right, but these are minor problems I think, compared with the huge potential advantages.

 I can not believe it when a slow immature language like Ruby could take over web development just for one library, Rails and some buzzwords, when a faster, safer language can do it millions of times better.  Haskell  can revolutionize all the industry simply selling it not as one more language, but as THE meta-language for building EDSLs for each domain problem. some EDSLs so close to the domain problem that can be used by non-programmers.

That lack of vision and effort in the side of the haskell community hurts me. And the lack of interest in this ticket

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

Is a clear display of this lack of interest.  it is like the Aristocracy of the Haskell Wondwerland fears to be hijacked by hordes of mediocre DSL villains from the industry, so it is necessary to keep the walls high 

Haskell is a language dominated by academics that has no interest in the success of Haskell. On the contrary. 

--

Alberto.

[Bardur Arantsson]

On 2014-11-22 17:56, Alberto G. Corona wrote:
> Michael:
>
> You are right, but these are minor problems I think, compared with the huge
> potential advantages.
>
> I can not believe it when a slow immature language like Ruby could take
> over web development just for one library, Rails and some buzzwords, when a
> faster, safer language can do it millions of times better. Haskell can
> revolutionize all the industry simply selling it not as one more language,
> but as THE meta-language for building EDSLs for each domain problem. some
> EDSLs so close to the domain problem that can be used by non-programmers.
>
> That lack of vision and effort in the side of the haskell community hurts
> me. And the lack of interest in this ticket
>
> https://ghc.haskell.org/trac/ghc/ticket/7870
>
> Is a clear display of this lack of interest. it is like the Aristocracy of
> the Haskell Wondwerland fears to be hijacked by hordes of mediocre DSL
> villains from the industry, so it is necessary to keep the walls high

Not that I necessarily agree or disagree with what you're saying, but
that is a completely useless ticket. It's *way* too open-ended and
doesn't seem to have very many specifics about what's the desired
feature actually *is*.

I submit that you're likely to get a lot more traction if you actually
worked to specify *exactly* what's the desired feature is, i.e.
*specify* the stripped down algorithm that you want implemented, how
it's going to be integrated with user code, how it can be used to
improve error reporting for EDSLs, etc.

(I believe it's customary to create a Trac Wiki page for any proposed
features.)

>
> Haskell is a language dominated by academics that has no interest in the
> success of Haskell. On the contrary.
>

Well, the unofficial Haskell motto *is* "Avoid success at all costs", so
y'know... :)

Regards,