4 ms·
The author of the article buried the lede, which is in the last paragraph: > So the tension around types comes from the fact that if you want to program in a s
by jfarmer 12y ago
The author of the article buried the lede, which is in the last paragraph:
> So the tension around types comes from the fact that if you want to program in a style that turns effects into explicit things that get passed around, sophisticated higher-order functions are necessary to keep your code reasonably clean. And sophisticated higher-order functions tend to have fancy complicated types. To make programming with them palatable, you either need to have a correspondingly fancy type system or punt on types entirely.
I think the author is right when he says "To explain the why of monads, we have to first explain the why of the functional style of programming." However, he says one of the "defining characteristics" of the functional style is that "[f]ancy type systems are important." The net effect of the article is to give the impression that monads exist because one needs a "fancy type system" to program with pure functions — as if it were the "fanciness" that mattered.
We don't have to look hard to understand the "why" of monads. They were introduced in the paper Monads for Functional Programming by Philip Wadler (http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/ba...) and he spells out the motivations very clearly!
Here was one key to my understanding monads. In a purely functional language you want everything to be referentially transparent. That is, every expression should be able to be substituted for its value no matter where it appears. At the very least, you'll want the ability to denote which parts of your program are referentially transparent and which aren't.
This can be expressed as utopian vision: in a purely functional language we'd like everything — everything — to be a value. And if you want expressions involving functions to be referentially transparent you're going to need pure functions.
We now need some way of translating code with side effects into code that returns a value. One reasonable abstraction is to say that the "value" is not the work itself — once the work is done it's out of the bag, after all — but rather the "value" is the machine which can perform that work.
- hawkice 12y ago> So the tension around types comes from the fact that if you want to program in a style that turns effects into explicit things that get passed around. > We now need some way of translating code with side effects into code that returns a value. One reasonable abstraction is to say that the "value" is not the work itself — once the work is done it's out of the bag, after all — but rather the "value" is the machine which can perform that work. It's also worth pointing out that this is precisely why Monads are the abstraction level of choice for a great deal of DSLs (there are some good applicative DSLs for parsing and applicative FRP things as well, but most DSLs have Monad transformers and such as the desired interface). And since this is the syntax and abstraction target for most DSLs, and DSLs are great, Monads often get brought up quite quickly in discussions of languages that use them (notably, Haskell).
- jarcane 12y agoWhat I'm realizing in trying to develop my own (admittedly limited in scope) functional language is that "fancy type systems", or at least "fancy some-kind-of-structured-value-thing" systems go a hell of a long way to making it not an interminable pain in the ass. The hardest thing for me to "get" about FP is that some problems really do require an awful lot of persistent data to be easily converted to values to be passed back and forth instead. Something like, say, a VM, that's a piece of piss to code in a language that allows mutable state can become an interminable mess of gobbledygook or just a huge pain in the ass in a lanugage where the means for passing data structures is too verbose or complicated (like say, Scheme/Racket structs). This is why the 'fancy types' in Haskell, I realized, and the robust syntax for dealing with them. Because they become the main medium for communication within your program in anything non-trivial, and you need that process to be as frictionless as possible for the FP approach to not fall apart completely into a very tedious sort of chaos.
- tel 12y agoThe other way to look at it is that Haskell allows all of this information which would be otherwise implicitly embedded in the abstractions, style, and conventions of a language to float to the top to a formal, verified type language. So you can see them as a primary tool to handle the complexity or the driving force for exposing all the complexity in the first place!
- codygman 12y agoThanks for reading that paper by Wadler. In the past I was very intimidated by papers such as this, but I've found they are one of the best ways to learn. If you go back far enough to when Haskell (or any language) was created you'll usually encounter simpler and simpler ideas and less abstraction. Kinda-sorta implementing Monads through pattern matching in that paper helped me really get quite a few things.
- tome 12y agoWadler typically writes very clear, approachable papers.