Yes. Also, a great example of democracy at work. A citizen saw a problem, collected data, got a proposal to government, and government actually fixed the problem. We need more like him.

Nostalgia is a powerful drug

Oh, that music! I never been a fan of Ragnarok Online and even only played it on my own local bootleg server, alone, in 2005, but I somewhat liked this game because it felt very weird. Lots of nostalgia feelings when I listened to this music now.

Haskell has no syntax in the core language to sequence one expression after another.

It has quite a few alternatives actually. Depending what you mean by “syntax in the core language”, there are some things with specific grammar rules in the Haskell98 and Haskell2010 standards; there are some “userspace” functions/operators (i.e. their syntax is a special case of functions/operators) which are nevertheless mandated by those standards; there are some things which the de facto implementation GHC supports (e.g. via commandline flags); etc. Here are a few:

• a : b is the expression a followed by the sequence of expressions b (all of the same type)
• a ++ b is the sequence a followed by the sequence b (again, of the same type)
• [a, b] is a sequence of the expression a followed by the expression b (of the same type)
• (a, b) is a sequence of the expression a followed by the expression b (can be different types)
• f . g is the expression g followed by the expression f (input and output types must coincide)
• g >>> f is the expression g followed by the expression f (same as above but their order flipped)
• a -< b is the expression b followed by the expression a (must have compatible input/output types)
• do { a; b } is the expression a followed by the expression b
• f <$> x is the expression followed by the expression f (must have compatible input/output types)

These all define a specific order on their sub-expressions. They’re not all identical, but they follow roughly similar usage:

• a : b tells a Prolog-style interpreter to perform the computation/branch a before trying those in b
• a ++ b generalises the above to multiple computations (the above is equivalent to [a] ++ b)
• [a, b] is a specialisation of the above, equivalent to [a] ++ [b]
• (a, b) generalises [a, b] to allow different types. We can use this to implement a linear sequence (it’s essentially how GHC implements IO). Somewhat surprisingly, and completely separately to anything IO related, it also represents parallel composition
• f . g is a rather general form of composition
• g >>> f is the same as above
• a -< b is is part of arrow notation and desugars to a mixture of sequential and parallel composition (using lambdas, >>>, (a, b), etc.)
• do { a; b } is a generalisation of b . a, corresponding to join (const b <$> a), which is the most similar form to the ; operator of other languages you refer to: both because it has the same syntax (an infix ; operator) and a similar meaning (generalised composition). This can also be written as a >> b, and is related to a >>= b and a >=> b which are also built-in sequencing syntax, but didn’t seem worth their own entries.
• f <$> x is generalised application of f to x. That generality also makes it a composition/pipeline operator

The reason I’ve listed all these isn’t so much to say “look, there are some!”; but more to point out how many different meanings the word “sequence” can have (a list of values, an composition of functions, a temporal ordering on side-effects, etc.); how many different implementations of sequencing we can build; and, most crucially, that they all seem to overlap and interminge (e.g. the blurring of “container of values” with “context for computation”; how we can generalise a single thing like “composition” in multiple ways; how generalising seemingly-separate ideas ends up at the same result; etc.). This tells us that there’s something important lurking here. I don’t think investigating and harnessing this makes someone a wanker.

Monads only matter for representing sequential execution in extremely constrained languages, like haskell. (Some people believe monads are useful for other things, but I’m not interested in that debate, I’m just talking about where monads are certainly important.)

This is not true. Monads are critical for code reuse. I’ve used the concept of a monad in many areas, but explicitly and critically in Scala.

Haskell has no syntax in the core language to sequence one expression after another.

Yes it does: do-notation. You can even use semicolons if you don’t like newlines. It’s the syntax to sequence expressions which can be sequenced. You can’t use semicolons to sequence things that can’t be sequenced in other languages, either.

And why talk about Maybe but not MonadPlus, free monads, transformers…? All you know is Maybe and IO? Of course it’s boring to you. In stead of writing blog sized posts about how blog tutorials don’t teach you everything you could read up, but oh well you do you.

By changing each stage to take and return a fat outer type holding the entire context, you can just as easily achieve the cool pipeline effect by defining >>= as function composition rather than bind.

With bind you don’t have to change each stage.

Understanding how to write programs which allow change without triggering catastrophic rewrites is pretty useful.

Understanding why some programs are easy to modify is pretty useful.

Having language to discuss why some programs are easy to modify and others are not; also pretty useful.

The original post is about how thinking in terms of Monads can make a program which is hard to modify into a program which is easy to modify, it’s a useful post.

Some people believe monads are useful for other things, but I’m not interested in that debate, I’m just talking about where monads are certainly important.

First of all, by far the most popular monadic interface in modern software development is not Haskell’s IO type, it’s JavaScript’s Promise type, together with similar systems for writing asynchronous logic in other languages. If we’re talking about use cases where monads are “certainly important,” I think it’s worth mentioning the large number of programmers writing monadic code on a daily basis in languages which certainly do not lack native support for semicolons.

I love monads and find they’re actually among the most useful and important tools I’ve ever acquired as a programmer, but I agree that the PLT and functional programming communities could do a better job communicating exactly why monads are actually important. The use of monads as “extendable semicolons” does have some narrow but critically important use cases, such as asynchronous code, exception handling, and recursive backtracking, but I actually believe that the exotic forms of control flow you can express with monads is of only secondary importance.

In my experience, the most important consequence of modeling side effects with monads is that it allows you to reliably distinguish between pure and impure functions. The features which you claim make Haskell “extremely constrained” in fact give it an entirely new dimension of expressive power, because whereas most languages only have one form of function, which is implicitly allowed to perform side effects, Haskell has two forms of functions: functions which may perform side effects, and functions which may not. Given that a function’s interaction with an environment is an extremely important aspect of its semantics, this is information that you would be informally documenting and keeping track of anyway; Haskell just allows you document it in a precise, machine-checked format with great integration with the compiler.

This immediately allows you to separate functions which perform IO from those which do not, but that’s not actually the coolest part. The coolest part is that once you start defining your own monad types, you can express much much more precise and interesting classes of side effects, like “a function that interacts only with a random number generator” or “a function that interacts only with my database state” or “a function which interacts only with a sequential-identifier generator.” This is the real power of monads: the ability to make fine-grained guarantees about the data dependencies and side effects of a function given only its type signature.

I doubt that was the intention? It’s more like a personal experience report.

There’s no term for it, but the alternative is structured data: a “binary” AST with data at the leafs, and if that data is text it has to be with explicit mentioning of the character table.

Yes, you can see the equivalent of a glider in the gif. It’s a lopsided donut.