Map and Filter are nice because they let you reason locally about a single element in isolation. Reduce(Fold) forces you to reason globally about intermediate results. Reduce also forces you to conjure up a "zero" value of the relevant type, which isn't usually difficult but it does constitute some extra mental overhead.
That's what I'm used to as well, but in my experience a lot of programmers take fold and reduce to be synonyms. A monoidal reduce is much less "scary" than a general fold. I suspect most programmers have never[1] heard the word monoid, let alone know what it means, and having to remember the meaning of a weird new word is enough to make most people dislike something compared to the simpler more familiar operations.
[1]Or if they have, their only encounter with it is the "a monad is just a monoid in the category of endofunctors" meme.
It just means if you have some functor F (generic type with a well-behaved `map` function, like List), then you have a `flatten` operation F[F[_]] - > F[_], and like a monoidal product, it's associative. So if you have a triply nested List, you can flatten inside first or outside first. Also, like a monoid, it has an "identity" function wrap: A->F[A] (e.g. x -> [x]). Identity in the sense that "multiplying" (flattening) with wrap does nothing. i.e. wrap(flatten(x)) = flatten(wrap(x)) = x when those things make sense.
So basically wrapping and flattening behave in a sane way. Flatten is your multiply, wrap is your multiplicative identity, and it's like a monoid if you squint.
"The meme" literally comes from a book that was offering it as an intuitive explanation of a long definition, assuming you know what a monoid is. All the laws and stuff boil down to "if you generalize the idea of a monoid a little bit, and if you have some functor+flatten+wrap forming a monoid, we call that a monad." If you don't know what that stuff means then obviously it's not for you, but if you do, then it's actually a concise way to give an intuition for "what (or why) it is," which is basically just that flatten is associative and wrap is neutral.
Like if someone says they know about rings and modules, you might say that an ideal is just an R-submodule of R, which grants an interesting perspective and gives a quick, memorable definition. But if they don't know about modules, you might not give them that definition.
The point is that the terminology surrounding this is impenetrable and non intuitive. Rather than acknowledge that, we get a lesson on category theory, which is missing the point.
Do you want to understand monads, or do you want to understand the original quote that the joke you referenced was based on?
For the record, the original quote by Saunders Mac Lane is "a monad in X is just a monoid in the category of endofunctors of X, with product × replaced by composition of endofunctors and unit set by the identity endofunctor."
That quote is a statement in category theory. The author probably never heard of, say, Haskell - he was a pure mathematician. You can't usefully express that quote in Haskell code. You can treat it as a kind of formal description of what monads are, and Haskell generally conforms to that. But in that context, the quote itself is essentially using category theory as a metalanguage, in the same sort of way as one might write a mathematical statement that captures the semantics of some programming language expression.
That said, the quote can be handwavingly understood if you know what a monoid is, and that for monads, the identity object is the identity functor, its product is `join`[1] and its unit and multiplication satisfy the usual monoid laws.
For a concrete example, consider this Haskell expression using the `Maybe` monad:
do
x <- Just 3
return (x + 1)
That desugars to:
Just 3 >>= \x -> Just (x + 1)
Which we can desugar to an expression in terms of the monad's monoidal product, `join`, by substituting the definition of `>>=` in terms of `join`[1] to get:
join (fmap (\x -> Just (x + 1)) (Just 3))
You can evaluate that in Haskell and you'll get `Just 4`, just like the original expression.
So what happened there? The inner expression `fmap (\x -> Just (x + 1)) (Just 3)` applies the anonymous function to `Just 3` to get the double-wrapped `Just (Just 4)`. One of the `Just` wrappers is then eliminated with `join`.
(Btw, the fact that we have a Maybe within a Maybe here is related to the fact "monads are monoids in the category of endofunctors" - a category that maps to itself. That's where that part of the quote comes from.)
In this simple example, there's some unnecessary machinery - you can get the same result with `fmap (\x -> x + 1) (Just 3)`, without the extra `Just` wrapper or the `join` to eliminate it. But then you lose the ability to do things "in the monad": the anonymous function becomes just an ordinary function, it doesn't have access to the monadic wrapper. Many of the useful things that monads can do are because the wrapper is available in every function, so you can store state in it (Reader monad), create new wrapper instances with different state and pass those on (Writer and State monad), etc.
The accumulator is global state. If you're folding from list<int> to int you're right that it's (usually) effectively a pairwise operation on ints. If the fold is something like list<foo> -> tree<bar> then you have to reason about each intermediate (tree<bar>, foo) -> tree<bar>, i.e. how global state should evolve over time with each update.
> Reduce also forces you to conjure up a "zero" value of the relevant type, which isn't usually difficult but it does constitute some extra mental overhead.
It's always worthwhile to consider what the result will be when you pass in an empty list.
If you have need of a reducing operation though, you will still need to think about that value. If you are summing up a list of numbers, it doesn't matter whether you use reduce or a loop, you need to set some initial value.
I agree, although most of the time you do end up needing to consider it with Map/Filter. It's just, it doesn't force you to. Which means either you think about it later, or it bites you in the ass because you didn't consider the empty case. Not always—and for those cases where you don't end up needing the empty case, Reduce is probably not necessary, and Map/Filter is sufficient.
> Reduce also forces you to conjure up a "zero" value of the relevant type
It's more accurately an identity. If you are multiplying the identity is 1. While I think most people are comfortable saying the sum of no elements is 0 it's perhaps less intuitive that the product of no elements is 1. This makes me think reduce might be preferred by those with a mathematical background.
One possible solution is to only be able to contact someone if you have received an invitation code from them out of band. E.g. "scan this QR code to add me on signal". Such an invitation code should default to single-use but users should be allowed to generate standing invitations so that businesses and the like can print and post one in their store or whatever. Start getting spam from one of your standing invitations? Just revoke it and make a new one. Presumably the Signal folks can come up with more alternative solutions than the half baked one I came up with after thinking about it for a minute, they're clever cookies.
Welcome back to “key signing parties”. PGP never got enough adoption. At least Signal is simple enough that the (ahem) leaders of the US can (mostly) manage to use it.
Unfortunately, in an end to end encrypted messaging system, an identity is denoted by some sort of long number. That is an inescapable fact. Trusting a third party to correctly map, say, a phone number to a cryptographic identity number eventually results in the sort of attacks we have been seeing with phone oriented encrypted messengers recently like WhatsApp and Signal. The PGP people were doing the right thing when they were doing education in the form of key signing parties. That is something the user needs to know.
Anonymous messengers have no real choice and have to use some sort of number for identity. See Briar, Session or Tox for examples.
> attacks we have been seeing with phone oriented encrypted messengers recently like WhatsApp and Signal
Could you give an example of an actual attack of this kind on Signal? The 'Signalgate' event was someone mistakenly inviting the wrong person to a chat.
Allegedly, Signalgate was caused by Apple helpfully mapping the wrong number to a name. Then Signal mapped that number to the wrong cryptographic identity.
> Allegedly, Signalgate was caused by Apple helpfully mapping the wrong number to a name.
In what system is Apple mapping numbers to names? The address book is maintained by users. An AppleID? How could that happen? And it would seem to result in many errors before the Signal error.
I thought it was simply caused by someone adding the wrong person to the chat?
> The Intercept
Per that article, the cause is unknown. The speculated cause in the article is that The Intercept somehow lost control of the user id, and Signal recycles user ids. That seems like a bad practice generally and with this predictable consequence, and especially bad for an application people trust with security.
> Twilio
This was Twilio employees caught by a phishing attack. I wonder what more secure, and affordable, options Signal has. Operate their own SMS infrastructure - would that be more secure that Twilio's? Use something besides SMS - would on-boarding become too hard? Stop using phone numbers - they need some spammer and bot filter, so what replaces it?
> Russian State-Backed Hackers
A phishing attack on Signal users, using a QR or link to make the attacker a linked device. That setup seems risky for non-technical users; I wonder how Signal could better secure it.
That and other attacks are described here. The other attacks all require compromising the device on which Signal is installed:
Leaders of the US use an Israeli backdoored version of Signal (TM-Signal) TeleMessage by Smarsh was used by DOD, CPB, and others for records retention reasons... also hacked to smithereens.
People seem to get on with Discord invite links just fine. You don't have to do the "confirm that all these emoji are the same on both your devices" dance to stop spam.
> People seem to get on with Discord invite links just fine.
Discord is used by a narrow group of technically literate people. Signal is for everyone. Your grandparents probably don't use Discord, but if they can text then they can use Signal.
Imagine setting up a chat for an organization you're working with - will you be willing to process 20 out-of-band QR codes? 50?
On a smaller scale, it's clear that Signal believes a functioning address book is necessary for end user adoption. For example, by default Signal notifies you of people in your phone contacts who are on or who later join Signal.
> Presumably the Signal folks can come up with more alternative solutions
I have yet to see a solution better than the one they chose, for their requirements. Notice that there are none in this discussion.
> Finns and Norwegians only are able to bike part of the year.
They very much bike all year round, even in the north where it regularly gets to -20C(-4F) in winter. Biking in snowy sub-freezing weather is really not a big deal as long as you maintain the bike paths as well as the streets.
Source: have lived there, everyone I knew had a bike they regularly used. The only time I can recall where people I knew who usually commuted by bike didn't do so was during an unusually heavy snowstorm. They instead had to walk about half a kilometer to/from where the city had managed to plow the streets and take a taxi. That was decades ago.
> Source: have lived there, everyone I knew had a bike they regularly used.
I don't live in Finway or Norway. It would be nice to be in a country that accepted a more pescetarian / fish-based diet. It might help with the able-bodied reasoning given elsewhere for car driving.
But I live in the US. Here in the US, the loudest advocates we have for biking are groups like Critical Mass. Up in Chicago they have a winter biking campaign. But we know how Critical Mass is perceived by people on the fence about more biking investment. It's a radical group. So discussion digresses into sidewalk safety issues and identity politics. And yes, sidewalk safety impacts people, falls are dangerous for many populations. But all that media bandwidth means simple messages of celebrating biking and transit get lost. There's only limited time on the news.
This isn't an isolated issue. I honestly think that's by design. At this point, in 2026, it's not an accident.
So you have people like me, jobless pervert civil libertarian hipster techbros being the group advocating for more biking. What do you think is going to happen US?
Waymo will be the same thing.
It will be turned into a drama show about saving people feom drunk driving accidents, a very good thing. But then there will be pushback about it encouraging more drinking among the population and increasing rates of domestic abuse. A very horrible and tragic thing.
And some of us will be going to a food pantry wondering why it can't be a more bike oriented endeavor and knowing the truth in our hearts. The US wants drama, even after Trump is gone. And that drama takes focus from just rolling out programs to encourage love of public transit and biking. Media saturation matters. And I don't believe anymore.
So, I'm sorry, Chicago or up north doesn't seem like a great choice personally. It's not healthy for me to dream about up families up there. I'll be biking out west.
Heretic[1] is not that far off, though I suppose it's more along the lines of undoing the "for your own safety" lobotomy than explicitly specializing in unsafe things.
You don't need explicit consent for functional cookies, e.g. a session cookie or to store what preferences the user has selected on your settings page. It is implicitly given by the user telling you to treat them a certain way. For that you just need a notice somewhere on the page that reads along the lines of "this website uses cookies". It can be an unobtrusive note in your footer.
You do need consent even for the necessary exemption in practice because of how that is defined; the user must have explicitly asked for the function that requires the cookie:
> strictly necessary in order for the provider of an information society service *explicitly requested* by the subscriber or user to provide the service.
But this the basis for the OK-only style of banner, to inform the user that certain functions require and will use cookies if they use those functions.
Dropping permanent cookies for any of this stuff is not strictly necessary; session cookies would be sufficient, so then to do anything convenient (e.g. persistent cart, Amazon-style) but not necessary you still need to request consent.
GDPR's legitimate interest basis is better written. But ePD is not superceded by GDPR, they are layered on top of each other.
Site builders argue to themselves that what the regular user would want to do -- e.g. close the site and browser, come back to it and expect the items in the cart are remembered (for some amount of time, e.g. a month, not forever) -- is something the GDPR (or ePR) would strictly prohibit. Neither prohibit this. You can use persistent cookies or local storage for maintaining the user's cart.
The reason they massively overstate what the regulations prohibit is because there are many things they want to do: user tracking and analytics, marketing engagement, etc., and know fine well the regulations prohibit that unless they get consent. So they pretend they can't possibly even do a basically functional site without getting consent, which is bollocks, so they don't feel so bad about imposing a consent banner on every visitor.
The same thing happened in the UK where businesses told customers lies that "Health & Safety made me do this" or "the EU made me do this"
Why would he do that? Billions of users prove him right. I wouldn't change my views either if I'm right. It's society's fault for being dumb fucks. This creep it's just exploiting that.
Market forces are not effective at creating good outcomes when there is an oligopoly.
If there are two producers each with ~50% market share, it's not profitable for one of them to improve their product such that they capture an additional 5% of the market but reduces the profit margin of their product by 10%. If there are 50 producers each with ~2% market share, one of them would happily capture 5% of the market (more than doubling the size of their business!) by sacrificing 10% of their profit margin.
In the Google-Apple duopoly it's much more profitable to engage in tacit collusion than it is to defect.
First, copying information isn't wrong to begin with. It is literally the one thing that makes our species special.
Second, even if you are a copyright maximalist the output of an LLM is either
a) not subject to copyright because it is not the creative work of a human or
b) a derivative work of the original training material to which the LLM's operator has no rights.
Since the LLM's operator forcefully asserts that it is not infringing, any wrong that arises from taking their word for it and distilling one model into another rests squarely with the operator of the former.
It's not just good PR for politicians to pass "<specific instance> case of already illegal <generic> is explicitly illegal"-laws. Prosecuting a violation of <generic> tends to be a lot harder because in addition to providing evidence for <specific instance> it requires convincing a judge that <generic> even applies to <specific instance> in the first place. You get to short-circuit that ordeal by passing a law that clarifies the intent that yes, <specific instance> is in fact an instance of <generic> without having to go all the way through setting precedent in higher courts.
reply