A non-programmer will just figure the programmer is a bozo (you could tell this joke with a physicist and a geologist, or any combination of <local-in-group-0> and <local-out-group-0>): that's simply how thermoses work.

But a thermos with a switch on the top to say "insert hot" or "insert cold" would be absurd. A thermos is simply a container _with no concept of temperature_, just isolation: it just maintains the state blindly; whether that state is hot or cold is managed by the "caller" who inserts and extracts the contents, inspecting them itself if it wants to know what had been put into it.

Yet I still see plenty of code that does have a variable to indicate what's inside, perhaps an enum {hot, cold} or worse a bool. Yuck -- you should simply store the thing and if you need to know its state you look at it. That variable is something to get out of sync; something you need to be careful to set and maintain, something at threat to a race condition or ill-timed interrupt. Bleagh. If your first language was FORTRAN, OK. Otherwise there is no excuse.

Sadly I see shit like that in pedagogical examples too, which is malpractice.

"I still see plenty of code that does have a variable to indicate what's inside, perhaps an enum {hot, cold} or worse a bool. Yuck -- you should simply store the thing and if you need to know its state you look at it."

Now I'm confused... How are those two things different? The variable indicating what's inside is going to be coming from the actual state itself, no?

It sounds like perhaps you're talking about some case where a developer has somehow copied a state and referred to the copy somewhere else. Or are you talking about a computed variable of some part of the state being a code smell?

He's talking about explicit state, which can be a code smell when you can have equality efficient (or more) stateless solution.

I interpret the story as though the programmer thinks about the world (in this case, the thermos) as actors, acting explicitly on their inputs. This type of thinking aligns with code full of conditional statements, such as checking the input liquid temperature rather than what the thermos does (just keeping the liquid at the same temperature).

To be more explicit, I see "how does it know?" as analogous to code like this:

    if (condition == True)
        return True
    else
        return False

It's a joke about type systems (as I read it). HotDrink and ColdDrink are both subclasses of Drink, and Thermos has a method "void fill(Drink * drink)" and a method "Drink * pour()". The programmer is asking how the calling code knows whether the Thermos is returning a HotDrink * or a ColdDrink * when pour() is called.

Of course, the answer is "the code should know beforehand what's in there". If someone hands you a thermos with no clue what's inside, then you either have to assume it could be hot OR cold (ie. just use the base Drink * pointer) or you have to check the temperature (ie. explicitly check the type of the return pointer using runtime type information or some kind of Variant-style wrapper.

The joke is how does the thermos know whether to keep the drink hot or cold and that a programmer thinks that must be how the system works.