charmonium's comments

Why does the "Comparison" table show "Nix" as "No" for "Containerized"? One can [run Nix in containerized environments](https://nix.dev/manual/nix/2.24/installation/installing-dock...), [build containerized environments from Nix](https://nix.dev/tutorials/nixos/building-and-running-docker-...), and [even run Nix-generated environments directly in containerd through a plugin](https://github.com/pdtpartners/nix-snapshotter/blob/main/doc...). I believe the former two apply to Guix as well which is also marked as "No" for "Containerized".

Generally agree, but consider the counter-example of regular expressions, where the purely in-language notation is so much more verbose than putting a string-literal of a minilanguage in the larger language. Usually, we don't need to use the larger language to dynamically generate elements in the minilanguage (most regexes are string literals).

One must consider the cost of developing/maintaining new language parsing infrastructure (main point of the blog) against the readability/conciseness/features of a new syntax (not discussed in the blog).

I'm starting to come around to that view, especially since shell is an unusually productive REPL. What are the "right circumstances" for a shell script in your experience?

This is exactly why I wanted to write this post. I feel like the pattern is valuable besides "we need it to have stateful computation." I have to mention this use for completeness, but I wanted to focus on using monads as another abstract software development pattern, because that's how it is applicable in non-FP languages (async/await for example).

A few observations which might also be false.

We can have arbitrarily nested monads:

  monadicObj.bind((T value) => monad.wrap(monad.wrap(value)));

Remember, `bind` only unwraps one layer. Without it unwrapping one layer, programs would continue accumulating large stacks of monads in monads.

I would also point out that it only collapses abstractions of the same kind; Maybe's bind only unwraps one layer of Maybe's. If you have a Promise<Maybe<Foo>> where Foo contains potentially more monads as instance-variables, those don't all get collapsed.

I like the 'converting nesting to concatenating' observation.

Sometimes we do need parentheses though, because most languages are not associative 5 - 2 - 1 is not the same as 5 - (2 - 1). Basically minus does not form a monoid, so the parens matter.

What exactly do you mean by stateless? Encapsulation in the OOP sense is not stateless, because two identical method-calls may not return the same value. Example: if you have an ArrayList, calling `size` at one point in time might have a different result than calling `size` now. That's why I say the list 'remembers' its 'state'.

An object wrapper has to have the object somewhere in memory, you just can't touch it. With a monad, the object might not even exist yet (example: Promise) or there might be more than one (example: Collections).

Promises, as exposited in the article, are an interface for bona fide monads. I think Promises are the best example of monads because they don't just wrap a type in memory. Maybe is kind of a subset of List (as you mention), and for both the contents are available in memory. Promises are not like Lists, and their contents can't just be pulled out, so you have to use `.then` (monadic bind) to do computation on them.

A part of the push for rigor in calculus is being able to prove results instead of appealing to intuition. They are both important aspects of mathematics when working together (often intuition guides a slower, rigorous, methodical proof), but we don't want people relying on intuition where a proof is necessary. This kind of critical thinking and logical reasoning are both important cross-disciplinary skills that almost every field requires.

when you get to 5x + x = 6x, you can't simply memorize a similar sequence. Knowing how the sequence is created is much more valuable than memorizing the sequence. You do loose some speed, but critical thinking is more important than speed, especially with the onset of cheap personal computers and calculators.

Perhaps math classes should focus less on remembering algorithms and more on inventing your own algorithms by solving novel problems. In that context showing work is much more meaningful.