If monads are the solution, what is the problem?
danghica.blogspot.com
danghica.blogspot.com
That's a very operational/imperative perspective, and to my mind is putting the cart before the horse. To me the whole value of monads is that they let you talk about things like state and input-output in a declarative way, using plain old functions and values, rather than having to use these awkward/confusing concepts of "evaluation" and "scheduling".
There are many perspectives one can use to understand Monads. The operational one is valid - and useful for many beginners. Of course, it's not the only way to look at them, as you point out.
This is in contrast to Haskell that uses monads to declare the computation graph (well, functions, but monads are under discussion here). In this world, data is computed lazily as needed. The questions you ask about the code center around functions and their dependencies, not necessarily computation order.
A task that is trivial to express with on paradigm might be non-trivial to express on the other: haskell is excellent about expressing lazy computation and side effects, whereas a CSP language will offer easy reasoning about the specific and correct order of execution.
Note I am not a PL expert, just an enthusiast. My diction may be off for the domain.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.673...
Meanwhile I find monads very useful in Scala, even without any laziness in sight.
> Meanwhile I find monads very useful in Scala, even without any laziness in sight.
But do you use monads for all the things Haskell programmers use them for? Or only a subset of those things?
Almost all projects end up needing to care about performance at some point or other, if only a little. (So yes, Haskell is probably not a suitable language for most projects, sadly)
> But do you use monads for all the things Haskell programmers use them for? Or only a subset of those things?
All the things, as far as I'm aware. Certainly the obvious ones like IO.
The `Maybe` (or `Option`) monad, for instance, has the single effect
fail :: Maybe a
fail = Nothing
List monads have a non-determinism operational interpretation. The `State`, `Writer` and `Continuation` monads obviously do as well.
You could say the `Reader` monad has the single effect
ask :: Reader e e
The same thing goes for `Free` which is essentially a data structure for the abstract syntax of Monads. However in some sense even for this part of you understanding of free monads is likely based in providing a natural transformation to an interpretation in another monad (i.e. `iterM`)
(I believe there are good reasons you would want to use monads, but only from a denotational perspective, not an operational one)
Haskell also does not need monads to do IO as the author suggests. If you made monads impossible to express (as first class concepts) in Haskell, say by blasting HKTs out of the language, you would still do IO the same way, just with concrete functions instead one's parameterized over an arbitrary monad. If you made Haskell strict, you would still do IO the same way (as an unrelated note though, I believe you would need to add an unbounded looping combinator uloop : (a -> IO (a, Bool)) -> a -> IO a)
Or are you telling me it needs a rather elaborate type signature(World -> (Char, World)), which is entirely the point the author is making here why haskell as being a lazy language needed monads but not ML.
Again, monads are just an abstraction. A language does not need monads to do IO because it is pure or lazy. And a language does not not need monads because it is already impure.
getChar: IO Char
putChar: Char -> IO ()
pure: forall a . a -> IO a
ap: forall a b . IO a -> (a -> IO b) -> IO b
[[p: IO a]] is a program that produces an [a] (or diverges)
[[getChar]] := program that reads a character, c, from the input and produces c: [Char]
[[putChar c]] := program that:
1. "runs" (see below) [c]: [Char] producing a character
2. prints that character to the output
3. produces [()]: [()]
[[pure (x: a)]] := program that produces [x]: [a]
[[ap (x: IO a) (f: a -> IO b)]] := program that:
1. runs [[x]], producing y: [a]
2. then computes p = [f] y: [IO b]
3. then runs the program [[p]], whose result is the final result
* we can apply f: [a->b] to x: [a] to get f x: [b]
* there is a way to regard a character c as a member of [c]
* there is a way to "run" an element of [Char] and get a character, in some sense appropriate to the outer language. For normal pure functional languages [Char] will just be the set of characters plus possibly some additional data to model non-termination so this is easy, but it works even if the language is impure (in this case, the effect of running [c] would precede the effect of printing), if it is non-deterministic (in this case, the output stream bifurcates whenever you print a character), etc.
There is no place in which whether the outer language "has monads" enters in.
(Unlike the above list of requirements, where the notion of a monad has certainly entered in :-) But that is what Moggi used them for after all.)
You can't change the semantics but you can emulate the desired semantics, which is what i argue IO type does.
It would be comparable to working with e.g. Lwt in OCaml, which is very much a practical way of programming.
newtype IO a = IO (State# RealWorld -> (# State# RealWorld, a #))
As the article points out, this has little to do with monads. You can force ordering using unique types [2] (e.g. used in Clean) by having I/O functions take a file handle and return a new file handle in every call. But IO fits nicely into the monadic pattern.
[1] http://blog.ezyang.com/2011/05/unraveling-the-mystery-of-the...
Interestingly, the programming experience with this is going to be pretty much the same as using a language with promises. It would be like working in JavaScript with no blocking IO, but with some abstraction and syntax sugar to make it less powerful.
Or, more pointedly, it would be like working in OCaml. OCaml might not "need" monads, but all serious OCaml is full of monads anyway, at least depending on LWT or Asyc for concurrency.
Why does it need that concrete type (taking one world and producing another)? Why can't i just have it's concrete type be Char? (obviously you would implement with some unsafe inside). But does referential transparency still hold?
One of the advantages of keeping IO in an explicit IO type is that code that isn't in IO becomes easier to refactor. This is what people mean by referential transparency: since I know that a `Char` cannot implicitly depend on the state of the rest of the program, I am always free to move it around, put it in a variable or replace it with an equivalent expression without changing the meaning of the program. You would not get this with getChar :: Char because two getChars could give you different results, so moving them around or reordering them would change the semantics of your program.
It needs some IO type that you can put stuff in it; when that stuff is functions you need some way from passing previous results as arguments of the next ones; also, you need some way to compose that stuff in a defined order.
You do those, and you have a monad. Other languages do not work without monads, they just get a single IO monad that everything is implicitly inside. Their programmers can afford not to say "monad" because they only get one to choose, and can't choose not to take it either.
Haskell needs to constrain the order of evaluation when it's dealing with the real world. There's a solution to that problem (require and yield `World`). Then we choose to use `IO` (i.e. a monad) to implement that solution.
But the abstraction that is a monad is independently justified and worthwhile in languages like Typescript (I wish!) and ML which don't have the same IO issue.
As long as we teach monads as if they have anything to do with IO we're confusing people. IO uses monads because it's convenient and apt. But monads don't control order of evaluation. They've got nothing to do with order of evaluation.
Yes, we are in agreement, however i am arguing that haskell had to use monads here otherwise it would be very difficult to use.
> As long as we teach monads as if they have anything to do with IO we're confusing people.
Sure, but the introduction of monads in haskell came out of a real necessity is my point. Category theory is powerful tool for abstraction and useful in any language.
> But monads don't control order of evaluation. They've got nothing to do with order of evaluation.
Right, but they can hide the trick and make it all seem transparent, which imho is very important point to keep in mind.
The code "putStrLn this >> putStrLn that" is allowed to evaluate this and that in any order, basically. "that" may depend on "this" and vice versa. The very expressions "putStrLn a" is also not an action, but expression, being evaluated into actions.
And the constrainment of effects is what makes Haskell special.
Stream processing type used in Fudgets also admits monadic interface implementation.
After I learnt Haskell, I was forever wishing the languages I work in professionally had monads. But they're all strict languages. Monads give us a nice consistent way of working with stuff inside generic wrapper types (e.g. nullable, arrays, classes and other partially applied functions, state machines, data paired with a world, partial functions converted into (more) total functions by tagging success and failed operations). My professional languages have different solutions for all of them and so it's harder to separate the rules and the mechanisms with heavy syntax
It's more that it's very convenient to think of side effecting functions operating on a world and returning a new one once you already have this powerful abstraction.
I like the fact that the type system encodes that the function has a side effect. But I don't particularly care that the language is lazy when I enjoy this benefit. They're quite independent.
The IO monad is noncommutative, and thus controls sequencing of operations, because of data dependencies, more or less hidden.
A "Haskell wizard" tried to tell me the ordering of operations was implemented through low-level magic a few weeks ago. The fact is that whatever ultimate form GHC might compile your code to, the sequencing is expressible in the semantics of Haskell code. Getting sequencing into the semantics is one of the problems which monads solve.
Without that magic the compiler may inline everything, drop the 'uselss' state token and happily move your buffer freeing before the allocation - or drop it entirely.
Alternatively you could mark every function as noinline and end up with fantastically slow code.
fma a b c = (a * b) + c
It's simpler and cleaner to merely state that the Haskell runtime is written to execute IO actions in sequence.
fma a b c = (a * b) + c
These details of evaluation order are important to know, and they are not something to be argued about: they are well-specified and the compiler doesn't just casually make lazy code into strict code or vice versa. That would cause chaos. And what instruction set Haskell is being compiled to is totally irrelevant to this level of the language's semantics.
Yes, you are certainly right. I misread and thought incorrectly that the discussion was about whether certain constructs forced data dependencies in any theoretical language, not in the particular language Haskell.
> These details of evaluation order are important to know, and they are not something to be argued about: they are well-specified ….
While I take your meaning, I think that you don't mean literally what you said: they got to be well specified precisely by being argued about, and will hopefully get to be even better specified by continuing argument. They are certainly not for me to argue about, though.
Sequencing using the IO monad predictably involves strictness. There is nothing in the type of >>= that forces strictness. That is why, for example, you can usefully bind infinite lists in the list monad. So in e.g. [1..] >>= return . (+ 1), the list is not evaluated before the call to (+).
In fact, binding is not strict in the IO monad either (that's why lazy IO works). It's only the special magic world parameter that is, in effect, evaluated strictly.
The idea of using a data dependency to force a certain order of evaluation predates monads and it predates laziness. So it is implemented accordingly, and any hoops that need to be jumped through in the implementation to make it work aren't magic—they are just necessary to express a long-established pattern.
What monads offer is a way of discreetly passing the state from one operation to the next (the State monad is the model for the IO monad). It removes the need for the programmer to think about that aspect of the plumbing, without creating magic elements in the language.
The hoops are magic in the sense that they can't be expressed in Haskell 98 or Haskell 2010. A Haskell compiler is perfectly entitled to optimize out any dummy values which aren't used. That includes dummy world variables.
More generally, it simply isn't possible to use data dependencies -- even real data dependencies -- to control the order of side effects. The Haskell standards just don't provide the guarantees necessary to make that workable, for the reasons that millstone gave.
do { x <- return [1..]; return 7 }
That evaluates to 7, and the infinite list is never evaluated. So the 'data dependency' that monadic bind gives you doesn't, in general, force evaluation order. It's only because the implementation details of the IO monad ensure that the dummy world parameter is always 'evaluated' that you get guarantees about evaluation order. Note that the dummy world parameter is just that -- a dummy -- and no computation actually depends on its value. It's pure compiler magic.
Well, yes, that's the point. You don't need to understand anything about monads to understand how the implementation of >>= for IO forces the correct order of side effects.
But I do agree with the general idea that Haskell as a language is still a leaky abstraction, you still need to understand a lot of behind-the-scenes stuff, like how the RTS interacts with the OS ABI, how concurrency is implemented, the consequences of laziness and so on. Just knowing the denotational semantics of the language is not enough.
No, there is nothing in the type of >>= which guarantees sequencing of side effects. So for example:
a >>= (\b -> c)
There is nothing in the type of >>= that guarantees that a will be completely evaluated before c is evaluated.
I suspect this misconception is what makes many people think that Haskell's way of handling IO has something crucially to do with monads.
Well, that's in theory at least. In GHC Haskell the ordering is not denoted by neither data dependency ot the operator semantics, but by a complex set of rules that change from one version of the compiler to the other.
1 - Although it is sufficient for any monad that lacks real-world effects.
2 - Well, technically nothing is enough for really ordering IO operations, but those two properties give single-threaded semantics to IO.
Saying that lists are an instance of Monad in Haskell says much more about novel ways you can use a list in Haskell than about properties of a monad.
What's often happening in PL theory, though, is that people start off with axioms/syntax and then mutilate the actual problem until it fits the syntax (still badly). That's how you get ridiculous stuff like "everything is an object" or "everything is a file". In PL theory, people will usually first make up some syntax/theory and then search for models. If physicists worked the same way, they'd write down random formulae and would then go out to find phenomena described by them. You'd probably read this comment on a cave wall.
You don't get everything is an X because of axiomatic formulation. You get it for the same sort of reason that instead of spending ages describing the configurations of atoms in front of you, you throw all that out and call it a screen. Is everything still atoms? Yes! But we can call it a screen and that makes things massively easier to reason about and so we do it, because we like to reason well. But there are still benefits to thinking the other way, thinking from the very foundations. They are just different benefits, which is why we choose to think of problems from more than one perspective.
For example, the notion of elementary topos has been invented because its creators wanted to capture the way Grothendieck toposes kind of behave like constructive sets. This I find very useful, and also the axiomatizations of elementary toposes. On the other hand, Martin-Löf type theory didn't have a formal semantics at first, then an erroneous one, and finally ~20 years later a kind of acceptable one. And its category of models is... not really interesting. Except for categories of assemblies, I don't know of a single model of ML type theory that's not also an elementary topos. And the interesting thing about assemblies is that they can be turned into objects of the associated topos... so yeah.
So, String Theory?
Monad is interesting in retrospect. After you "get" X, Y, and Z you come to realize that they're all monads and then maybe you get some mileage out of the mental compression.
Monad: if you have a data structure that wraps some value of any type, then you also have to implement the interface that provides `return` and `bind` (there's talk about requiring another method, `join` but I digress). The data structure is the "context" and the interface is how you compose values from other Monads together using functions. If you can prove your implementation of the interface methods follow certain rules then you have a Monad.
Why is this pattern/abstraction/interface useful in Haskell?
I think there are several reasons. The article touches one of the most talked about: sequencing. Because of the way the rules of the Monad interface are structured you're guaranteed that the functions you use to compose your Monads together will be executed in sequence with respect to their definition in your function body.
(How it all ties together is straight-forward but requires a certain pedagogy and exposition to follow that I won't get into.)
This is, consequently, what makes Haskell the best imperative language in the world. Not only do you get to use it's wonderful type system but you can compose together small imperative programs into bigger, more useful ones.
These bigger, more useful programs you can write with Haskell are pretty much unreadable though. There is a reason everyone is not jumping into the functional programming bandwagon, despite mature languages being available for 30+ years.
The hard part was that the type system doesn't help you get your algorithms to spit out the correct answer, only the correct kind of answer. After a while I find that errors of that sort dominate the kind of things the type system helps with.
And I'm sure there are type-system-ways-to-solve-that-problem but they're nonobvious and would probably render the rest of the program more confusing. Certainly adding in error handling and state did, compared to working strictly in the IO monad.
In no other language have I ever got distracted from my main goal by just reading the source code of the libraries I'm using.
I have never seen any language get near Haskell on the legibility of random code on the internet.
After I learned Haskell I had a "I knew nothing!" moment. Anybody writing enterprise code on anything that is not as safe as Haskell (that is, basically everybody) is letting a lot of money on the table.
This seems somewhat baseless. Unreadable according to whom? There are many large and complex programs written in Haskell by large teams of developers (open source or otherwise). It’s the nature of software in any language to become difficult to manage as the code base becomes large; I don’t think Haskell is an exceptional offender in this category.
> There is a reason everyone is not jumping into the functional programming bandwagon, despite mature languages being available for 30+ years.
There certainly are reasons for that, but not the ones you laid out.
How many of those projects regularly attract new contributors, vs ..say.. something written in python or C++?
The last readable programming language was Algol 60.
So it's a wrapper that implements a particular interface? Then why, oh why, do we have so many people who spout, "A monad is just a monoid in the category of endofunctors, what's the problem?" Gilad Bracha covered this in a talk once.
Because of the way the rules of the Monad interface are structured you're guaranteed that the functions you use to compose your Monads together will be executed in sequence with respect to their definition in your function body.
So it's a way of imperatively declaring execution sequence dependencies that lets you reason as if there's only pure functions most of the time. This seems to be the case for all functional programming languages/environments. When you get down to it, they're all, in the words of Garrison Keillor, "Pure, mostly."
It's a joke/dank maymay that Haskells still find funny long after it's pissed everyone else off.
The idea is that since category theory is described as "generalized abstract nonsense" by its practitioners, describing monads in terms of their strict category-theoretical definition helps no one, especially those new to Haskell. The problem is that unless your audience is steeped in category theory, they can't appreciate the irony of the situation and you just come off sounding like a dick.
Who needs mindshare, when you can have in-jokes instead? Better to be the one everyone initially laughs at, but wind up with all the mindshare, than to be the one doing all the laughing who gets left behind.
Anyone on the far side of a gulf of enlightenment—and understanding monads is an enlightenment, if a small one—knows that it's effectively impossible to actually communicate the particular thing they learned that helped them achieve enlightenment. (Well, it's not impossible to communicate what they learned; it's just that that's roughly useless to anyone else. An enlightenment is a realization that culminates only from all of a set of micro-skills being attained; and each person is missing different micro-skills to start with. You can look back and see the micro-skills you learned, and teach those, but you have no idea what micro-skills you started off already in possession of that others did not—what micro-skills you take for granted—and so you cannot teach those.)
When faced with someone starting on the path to an enlightenment, who asks you to simply summarize the path for them, there's no way to actually usefully tell them. But it's kind of rude to just say nothing—and on a forum like this, equally rude to assume a role of a master verbally lashing an apprentice (ala a Zen parable) for assuming they could understand the concept without working their brain up through all the micro-skills it was missing first.
So, what you do instead is, you make a joke. A joke that seems opaque at the time, but which the learner, having journeyed further down the path, will realize was the truth they sought, and exactly what they asked for—it was just a truth that was, necessarily, completely useless to them at the time. Any such truth would be.
You don't make the joke to be snarky. You make the joke because you wish that, this time, it would work, and the learner would skip the path and achieve the enlightenment; that you could just reach across the gulf and bring them over. But you know it won't. The punchline of the "joke" is not played on the learner, but on the teacher: it is that the world is cruel and to teach skills that require enlightenments is to suffer knowing your students lay across this gulf, and most of what you say will miss them entirely because of the mismatch in micro-skill acquisition between you.
(Though, I suppose, when the learner attempts to teach the concept themselves, and realizes the only thing they want to say is the same useless thing that was said to them—this would be the joke "paying off." That pay-off makes it sort of like a traditional joke, in the sense that choosing to "tell" it rather than simply thinking it to oneself is choosing to set the learner up for that later pay-off.)
There are lots of disciplines/areas of human knowledge and culture where most of the micro-skills have inherent rewards for learning them.
When faced with someone starting on the path to an enlightenment, who asks you to simply summarize the path for them, there's no way to actually usefully tell them.
I think that has to do more with not being motivated enough to try hard enough combined with the difficulty of summarizing. It's one thing to try to explain a paradigm-shifting insight or system to someone who has never paradigm shifted to learn something. The thing about Haskell outreach, are such failures even in the face of an audience who has previously undergone such a paradigm shift.
You don't make the joke to be snarky. You make the joke because you wish that, this time, it would work, and the learner would skip the path and achieve the enlightenment
How is this different from laziness? Smalltalkers similarly gave up trying to convey how their environment was different, many of them with such snarky jokes. Then years later, Chris Granger comes along with Light Table, and transmits what it is quite clearly and succinctly.
A journeyman is someone who has acquired all the micro-skills they were missing, and has thus gone on to achieve some level of intuitive grasp of the enlightenment they sought. They "grok" the skill.
A master is someone who has gone back and thoroughly weeded their mental garden of the micro-skills they started with and took for granted, and have begun (though perhaps not finished) replacing those with conscious learnings. The master desires to attain conscious handles onto each and every part of the mental schema or process they seek to understand, in order to understand the enlightenment-requiring mental skill as a system, rather than as a simple intuition.
A journeyman has a sense that they know the answer—that they "are enlightened"—and this sense works well enough to guide them when they seek to use the mental skill they sought to acquire. But, because they do not understand the enlightenment-requiring mental skill as a system, only as an intuition, they can give an apprentice on the path no answer that will satisfy them. This is the "gallows humour" stage of the path.
Yes, masters of the path will be able to guide apprentices. Zen koans are written by masters, and they are no gallows humour; they tilt the world enough to allow you to catch sight of the micro-skills the master was attempting to convey. (In the modern world of analytic philosophy, koans might even have a hope of being displaced by jargon-laden explanations that can be drudged through to bash the concept into one's head, like a maths textbook. That doesn't sound exciting, but it is!)
Light Table is such a koan, created by a master of the path of living-memory-image reflective systems, seeking to "tilt" as many parts of the system that Smalltalk is into the light as possible. (Granger's trick was contrasting those parts to a backdrop of regular, ugly concepts like Javascript and Electron that aren't part of the enlightenment-inspiring system. The concept-handles come clear at the visible seams of the Light Table system. Whereas, in Smalltalk itself, the seams aren't visible, because the system is coherent. You can't see the muscles of the perfect average face; it's too coherent to dissect.)
Putting this another way: most people who might be asked about something aren't teachers with education degrees. They're just students who already learned something and want to share what they learned. They fail because the thing is hard to share, and they don't have the skills about teaching required to realize what's making the thing hard to share and to fix it. (Those that do have such skills, but don't have the time to apply them to the concept—dissecting it and re-building it in a teachable-to-others form—usually just keep silent, rather than attempting to share their learning.)
> Haskell['s journeymen] are such failures [to teach the required micro-skills] even in the face of an audience who has previously undergone such a paradigm shift.
Ah, but have they? Many people have a natural mind for software engineering. They take for granted the concepts inherent in procedural code execution on a CPU or virtual machine; in parsing and lexing; even in pseudo-paradigms like OOP.
Indeed, it is the rare software engineer who actually experienced any paradigm shifts regarding Computer Science (for those of us that took a degree in it.) Usually it's "easy"—meaning natural—for those of an analytical mindset.
All, perhaps, except for that one class you have to take at the beginning of a CS curriculum, Discrete Maths. A lot of the SwEng "naturals" struggle at that. Because Discrete Maths is not the same thing as CS. Discrete Maths is, in fact, maths.
Mathematicians are used to paradigm shifts/"englightenments" (i.e. learning systematic skills requiring working knowledge of many micro-skills). Each subfield of mathematics is essentially named for the systematic skill required to comprehend work done under its aegis. Mathematicians who read work in various sub-fields, are used to quickly achieving a journeyman's competence in the relevant systematic skills. Mathematicians who specialize, who enter a sub-field, must necessarily become masters, if they have any hope of building upon that work. They must understand the required skill fully. (They must, by cute analogy, be able to build their Light-sabers from scratch.)
Most software engineers—including Haskellers—are not mathematicians. They have, other than that one time in Discrete Maths, never experienced the feeling of climbing toward an enlightenment. Even then, Discrete Maths is often the lowest grade for a lot of new CS students. They don't yet have this meta-skill of climbing toward enlightenments—of throwing themselves hard at formalized jargon using textbooks and references in an attempt to build a new systematic schema in their brain in just a few days. And they are almost never told that this is the true skill that their Discrete Maths course is there to impart into them. It's not about learning graph theory or whatever; that, just as much as a class on Operating Systems or VLSI or whatever else, is a practical, concrete skill for a software engineer. The Discrete Maths class in a CS program is about learning how to quickly learn those kinds of concepts. It's about discovering that these mental gulfs exist, and learning the skills required to cross one.
If only it was taught as such ;)
The reason Haskell is uniquely bad, here, is that Haskell was—perhaps problematically—constructed by mathematicians, people who had already crossed one such gulf. Haskell's design and ecosystem "reflects" enlightenment on category theory, somewhat like Smalltalk "reflects" enlightenment on living-memory-image OOP. Neither system teaches those skills, though. You don't need to cross the gulf of category-theory to intuit Haskell as a journeyman; you only do if you want to have the appreciation for the "coherent shape" of Haskell required to make coherence-preserving modifications to its feature-set.
---
The long and short of the way to communicate all the Haskell "stuff" efficiently, not just monads, is to:
1. give the learner the meta-skill of Being A Student Of Mathematics (i.e. becoming a journeyman in new systematic skills by poring over textbooks and doing problems);
2. throw a Category Theory textbook at the learner, who is now equipped to digest it.
Anything less is laziness—though not necessarily on the part of the teacher ;)
Two answers. 1) So then someone should create a Haskell Koan which has just as much popular appeal and broad intuitive popular understanding. But then again, not really, because: 2) Really, get off of this Koan nonsense. It was really just a very well thought out and effective demo which chose exactly the right way to get across the benefits of such a system.
Whereas, in Smalltalk itself, the seams aren't visible, because the system is coherent.
Oh, there are seams! And warts!
Indeed, it is the rare software engineer who actually experienced any paradigm shifts regarding Computer Science
Really? It sounds like you haven't experienced too many of those kinds of paradigm shifts. All you know is the math-y kind.
Haskell's design and ecosystem "reflects" enlightenment on category theory, somewhat like Smalltalk "reflects" enlightenment on living-memory-image OOP. Neither system teaches those skills, though.
Absolutely wrong. If you delve into the Smalltalk image and class library, it does teach you OOP!
The long and short of the way to communicate all the Haskell "stuff" efficiently, not just monads, is to:
1. give the learner the meta-skill...
2. throw a Category Theory textbook at the learner...
Either put up or shut up. Anyone can have an esoteric uber language off in a corner somewhere and tell themselves the world misunderstands them while circle jerking with like minded folks. Been there, done that. The whole world is chok full of little groups like that. Stopping at just that is not that which makes a difference in the world.
What you are saying seems to amount to: "We're awesome! We're the superior learners, which is why we're superior, but alas poor us, it also makes us suck at teaching." I call BS. It doesn't matter if your tools are superior, if their qualities and the community's qualities make them inherently inferior at gaining mindshare. Either they're so superior, everyone will take the time to adopt them, or they're not so superior that it really matters that much.
Try and produce stuff. Try and reach people. The world will see who succeeds. Simple as that.
You know that HN readers are about the 99th percentile of "willingness to learn random new CS concepts", right? Most programmers know one language. In fact, most programmers have only ever worked for one company, on one product, for their whole productive careers so far. Your idea of an "average" programmer is, in fact, a rare programmer.
> If you delve into the Smalltalk image and class library, it does teach you OOP!
That is the exact equivalent of reading a textbook on the subject, except it's not presented in prerequisite order, so it's slightly harder to digest.
A system that teaches is a system that allows you to notice the micro-skills you're missing faster than a textbook. A textbook is the brute-force approach.
Smalltalk is not a system that teaches. It's just a system. You can get out what you put into delving through it, but you can do that just as well with any random system. To be pedagogical, a system has to accelerate that process.
> We're awesome! We're the superior learners, which is why we're superior, but alas poor us, it also makes us suck at teaching.
Er, no: people that "know Haskell" (category theory) generally suck at teaching Haskell (category theory) because people suck at teaching by default, because they haven't learned the meta-skill of teaching. And even those that do, haven't yet put in the effort to factor their mental-model of a given skill to turn it into a teachable skill.
The people that can teach you something about Haskell (category theory), are, y'know, teachers, that have learned Haskell (category theory) and then applied educational principles to their understanding of it in order to be able to teach it well.
Has nothing to do with Haskell, other than Haskell actually having a relatively-difficult skill in it for people coming from a SwEng background to learn. Other languages are easier or harder for such people to learn, because the skills they require are more or less natural given a SwEng background; and, comparatively, people with a CS or Physics or Electrical Engineering background have other backgrounds that make different languages have a different skill-gulf. Haskell (category theory) is easy for mathematicians. Assembly is easy for electrical engineers. Prolog is easy for DB systems programmers. Etc. Nothing special about any of them—they're just different points in knowledge-space, that different people start out closer or further from because of their backgrounds.
> Try and produce stuff.
I do! Not in Haskell, though. Despite writing the above, I have literally never used Haskell once in my life. I'm just talking about it as a specific application of the general principle of skill-gulfs.
> Try and reach people.
Why?
In all of the above, nobody ever said why anyone is trying to teach anyone else monads. Honestly, I think people just shouldn't bother. No "amateur teacher" is attempting to teach anyone else graph theory, or linear algebra, or the x86 ISA. Professional teachers, at universities, do that, because those are skills independent of any programming language. People generally understand that teaching these skills is the job of professional teachers, and that you have to apply yourself as a student, full-time, to learn them.
Well, category theory is such a skill.
In short: stop trying to teach people monads. Petition more schools to teach people monads (category theory), outside of the context of any particular language. Then Haskell is just a language, with no skill gulf.
To say that you should "reach people" with an explanation of monads, is like expecting RDBMS docs to "reach people" with an explanation of relational algebra. It's not their job. You're supposed to come in with that skill. Their job is to provide you a thing that you know you want—a solution for a problem you know you have—given that the skills you already possess give you the ability to evaluate that solution.
I'm tempted to share your writing on my other social channels! Excellently done!
It's a joke, but more importantly, it's a joke by and for people who are already familiar enough with Haskell. It's not a serious attempt at communicating something useful about the language; these attempts exist, but this joke is not one of them. Absolutely no-one makes this joke to beginners. You only make this joke to someone who already has an understanding of Haskell. It's not a common joke, either.
It's like those obfuscated C examples. Nobody uses them to teach beginners anything, and it'd be a mistake to ask "why do all these C programmers keep writing purposefully obfuscated code to scare beginners!?". Purposefully obfuscated C code, much like the Haskell joke, is not aimed at beginners.
That should be more accessible for people trying to learn it. The idea that "category" by itself is something that is supposed to be completely devoid of meaning is not clear at first. This slowed me down a lot when learning.
I am a counterexample: the description of a monad as a monoid in the category of endofunctors actually helped me, especially when I was new to Haskell. I am a mathematician, and happen to know category theory enough to appreciate this description. Also, I am a little tired of hearing "you don't have to know category theory in order to learn Haskell". What if I already DO know category theory? I wish someone wrote a tutorial or a book explaining Haskell to mathematically inclined readers and not dismissing (in a kind of anti-intellectual way) simple algebra as "useless abstractions".
"Monad" seems to be just beyond the complexity event horizon where it is difficult for people to get a really clean idea of what it is, so instead we've got dozens of ideas of what they are floating around, probably a good two-thirds of them with fundamental errors in them, which then contributes to the general haze surrounding the ideas.
I've got a mostly-written blog post on deck with the tentative title "Functors and Monads For People Who Have Read Too Many Tutorials", for which around 80% of it isn't explaining what they are, but systematically walking through all the errors I've seen (some of which are in the type notation for Haskell itself; the "[a]" abbreviation for what should be "[] a", if not "List a", alone has done untold damage to comprehension) before finally getting down to what the things are.
(Functor in particular is so trivial it's hard to believe it's that trivial when you finally really get it. Monad legitimately has a bit of a twist in it, and some of the specific uses of that interface take that twist and hammer it home to produce some very funky code, so the fact that it's a bit foggy isn't that big a surprise. The fog that functor has picked up by association with monad is much, much larger than the concept itself, though.)
"So it's a way of imperatively declaring execution sequence dependencies that lets you reason as if there's only pure functions most of the time."
It turns out no, that's just one use of them. A very big one, a very natural one, and the one that drove their prominence in the current debate... but it's not actually what the interface is "about" per se. For a good counterexample, consider the parsing monad implementations that "declaratively" [1] create a parser. It's not really about declaring execution sequences.
(There's also a non-trivial amount of confusion that arises from the fact that monad and laziness have a lot of interaction. The monad interface in a strict language would be used differently than it can be in Haskell.)
Monoid: A data structure wrapping a value of some type that implements the Monoid interface. The interface has two methods: `identity` and `append`. If you implement those methods for your structure and your implementation follows particular rules then... you have a Monoid.
Why are they cool? You can append a lot of things together; not just lists. You now have a generic, binary append operator `mappend` that can join together anything that implements the Monoid interface.
What can you use it for? Well.. lists for a start. Configuration? Sure! Load up configs from the shell environment, the `~/.myapp` file, and the `/etc/myapp` file; concatenate them together with your generic `mappend`... boom. Streams? Sure. Trees? Why not. If you can implement the interface you get the operators. You code can stop caring whether it's a this or that. It can focus more on do this, do that.
Semigroup: a monoid without the `identity` method in its interface.
Functors, also a shockingly simple concept hidden behind jargon.
I've developed such intuition twice and it evaporated both times, when I wasn't using it for long enough.
That's why you would want it. That's what you gain from them. It is a very easy standard to implement if your interpreter is simple, it can be composed into more complex interpreters, and languages that support it come with many basic implementations that you can use to construct something more complex.
The mathematicians are saying basically the same thing, but from another point of view (monoid on the category of endofunctors means computations, with an environment, that you can join one after the other) that focus much more on standards than on usability, and much more on formality than on how to make large structures out of it, so the names are different.
Note that Bracha, knowledgeable as he is in his areas of interest, is painfully dismissive of things he does not understand. I watched that talk where he mentions monads (as well as non-optional static type systems, another subject he dislikes), and he comes across as ignorant and dismissive. I wouldn't use his opinions on these subjects as evidence of anything.
There's no wrapper, and "interface" is misleading since it suggests something that lets you invoke methods on instances whereas actually one of the core monad functions (pure aka point aka return) is something you call with a value that currently has no connection to the monad.
> Then why, oh why, do we have so many people who spout, "A monad is just a monoid in the category of endofunctors, what's the problem?"
The categorical thing is just a joke. It's hard to talk about monads in general because they're very generic, and unfortunately IO is one of the most "monadey" of them all: it's a monad and essentially nothing else. The best way to learn to work with IO is probably to learn to work with other monads first - option or either or writer or state, things that have a canonical presentation in terms of normal functions and values. Unfortunately, even though I/O is a tiny fraction of real-world business programming (when was the last time you actually used "getChar" at your day job?), it's where people tend to start programming.
> So it's a way of imperatively declaring execution sequence dependencies that lets you reason as if there's only pure functions most of the time. This seems to be the case for all functional programming languages/environments. When you get down to it, they're all, in the words of Garrison Keillor, "Pure, mostly."
You've got it backwards. It's a way of expressing operations that lets you reason as if you were calling imperative procedures most of the time, but they are and will always remain be pure functions in a guaranteed sense that you can fall back on. There is nothing "mostly" about it and this is really important, it's what makes functional programming so useful.
True. I used a convenient lie to make a point. If you're interested in learning Monads you should definitely learn it from a proper source like Haskell from First Principles [0], an online course, or someone who really knows what they're talking about.
As I only alluded to and others have pointed out: there's nothing about monads that's inherently sequential or having to do with ordering operations. That's just how the language defined the interpretation of the IO monad. And it also happens that this is the primary topic of concern of TFA.
You might even come to realize that much of what a Monad isn't contradicts the entire premise of TFA... Haskell doesn't even need the IO monad and could implement IO other ways just fine [1].
[0] https://haskellbook.com [1] https://donsbot.wordpress.com/2009/01/31/reviving-the-gofer-...
No. Monad is just a “design pattern”. It’s nice that this design pattern happens to be useful to force sequential evaluation, but it’s just one of the many things that fits the monad abstraction.
Its because its actually a mathematical concept. And that's the mathematical definition.
So Haskell decided to use the same name. Now some people feel, should I explain the math concept, or its concrete representation in Haskell.
Also, its a bit more involved as an interface. In that its not enough to implement the common methods for the interface. You also have to prove that your implementation for each exhibit certain properties, specifically there needs to be an identity value which act as a neutral element, and they must be associative.
Those laws are where things get more mathematical. Because its rare in comp-sci to talk about laws and properties of functions.
No! Monads don't guarantee sequencing. Some particular monad instances do (e.g. IO). But there's nothing inherently sequential about monads. See e.g. point 10 of the following:
Monads in Haskell are used as a mechanism for scheduling evaluation...
This is only partially true. Any language that tries to be fully declarative -- which is to say, that tries to make all effects "part of the value" (and in consequence, part of the type) -- faces the same problems as Haskell. Idris, a strict language, uses monads to model effects.
The C language doesn't make effects part of the type signature, but C program verifiers do add effects modeling. This can be with regards to aliasing (which writes/reads could affect another pointer?), termination or timing.
It's the underlying interest in program verification that drives the use of monads in Haskell, in part because it's program verification that drives the interest in Haskell to begin with.
int err = socket(...) if ( err < 0 ) { do_something; }
err = listen(...) if ( err < 0 ) { do_something; }
Haskell's bind operator >>= makes abstracting this really simple. I wish I had it in C.
For example, for the `if (err) {...}` cases, this is just the `ExceptT` monad transformer.
With regard to understandability, using error throwing code in Haskell is really easy. Implementing it is slightly more difficult, but so is implementing a C compiler. I mean, we shouldn't judge the utility of a thing based on whether the implementation of the thing could be understood by a child. By that measure, children would be incapable of using facebook, because they could not build it.
>you don't have to write these checks every single time
But in real-world applications, the way you react to errors would differ from function to function. Some functions would print a notification to a logfile and return early. Some would terminate the program and send an email to an admin. Some would activate a red "offline" indicator somewhere in a program.
runService=
s <- note SocketConnectionError $ socket AF_INET ...
note CouldNotListen $ listen s 5
note CouldNotBind $ bind s ...
forever $ do
client <- note CouldNotAccept $ accept s
response <- serveRequest client
...
socket :: ExceptT SocketError IO Int
listen :: Int -> Int -> ExceptT ListenError IO ()
main = runExceptT runService >>=
either handleError pure
handleError (SocketConnectionError rsn) = <try again, maybe>
handleError ...
When trying to solve a problem by thinking it through, don't most people think imperatively? Ie by a sequence of steps (statements) that modify the world around them (state) to reach the goal?
It feels like I'm leaning to the imperative side. When breaking down the problem into substeps, I'm already thinking about the sequencing which will later dictate the scheduling.
I've been teaching Scratch[1] to 11-13 year olds for a few years now, and most seem to pick it up pretty quick. However a few struggle (while still being motivated enough to keep trying). Would be interesting to see how it went with a functional Scratch version.
That's not scheduling, that's a data dependency which functional style handles very well. Imperative would be more like deciding you have to unpack the charger and then unpack the phone and then charge the phone, when in fact it's fine to unpack them in either order. http://www.lihaoyi.com/post/WhatsFunctionalProgrammingAllAbo... has an extended example.
Do you have a source? I have a vague recollection of a paper doing some research on that, but cannot find it. If I'm not mistaken, results weren't that clear cut.
Oh good. A write up that’s aware of how unapproachable monads seem. Maybe this will actually be a good, plain-English breakdown.
Four paragraphs later:
> Monads, as a mathematical concept, can be always used as a part of the semantic model, but whether they transpire into the type system of the object language is a matter of design choice.
Oh... well, never mind.
Normally I don't comment on typos (there are more important things in life!), but this one made me chuckle :)
What if, in C++, the semicolon was an operator you could overload?
Your “what-if” is completely meaningless to me, and I’m sure it’s my lack.
Could you expound upon the implications?
To me it is like saying: what if you could redefine the period at the end of a sentence....ok, but why?
It's somewhat conceptually related to Command or Visitor Pattern programming, but Haskell has syntactic sugar to have them basically work similarly to normal statements. Alternatively, this is a runtime-only version of one specific thing that Lisp macros can do to &body scopes, in constructing custom control flow.
This also is only 1 way to use monads, as they're a technically pretty simple tool (an interface with 2 functions) that can be used in a bunch of scenarios.
[If I'm wrong, and I'm probably wrong, I'd love clarifications for myself, too!]
Imagine, you have code "var a=new A(); a.foo(x); a.bar(y); print(a);". How you reimplement it when "a" is readonly structure, not even a object? You will need to implement functions "foo(a, x) -> a" "bar(a, y) -> a", and so on. If you do so, you will have monad.
I think this is a big part of the problem explaining monads. If you don't have the problem, you don't care about the solution. And if you're an imperative programmer, this looks like saddling yourself with a problem you don't need to have, and then jumping through bizarre hoops to deal with the complications caused by a set of restrictions that you didn't need in the first place.
I think instead the right approach is to sell people on the benefits of immutability, and talk much less about monads. When they start to need them, they'll start to see why they want them. Once they see them solve some problems that they actually have, then they'll start to get it.
Monad shines with containers, because you can write tons of useful functions, even your own libraries, for a container, which will operate on generic type T, so you will have lot of functionality available out of box for any new type T, which can be wrapped into container, without any additional effort. It's as powerful as templates in C++, but WITHOUT SIDE EFFECTS, so you cannot shoot yourself in the foot.
It's up to you to modify text manually, or use existing tools for text stream monad.
Beacuse imperative programs are rife with "statements". Opaque lines of code that may or may not do something, somewhere, which cannot be manipulated as first class objects.
Why would you ever wanna program with that weird restriction?
Basically {A; B} becomes semicolon(A, B).
Then you can have hidden state in the semicolon function and have complete control of how (and whether) you execute A and B, and in what order.
https://philipnilsson.github.io/Badness10k/escaping-hell-wit...
In many practical situations, computations have deadlines, which may either be a timeout or the user giving up and cancelling. Languages that guarantee that functions terminate aren't as useful as you might guess, because they don't say anything about how long it will take. (It could be millions of years.)
A guarantee that a function will terminate is useful when you can avoid evaluating the function at all, while relying on a function call's existence (without compile errors) as a proof that the result exists.
It's not too often that you want to know that an answer exists without knowing the answer. This mostly comes up in mathematics when proving things.
That's a theoretical problem, but is it one that comes up in practice? In my experience those languages eliminate the overwhelming majority of long-running functions, so are about as useful as you might think.
But I have little experience with these languages (I've mostly read about them) so I'd be interesting to hear about your experiences.
I wouldn't start porting production systems to Idris just yet, but I do think it's worth adopting the same kinds of techniques: avoiding loops entirely, and making sure that when you do recursion it's very clear from the code what parameter is getting smaller in what sense.
None of these are acceptable in Agda actually, since they would all be partial functions (i.e. functions that are not defined for some inputs.) The simplest, intuitive explanation is that since Agda has dependent types it needs to be able to evaluate functions during typechecking, and if you allow partial functions (e.g. infinite loops, halting functions, functions that timeout, or functions that are undefined for untested input) the typechecking would be undecidable.
Instead Agda has a bunch of built-in tools to help the compiler figure out if a function is total (the opposite of a partial function, meaning it's defined for all possible inputs). Things like the termination checker can detect a subset of all terminating functions, and sized types let the programmer aid the compiler in figuring this out. There are also language pragmas to overide this totality check on a per function basis.
I've implemented an algorithm, that I knew on paper terminated, and had it rejected by Agda, although I'm not experienced enough to know how easily these things are solved in general.
To quibble with "none of these are acceptable in Agda": it seems unlikely that Agda or anything like it would detect hangs or timeouts due to code not meeting its deadline. Deadlines and performance constraints are not part of any type system I've ever heard of. Furthermore, performance is dependent on the compile toolchain, the runtime, and what else is running on the same machine, so it's not even well-defined for static analysis unless you make a bunch of deployment-specific assumptions.
A language may guarantee that a function is total in a theoretical sense, but you might not be able to calculate its value for some inputs in practice. (Consider something like "a ↑↑↑ b".) So this guarantee is subtly different from what most users of computer systems would actually want.
Of course, as a another commenter pointed out, this sort of practical bug-finding is not actually what the termination guarantee is for.
Static analysis is a funny word to use about what Agda does.. Remember, Agda has dependent types, so what you're calling "static anaysis" involves evaluating/executing functions. In fact it needs to be able to evaluate/execute any functions beyond value-level in any imported modules just to be able to parse a sourcefile, due to the presence of mixfix-notation[0] and how it affects typechecking.
> Testing is rarely exhaustive. However, testing will find performance issues where static analysis won't.
How do you test a function that takes a natural number? Not an unsigned integer, but an actual countably infinite natual number? For every natural number n you test your function with, you can construct a new natural number n+1 which your function is untested for, (literally) ad infinitum.
The answer, of course, is mathematical induction[1] and in the case of more general data structures we have the more general structural Induction[2]. But at this point you don't call it testing, you call it proving, and it's this that Agda is aspiring to.
> To quibble with "none of these are acceptable in Agda": it seems unlikely that Agda or anything like it would detect hangs or timeouts due to code not meeting its deadline.
Yes, your right that actually detecting hangs or timeouts would be difficult or impossible. But that's not what Agda does. Agda only allows functions that the compiler can figure out are total, which can never be all total functions (otherwise we would have a solution to the halting problem I think.)
Basically, functions are either (provably total by the compiler) and hence acceptable. In the case of long/diverging computations Agda just has a timeout threshold, where it rejects a function if it takes too long to evaluate it during typechecking. I'm pretty sure that's what would happen if you tried "a ↑↑↑ b".
> Of course, as a another commenter pointed out, this sort of practical bug-finding is not actually what the termination guarantee is for.
Correct, it's not for bug-finding at all, but rather to keep the type theory/logic sound when using Agda as a proof assistant.
Just to be clear: your criticism makes a lot of sense from a software engineering perspective, but considering the general performance characteristics of Agda, and the almost noneexisiting tooling around it, I think we're a couple of years away from "deployment specific assumtions" being something Agda needs to be too concerned about :)
[0] You can define a function "if_then_else_" where the underscores represent arguments, so you would use it like this: "if TRUTH_VALUE then TRUE_CONSEQUENCE else FALSE_CONSEQENCE"
Not my experience, at least if we're talking about constructive type systems (I don't find best-effort-style "static analysis" useful, personally). I don't think I've ever seen any "normal" software testing regime (junit etc.) catch a performance issue that wasn't a straightforward infinite loop of the kind that would be obvious in something like Idris.
> quibble with "none of these are acceptable in Agda": it seems unlikely that Agda or anything like it would detect hangs or timeouts due to code not meeting its deadline. Deadlines and performance constraints are not part of any type system I've ever heard of.
Languages with a more detailed type system that can express maximum evaluation time (in terms of e.g. some set of "primitive ops" for that language) do exist, though I wouldn't consider any of them remotely practical.
> A language may guarantee that a function is total in a theoretical sense, but you might not be able to calculate its value for some inputs in practice. (Consider something like "a ↑↑↑ b".) So this guarantee is subtly different from what most users of computer systems would actually want.
Sure. Requiring totality doesn't eliminate all possible code-runs-for-too-long bugs, only the vast majority of them. I don't see that as a reason not to do it.
By "static analysis" I mean anything you can learn from studying source code without running it. (Though, with Agda this isn't a clear distinction; maybe we could talk about what we can extrapolate about whatever the compiler didn't evaluate.)
I was speaking of testing broadly to include manual QA and running benchmarks. A continuous benchmark will give a graph of the system's performance for certain actions. It's typically not pass/fail, but if the developers notice a regression they can investigate. These slowdowns just aren't correctness bugs as commonly understood and many places don't notice performance issues until after the code goes live and it's noticed via monitoring. (Benchmarks are tricky to write, tricky to run consistently, don't generalize, and miss a lot of things, but nonetheless measure things that static analysis doesn't even try to do.)
"Vast majority": I guess this depends on what you put in the denominator? I can certainly believe that Agda programmers don't see performance issues. But I'll confess ignorance: is this used for anything other than doing math?
I'm thinking more along the lines of: if a more mainstream language had totality checking, what bugs would this actually find in the code that runs in data centers? Plenty, I'm sure. But I can think of lots of things it wouldn't. It's one method of bug-finding among many.
Well we've got to compare similar levels of effort. I think most "normal" teams would find it easier to adopt a more detailed type system than to set up a continuous benchmark and use it effectively. I could be wrong.
> "Vast majority": I guess this depends on what you put in the denominator? I can certainly believe that Agda programmers don't see performance issues. But I'll confess ignorance: is this used for anything other than doing math?
> I'm thinking more along the lines of: if a more mainstream language had totality checking, what bugs would this actually find in the code that runs in data centers? Plenty, I'm sure. But I can think of lots of things it wouldn't. It's one method of bug-finding among many.
I don't know so much about Agda specifically. I agree with thinking about mainstream code that runs in data centers. My thought process was: of the code-runs-too-long bugs I've seen in my career, how many of those could have happened if I'd been working in Idris with totality checking on? I can only think of one (which was due to regex catastrophic backtracking), and I can think of several that would have been caught (the case where the test used the wrong overload of the function being the most production-impactey one).
My experience is that while other methods of finding bugs do exist, the cost/benefit for type systems is just so much better than anything else that I wouldn't even think about using any other technique until I'd tried type systems first.
How did I do?
I do agree that Monoid and Monad aren’t really great names for anyone who doesn’t come from an algebra background (ie basically anyone).
Monads are like LEGOs, you can combine them in any way and what you get is something to which you can attach still more lego-pieces. It doesn't matter how exactly lego pieces are able to connect together. What matters is that you can combine any Legos together with that same mechanism and get as result something to which you can attach even more Legos. Maybe a better name for Monad would have been "Lego".
If monads are the solution to X, and we add a different solution to X to the language, then what are monads for?
Let’s say you have imperative IO. Then promises are a Monad but then you could just add language support for async and promises are not really needed as a Monad anymore.
A more functional replacement for monads could be something like algebraic effects. These could replace monads completely or they could be like multi core ocaml and only give you one shot continuations (so not allowing for list or other multi-shot monads).
In this context I like to think about the continuation Monad. In Haskell:
newtype Cont r a = Cont { runCont :: (a -> r) -> r }
This becomes really obvious how much boilerplate can be "lift"ed in something like the Flare library for PureScript (https://david-peter.de/articles/flare/).
Ex:
lift2 ( * ) (int "a" 6) (int "b" 7)
This generates 2 text fields, hooks up the change events, plumbs them into a third UI component that renders the product of the 2 fields.
Fundamentally we are just saying we want "a * b" but the monad / sidecar does all the extra work to make UI components and hook up the change events.
Then again, this shouldn't be a surprise from an article that describes the Haskell ideas as "the Haskell monadic dogma"! You wouldn't expect a particularly charitable or educational account to start like that.
A much better way to think about it is to think about IO without considering monads at all. One of Haskell's core characteristics is that it explicitly separates code with side effects from code without side effects using the IO type. This is a powerful design in and of itself—it's a tool for helping programmers manage effects and not a hack around laziness.
Personally, more tools to manage effects is exactly what I want. After all, even in languages, code I write is carefully organized to separate most side-effects (API calls, database accesses... etc) from the domain logic, but this happens solely through convention and code organization. Having tools in the language to express the same separation is powerful.
Note how I never needed to talk about monads here—IO is the important concept. With this in mind the real question is not "why does Haskell need monads?" but "why are monads a useful abstraction?". This gets a bit long for an HN comment, but I wrote a blog post with my thoughts a few years back. It started like this:
> I believe the notion that Haskell uses “monads” to enforce purity is rather misleading. It has certainly caused quite a bit of confusion! It’s very much like saying we use “rings to do arithmetic”. We don’t! We use numbers, which just happen to form a ring with arithmetic operations. The important idea is the number, not the ring. You can—and most people do—do arithmetic without understanding or even knowing about rings. Moreover, plenty of rings don’t have anything to do with arithmetic.
> Similarly, in Haskell, we use types to deal with effects. In particular, we use IO and State and ST, all of which happen to form monads. But it is still better to say we use “the IO type” to do IO or that we use State for state than to say we use “monads” to do IO or state.
You can read the rest here: http://jelv.is/blog/Haskell-Monads-and-Purity/
This is by no means a definitive discussion of monads or anything like that; it's just a perspective I found useful for understand what Haskell gets by having a monad abstraction and why it's interesting.
Ironic. The message he's referring to is the only explanation for what a monad is that has made any sense to me.
I also feel that it makes sense. Haskell prefers expressions to statements. When needed, statement-like things are constructed from expressions.
So in a very naive way - here's the problem, When you apply a function and get a result you have no state - the function doesn't remember what happened. In object oriented programming you always have the state - its in the object, or other objects floating around, and methods can always reach out into surrounding objects to get bits of state it needs, pure functional programs can't do this - they have no state except the things that are passed as parameters. The haskellian way around this is to pass around the context of what just happened - vaguely the context is the surrounding bits of data you need to keep track of.
Monads, functors and so on are the ways that haskell keeps and manipulates the context and the value. The rules also have a very nice mathematical theory which they fit into. Most haskell intros start from maths and shoe horn the code into this - its not really necessary. This clarified it for me http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...
You can do it differently if you like, but you have to define the semantics yourself and find out about edge cases that math has already solved, which is the problem that is searched here, I guess...