[Haskell-cafe] Wow Monads!

[David McClain]

What I have been able to grok by translating into Lisp is that Monadic programming allows you to hide implicit accumulators, filters, control-flow (the Maybe Monad). Haskel absolutely needs Monads in order to force evaluation order in side-effecting places. Lisp doesn’t absolutely need Monads. 

I won’t really know if programming in Monadic style actually makes better looking code or not - cleaner, easier to grok, performant, organized? - until I try to apply it in anger on a larger project. But I am happy now that I finally understand this often obfuscated beast. The monster is actually a tiny mouse.

I’m old enough now to have lived through at least two major programming fad cycles: Structured Programming followed by Object Oriented Programming. There are always nuggets to be found in any fad cycle, but unfortunately fad cycles always seem to swing to extremes. Psychologists would recognize that as borderline behavioral traits. 

I totally ignored the Programming Patterns cycle, so whenever I hear references to such patterns I first have to Google them. I can appreciate that practitioners would want a taxonomy, but for myself, I see programming patterns in an entirely different light. I have been designing and programming computers for longer than most readers on this site have been alive. But programming has always been only a tool for me, a sharp pencil, a side channel, in the pursuit of physics.

Lisp has somehow managed to retain relevance to me throughout this entire period. I don’t choose languages for myself based on popularity. I want to get things done. And I want to do them quickly and move on to the next project. 

So, being in Lisp, I am not overly concerned with type safety. I don’t have to live in a community of programmers all contributing to the project code base. I am in complete control of the projects in their entirety. But if this were not the case, then certainly a strong case can be made in favor of type strictness. 

I did tons of SML and OCaml code about 10-15 years ago. I used to design languages and write commercial compilers for C and numerical analysis languages. But for my own uses, I find Lisp, on balance, to be my ultimate modeling clay.

Monads were always a hole in my knowledge. I read Phil Wadler’s paper more than a decade ago, and I remember being impressed at the terseness of his little interpreter. But Monads kept being offered with all the extraneous Category Theory stuff, and all the black-box mysticism. Now that I have seen Crockford's video, translated his JavaScript into my Lisp, I thoroughly get what they are all about in languages like Javascript and now Lisp. 

They might be useful to me.

- DM


 
> On Apr 17, 2017, at 01:58, Joachim Durchholz <jo at durchholz.org> wrote:
> 
> Am 16.04.2017 um 23:07 schrieb David McClain:
>> Heh!! My title “Wow” was not an expression of wonderment. Rather it
>> was “Holy Cow! Monads, how can you guys be so obtuse?!”
> 
> LOL okay :-D
> 
> I think they suffer from being awesome even if not well-understood, so half-true statements about them get widely distributed.
> 
> What I still don't know is if their face value is overhyped or not.
> 
> The paper essentially displays how to do the visitor pattern in a functional way. Nothing to see here, move on...
> There are a few interesting aside points though:
> 
> One, that this kind of injection can be done in a type-safe way (not a mean feat given the complexities of type parameters, but essentially follows from the choice of type system and, interestingly, the absence of side effects). This point is unrelated to monads, it's entirely conceivable that some other structure could have been used instead.
> 
> Two, that the set of changes needed to turn a straightforward expression tree into an injectable one is so small. It's a mixed blessing, because the actual complexity of the definition is much larger than what you see at a glance. However, it's unrelated to monads as well, it's a consequence of having type inference and currying.
> 
> Three, that the injected structure does not need to be more than merely conform to Monad, which is a pretty small core API (with "core" I mean the set of functions that cannot be expressed as composition of other API functions).
> Now this is indeed related to monads, but to me, it's unclear how important that finding is. I see monads being found all over the place, but is that a consequence of the Monad structure being so simple and permissive that it happens to match so many places in so many programs, is it because there are useful monad libraries that people actively make their code conform to the structure, is it perception bias (because monads are well-discussed so people can identify a Monad in their code but not an Arrow), or is Monad indeed tied to fundamental properties of coding? Frankly, I don't even know how to test the hypotheses here.
> What I do know is that we had a quite overhyped, simple but ubiquitous data structure earlier: Lists. In the 80ies, there was that meme that lists are the universal answers to data structures, mostly from the Lisp camp where lists were indeed fundamental, ubiquitous, and so simple they could be applied easily to all tasks. I haven't seen anybody seriously entertaining that thought in years; it will be interesting to see whether monads share that fate or prove to be something more fundamental.
> 
> Just my 2 cents :-)
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.