Abstracting Effects with Continuations

Programmers are fighting over a clever shortcut that could replace three versions of the same code

TLDR: The article argues you can avoid rewriting the same logic for errors and delayed responses by using one more flexible pattern. Readers were split between calling it a beautiful breakthrough and joking that it turns a small coding problem into an intellectual haunted house.

A programming blog post about cleaning up repetitive code somehow turned into a full-on comment-section showdown. The big idea is simple in human terms: instead of writing separate versions of the same task for normal data, error-prone data, and slow data that arrives later, the author says you can use one flexible pattern that says, essentially, "just tell me what to do when the answer shows up." In this case, that pattern is called a continuation, and yes, the name alone was enough to send half the crowd into philosopher mode and the other half into meme mode.

The strongest reactions split hard down the middle. Fans were calling it elegant, powerful, and the kind of trick that makes old computer science papers feel weirdly modern. Skeptics, meanwhile, were waving giant red flags: why use a brain-bending abstraction, they asked, when most developers are already struggling with plain old error handling and async code? One common hot take was basically, "Congratulations, you removed duplicate code and replaced it with psychic damage."

And the jokes were flying. Commenters compared the article to opening a kitchen drawer and finding another smaller drawer inside, then another, then another. Others joked that continuations are what happen when programmers look at a simple function and say, "What if we made this a graduate thesis?" Even people who liked the piece admitted it has big "galaxy brain" energy. The drama wasn’t about whether the trick works — it was whether any sane team should unleash it on coworkers before a long weekend.

Key Points

  • The article explains that `Result` and `Promise` are specific ways to model computation effects such as failure and asynchrony.
  • It states that continuations can generalize these effect types and cites Filinski’s 1994 _Representing Monads_ as the theoretical basis.
  • A Gleam example is used in which business logic uppercases keys, fetches values, and returns the lengths of those values.
  • Separate implementations are shown for direct, fallible, and asynchronous fetch functions, demonstrating duplicated business logic.
  • The article proposes a continuation type `fn(fn(a) -> t) -> t` as the abstraction that can separate common logic from computation-specific details.

Hottest takes

"removed duplicate code and replaced it with psychic damage" — throwaway_lambda
"What if we made this a graduate thesis?" — monad_mom
"I understood it right up until I understood it" — async_ferret
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.