[dleslie]

I wouldn't over-think it and over-describe it.

The "aha" realization that the "container" can be an ephemeral concept and not resident at run time can come later.

FWIW, I think of IO as a container: it contains the risk of side-effects within. All the examples you gave are containers in their own way.

[jerf]

The problem is telling people it's a container is "over describing" it. We don't need to hypothesize about that. We have the space suits and burritos to prove it is not a good didactic approach. It is not removing from the definition to simplify, it is adding to the definition, exactly as I carefully showed in my description of "Iterator". An Iterator is "a thing that presents a series of items". It does not simplify the discussion of Iterator to say "It's a thing that presents a series of items out of a container, but also, it doesn't have to be a container". It's not the first definition that's "overdescribing", it's the second.

[dleslie]

Containers make sense.

Abstract computer science doesn't.

Part of why Haskell appears like such an implacable curmudgeon is the predilection of its community to believe that users must grasp type and logic theory to use it.

They don't.

Just like they don't need to have a mental model of their computer to write software for it.

[Koshkin]

In my experience, not having a mental model of the computer you are going to run your software on will bite you on the ass sooner or later.

[dleslie]

Countless mobile apps and web sites have been made with nigh-zero understanding of the VMs, rendering engines, or underlaying machine architecture.

It's not the 80s anymore.

[DagAgren]

I'll just point out that neither of you have managed to really take a single step towards actually explaining monads.

[jerf]

I'm not trying, so that's not a surprise.

This has inspired me to try to update my post on the idea in a side window, but it's been sitting on my hard drive for over a year now and probably still has a ways to go yet.