[LAC-Tech]

In Design Patterns in Dynamic Programming, Peter Norvig notes that strategies are just trivially replacable with higher-order functions (HOFs).

So that's where this trope is from! A few things:

1. The "just replace it with a higher order function" thing obviously falls apart when your strategy has multiple methods. In which case, the FP programmer might be tempted to supply a record where each field is a function, and maybe they want to close over some shared implementation details and... you've just re-invented objects, albeit memory in-efficient ones.

2. In many languages that support OO, a higher order function is an object, same way a string is, or an Integer.

I might be being harsh here. Presumably Norvig wrote this in the hey day of "OO flavoured" languages like C++ and Java being completely dominant in industry. But in 2022 we can stop repeating this tired trope.

[Smaug123]

Isn't your point 2 exactly what OP said?

> I think it’s more interesting to think of the GoF-language as mimicking HOFs with the strategy pattern facsimile. The strategy pattern reimplements HOFs as a code-level idiom.

[LAC-Tech]

No more than HOFs are mimicking objects.

It's two schools of thought - everything is functions & data, or everything is objects & methods.

[zasdffaa]

Closures are implemented as objects under the skin, but that doesn't make them equivalent conceptually to me. I suppose it's down to syntax, after all if you ignore that you can have anything you like in assembler, but it won't feel very high level.

[layer8]

Closures are a poor man’s objects. Objects are a poor man’s closures.

[zasdffaa]

What's the "poor man's" stuff? Is there a better way I don't know of

[Jtsummers]

https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent

Comes from that koan.