Haskell doesn't encode them. And other concepts can be given a mathematical definition if someone wanted to formalize them.

People unaware of the laws invent things that are almost monads but break in edge cases. E.g. Scala's collections with flatMap where you can mix and match collection types are almost, but not quite, monadic. Javas Optionals as discussed in parallel threads are similarly almost, but not quite, monadic. And this kind of almost correct implementation is more dangerous than a blatantly incorrect one.

Uncalled for. Try to follow the guidelines instead of calling people names.

> Mathematical rigor is also not comparable to whatever sense of rigor might apply to those concepts.

The two senses of rigor at hand are comparable at the level of frameworks of human knowledge. Comparable (not equivalent!), for example, in the sense of what these ways of knowing are seeking to know, and how they are seeking to know it. We are discussing software development practice here, so what is it exactly that these two ways of knowing are seeking to know?

The way I see it, in the context of software development, the commonality between Monads and a specific design pattern, say MVC, is that they are both tools in the developer's toolkit. Specifically, tools for structuring software abstractions. A bonafide concrete Monad gives guaranteed well defined compositional behavior for a particular class of operations on a particular class of objects. The Monad definition gives an abstraction for composable software abstractions. A design pattern describes a configuration of abstract software elements and/or roles, and a schema for composing these elements and the communications (protocols) between them. A single design pattern often describes a family of potential realisations. A design pattern, when documented properly (as in the PLoPD books), and applied appropriately, can be reduced to a practical solution that is no less robust (in practice) than the employment or definition of an object with a monadic interface. From a practical software development perspective they are of the same kind.

From a formal methods point of view the two are different. Monad has a settled mathematical definition, well understood properties, an exists within an established branch of mathematics. Application of the Monad definition to computer programming is supported by a body of established computer science that confers various mathematically proven properties. By contrast, a design pattern does not have a mathematical definition at all, and importantly for this conversation it does not claim to have a definition. A design pattern documents a way of doing things that is known to have worked for multiple past systems. It is literally an abstraction of a common pattern of practice, together with context, recommendations for use, contraindicated scenarios and so on (see my "context" comment elsewhere on this post). This is no more handwavy, and no less apposite, than the guidance given to an apprentice craftsman. Of course there is nothing to prevent someone from reducing a design pattern to a formal definition and attempting to verify properties of interest on it (I imagine this has been done).

Most developers today are not equipped to formally define and verify a Monad, or to reduce a design pattern to a formal definition and prove properties on it. Most software systems do not automatically check and enforce the Monad laws. In software practice, there is little between them. They are both tools for organising abstract software structure.

What does a “monadic architecture” look like? I’ve been writing web applications in Haskell for the past decade and all of them are MVC.

I don’t really understand what a “monadic architecture” is supposed to mean.

Haskell’s `Monad` type class is hardly the only possible encoding of a monad. They’re just a simple mathematical construction with useful properties, and — like functors and applicative functors — they emerge everywhere.