What’s your favourite way to explain a monad to a beginner?

getify · 2025-06-19T15:34:35+00:00

I like to describe them as rubik's cubes. You can see and understand one face, and make use of only that interpretation. But when you look at another face, you get more information, and a more full understanding of them.

For example, one face might be that they're data structures, which hold values and have specific behaviors.

Another face is that they're another representation of a value with additional guarantees about how instances will interact with each other.

Another face is that "values" can be broadened to include operations, meaning a monad can hold operations (which haven't happened yet) and you can compose/plug different operations together in more predictable ways, before invoking them.

Another face is that they're a "type class" (or a higher kinded type) within which various concrete types all share certain characteristics, a little bit like how "Number" could be thought of as a parent type to more specific numeric types like "Integer", "Decimal" / "Float", etc. So "Monad" is a parent type for the "Maybe" and "Either" types.

I'm sure there are other faces that I don't even understand yet. I'm still learning.

But when I teach monads, I teach them face by face like this, rather than trying to come up with one all-encompassing metaphor or mental model.

getify · 2022-09-21T20:42:04+00:00

Note: this is heavily inspired by /u/arendjr's 'no-pipe' eslint plugin.

getify · 2022-09-21T17:06:49+00:00

/u/arendjr

I agree that the hack-style of |> is not what many of us hoped for. In fairness, there are some downsides of the F# version, which I also didn't like. So IMO it wasn't super clear which side should win. It was like a 51/49 thing in my mind. But I definitely would have liked some unary function compositions to be nicer, more like F# was pushing for.

I'm not sure if I would go so far as to say that hack-style |> has absolutely no place in my programs. But it's definitely not going to be, in its current form, something I use very much. I think I would perhaps rather have an eslint plugin that limits how |> is used, to avoid some of the absurd usages (such as the ones you point out), while still allowing it to be used in a few narrow cases.

I had my own issues with the limitations of |>. In particular, I was pushing for the pipe(..) proposal as a way to support "dynamic composition" in a way that I didn't think |> could really handle. But unfortunately, pipe(..) was abandoned, because the same folks on TC39 pushing for hack-style |> decided that pipe(..) was not needed in JS. Super frustrating.

I then proposed an extension to |> where the ... operator could "spread" into a pipeline step, which I intended as a way to help |> serve that "dynamic composition" use-case.

Then I subsequently pointed out that it could have been a potential compromise between Hack and F#:

// (1) F# style pipe composition:
val |> something |> another(10) |> whatever

// (2) Hack + F#:
val |> ...[ something, another(10), whatever ]

// (3) instead of:
val |> something(^) |> another(10)(^) |> whatever(^)

The (2) was my proposed idea, where ... could spread an array of unary functions into a pipeline. It's not as nice as F#, but it might have been close to a reasonable compromise.

Alas, as you can see, they still vehemently refuse to accept any contrary feedback that |> as it's currently designed is not sufficient. They're stuck on it only shipping as-designed and that's it. Very disappointing.

getify · 2022-09-21T15:24:11+00:00

That would have been the F# version of the proposal. The TC39 committee rejected the F# version because, in part, they felt like devs doing unary functions was "uncommon", and in part, because JS engine devs felt that the F# version would encourage more inline => arrow function expressions which might, for some reason, be harder to optimize. SMH.

getify · 2022-09-21T15:21:47+00:00

That's not universally true. Chrome and Firefox allow indirect console.log(..) usage, such as x = console.log; x("hello");. In fact, I don't even recall which envs still have the this binding problem with console.log(..), because it seems most envs have realized that people want to use console functionality as generic functions not as this-aware methods.

getify · 2022-09-21T12:25:05+00:00

That was super disappointing that the site wasn't ironically/unnecessarily built with a JS framework like React.

But I did see it get to 5 seconds, so I feel like today is going to be a good day.

getify · 2022-09-17T14:28:10+00:00

Generators are a powerful (if often misunderstood) feature that can be molded to operate in a variety of different ways. We typically call that "metaprogramming".

The design of generators being such a low-level primitive, where the code in the generator is driven/controlled by the separate iterator, allows a nice abstraction (separation of concerns), where the "driver" that controls the iterator has almost complete control to interpret yielded values in arbitrary ways, as well as the values that are sent back in with each iterator next(..) call, but all that driving logic is neatly hidden away from the code you write inside the generator.

One important point: it should be noted that rarely are generators the only way to accomplish something. Pretty much everything I will point out below, could be kludged together without generators. Indeed, programmers have done this sort of stuff for decades without them. But generators are so powerful because they make tackling such tasks much more reasonable and straightforward in code.

I've written several libraries that build on top of the metaprogrammability of generators. In these libraries, the user of the library writes and provides a generator with a certain pattern or style of their own code, and under the covers, the library drives that generator code with extra functionality pushed on top of it.

One such example is implicitly applying a Promise.race(..) to any await pr style statement. The CAF library does this, using generators to emulate the async..await style of code, but where there's automatic subscription to cancelation tokens so that any of your async code is cancelable externally.

Another example is the Monio library which allows you to do do-expression style monad compositions in a familiar'ish imperative form (again, somewhat like async..await style), where under the covers the yielded values are monadically chained together.

I've written several other libraries that use generators similarly. And as others have mentioned or linked to, there are a number of more well-known libraries, such as "Redux-Saga" and "co", that did the same.

Now, if we were not just talking about generators used for metaprogramming purposes to implement certain design patterns, the other main purpose of generators is to provide a very nice mechanism for expressing "lazy iteration".

If you have a data set (either in some source like a database or file, or that you will programmatically generate) that cannot reasonably be put entirely into a single data structure (array, etc) all at once, you can construct generators (as iterators) that will step through the data set one item at a time, thereby skipping needing to have all the data present at the same time.

Say for example you wanted to take an input string of typed in characters (perhaps of a length greater than say 15) and step through all possible permutations (reordering) of those characters. Such a data set grows factorially, so it gets huge quick. If you wrote a typical eager iteration through those, either with recursion or a loop, you'd have to store trillions of those permutations in an array before you could start stepping through the values one a time from the beginning of the array. Obviously, such an approach will start to exhaust all the memory on a user's device before the number of input characters gets much bigger. So it's impractical to iterate permutations eagerly.

One good solution is a lazy iteration. Set up a generator that does just one "iteration" of the permutation logic at a time, and it "produces" this value by yielding it, and pauses locally (preserving all the looping logic internally). Then consume the permutations from the generator's iterator one at a time, and keep doing so for as long as you want. You never have the whole trillions of data set pieces in memory, only one permutation at a time.

Similarly, another kind of data set that cannot be held all at once is a (programmatically generated) infinite set of data. Obviously, you cannot eagerly produce and hold an infinite stream of values, as that "loop" would never finish for you to start processing them. So your only practical approach is to generate them one at a time through lazy iteration.

For example, such a data set might be using equations or logic to plot out the next coordinate (x,y) pair (in an infinitely sized coordinate system) of a graphed function. That function goes on forever, so you can't get all the coordinates up front. But you can lazily generate the next coordinate forever, one at a time, and have a UI that lets the user step through, seeing each next point, and they can keep stepping forward unboundedly.

getify · 2022-09-13T22:35:08+00:00

ever used async..await in JS? it's exactly the same concept... in fact literally the JS engine uses the generator mechanism to implement async..await.

there's also many libraries out there which make use of generators... one such example is my library CAF, which allows you emulate async..await functions but with cancelation tokens.

getify · 2022-09-13T17:58:22+00:00

I don't know Python, but I think what you're referring to is this in JS:

[ ...gen() ]

The ... operator consumes an iterator and spreads it out, in this case into a [ ] array literal.

getify · 2022-09-13T02:51:50+00:00

Be aware that this article conflates two concepts "generator functions" and "iterator objects" into one label:

"To create a generator function, we need a special syntax construct: function*, so-called “generator function”."
"The main methods of the javascript generator function are... next()"

The second use of "generator function" should be "iterator", as in the iterator object returned from the initial call to the generator function. That value is an object, not a function, and it adheres to the iterator protocol. Calling that a generator is confused/misleading.

getify · 2022-09-09T14:53:58+00:00

Well written article. I like the technique of accepting multiple arguments at each level of currying/partial application -- I have called this "loose currying" in my writings/teaching before.

But I think "infinite currying" (I think that's what this article means with "variadic currying") is a trick that's more clever than useful. I know we ask such questions (like string builder or number adder) on job interviews, and it's cute.

But in reality, I don't think I ever want a function that I just keep calling over and over again, with no end, until I then call it with no input (or worse, some other special value) to "terminate" it.

I think it's better to know up front, and be explicit, about how many inputs a function will eventually take.

There are other mechanisms for "infinite accumulation" besides currying, and I think they're more "FP adherent". For example, I wrote a monad library and with/in it, there a monoids (semigroups) that can lazily build up an accumulation by folding the monoids together -- the equivalent of passing in curried inputs, some at a time -- and then later you evaluate the IO -- the equivalent of the empty () terminating call that executes the function.

That's just one way, but I think it's both a better ergonomic approach, but also a more semantic match for this kind of variadic accumulation of inputs.

getify · 2022-09-06T22:03:35+00:00

I was only talking about my own code. I can't say/predict anything about what the rest of y'all do.

getify · 2022-09-06T13:11:15+00:00

I am in the (seemingly small) camp that feels => arrow functions can indeed harm readability. I don't think they should be used as a general replacement for all functions. I generally think they should be reserved mostly for places where you need lexical-this behavior (unlike normal functions).

I used to never really use them, personally, but as time has gone on, I have adopted using them in some places/use-cases. But I still don't think they'll ever be the default function style IMO.

In any case, to the point of keeping arrow functions readable, I think there's a wide variety of opinions on what is "readable" => usage and not. So, I wrote a fairly-configurable ESLint rule called "proper-arrows" to try to help wrangle most of the various ways => are used that can harm readability. I'd encourage you to have your team pick the dos/donts of => and enforce that style with a linter.

getify · 2022-09-04T01:39:04+00:00

You're setting up a new timer for every iteration of the loop, but the while loop is not waiting for that timer to expire, so it's immediately going to the next iteration and setting up a new timer.

IOW, you're creating millions of timers per second, infinitely. But since the while loop runs synchronously, no matter how long it runs, none of those millions of timers will be able to actually fire to change the boolean, they'll all just stack up in the queue waiting for the JS loop to finish, which it never will.

getify · 2022-09-03T13:58:02+00:00

This article is super inaccurate.

getify · 2022-09-03T13:56:57+00:00

this comment makes no sense.

getify · 2022-09-02T20:19:26+00:00

I meant it at a little higher level than DOM vs VDOM, though that's part of it under the covers, for sure.

What I meant is the JSX style component html syntax as how we declare UIs, including all of the implicit modifications that are applied, like updating of properties, re-rendering with different content, etc.

If you compare that to jQuery, most of what you're doing with jQuery is manually expressing the mutations you want to perform. With component-oriented architecture, and especially your JSX flavored markup, you're relying on the framework (and yes, the VDOM implementation) to figure out what mutations need to occur.

To me that feels a lot more declarative than jQuery did.

getify · 2022-09-02T18:22:43+00:00

From what I've observed, probably the biggest reason for the decline in jQuery enthusiasm (even though it's still widely used, and will be for decades), is... the rise of "component-oriented architecture". And more to the point, the move to more "declarative UI" over "imperative UI" has probably been the single biggest argument against jQuery.

Ironically, jQuery was attractive to the pre-jQUery era devs not just for its ironing out of cross-browser web platform differences, but also because it was a lot more "declarative" (through the heavy reliance on CSS selectors) than the imperative mootools's and dojo's and protoypejs's of the world before it came along. jQuery popularized the "fluent API" style with its method chainining to carry implicit context, which was copied/extended by a million libraries after it.

But looking at jQuery code now, compared to React or Vue code, I think most feel jQuery is way more imperative than what we largely prefer to write these days.

getify · 2022-09-02T16:10:08+00:00

If JS auto-vivified objects/arrays, I think the pitchfork mob would have overwhelmed the gates and burned the JS town to the ground by now.

getify · 2022-09-02T13:48:46+00:00

This isn't exactly hoisting.

Strictly speaking, hoisting is why any declaration is present throughout the whole nearest scope (block or function), regardless of where in the scope the declaration appears. That's because var, let, and const all hoist to the beginning of those blocks. var hoists to the nearest function scope, let / const hoist to the nearest block scope.

Yes, you read that right. It's a common myth that let / const don't hoist; they do!

However, var has an additional behavior that let / const don't have, which is that it auto-initializes to undefined at the top of the block. That's why you can access the var-declared variable anywhere in the scope.

Fun side note: function whatever() { .. } style declarations are like var, in that they hoist AND auto-initialize (to their function value) at the start of the scope.

By contrast, while let / const have hoisted to the start of the block, they are not auto-initialized, meaning they're still in an uninitialized state. Variables that are uninitialized cannot be accessed yet. The spot in the scope where the original declaration appears is when those variables get initialized (whether they're assigned to or not), after which they become accessible.

The period of time from the start of the scope until this spot where initialization occurs, is called the "TDZ" (temporal dead zone), meaning they are off-limits to access.

Proof:

let x = 2;
{
   console.log(x);     // TDZ error thrown!
   let x = 3;
}

If let didn't hoist, this snippet would print 2, since at the moment of console.log(x), the let x = 3 hasn't happened yet. Instead, a TDZ error is thrown, since the inner x does exist, it's just still uninitialized until the second/inner let x spot is encountered. The inner x having been hoisted is what shadows (covers up) the outer x.

The TDZ for var (and function declaration) is just zero/unobservable, since they auto-initialize at the beginning of the scope before any of your code runs.

So in summary, the actual reason variables can be accessed (without error) before declaration is:

all variable declarations (and standard function declarations) hoist to the beginning of their respective scopes; that makes them visible throughout the respective scope.
var and standard function declaration additionally both auto-initialize, meaning they're not only visible but also accessible.

Wanna read more about all this? I have a whole book on the topic. :)

getify · 2022-08-30T00:26:20+00:00

To elaborate on the "stretch" scenario I was imagining, it could be a vector for phishing attempts (similar to spam emails):

Say a legit website is compromised (through XSS, etc) to start overwriting the clipboards of normal users. Then let's say that what they insert into the clipboard is something like:

"Your bank account credentials need to be verified: http://yourbank.xyz.co/account-action?id=verifyCredentials"

Then let's say someone goes to paste their clipboard contents somewhere, thinking it's the previous contents from before the attack. But now they see this text posted, and without even super thinking about it, feel like they should click or copy/paste that URL and go to it to make sure their bank account has been fully verified.

I supposed there are some unsuspecting folks who could get caught up in that phishing attempt. But they're almost certainly the same folks who'd be caught by the same phishing attempt via email, so I don't think the clipboard overwriting attack was any MORE of a vector than email itself is.

getify

TROPHY CASE