And I wouldn't be surprised if there were more retired left handed surgeons in their 50s living in rural Switzerland than people who understand what he's talking about.

The blog post is an exploration of an alternative way to structure code in Haskell.

Why is the bar such that Haskell blog posts have to either demonstrate something clearly better then the status quo or that they need to explain the fundamentals of the language?

  In this case that’s the >>= from Maybe.Monad. As long as you satisfy the signature, it’s happy . do has nothing to do with Monads! Who lied to you?

I've been doing a lot of parsing lately and I find I don't need to reach all the way for monad (applicative is usually enough). But I guess that's what ApplicativeDo[1] is for.

  We’ve got to be explicit now which Functor or Monad we’re importing, and you can’t have do notation for different Monads in the same module.

But overall I like the approach of trying something radically new.

[1] https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/appl...

Assuming `IO.readFile` and `IO.writeFile` is replaced by HTTP requests. I can define `writeFile` and `readFile` in a type class and then implement the effect for HTTP variant, hiding the HTTP client beneath.

Is it just wiring it up in mixins, cabal file?

I think general conclusion is that there's no need for dependency injection, environment objects, or similar tricks if module system is rich enough.

For a long time I questioned why Python needs anything but `async def` or `def` (async should be achievable through module or `yield` usage) and `import` statements, to achieve maximal reuse, given dynamic nature of language and modules. We could ignore all object-oriented features, decorators, replace them with modules. Would be flatter and readable compared to bloated feature set.

That era is now over.

   if err !== nil {
      return err
   }