The first answer is interesting but I don't understand step 10. Imperative is a model with state and deterministic sequence and Haskell constructs like state and IO monads form imperative DSLs (with some typing burden/advantages). I don't see why the strategy pattern is particularly interesting here (but I see why imperative structures like mutable arrays and associative arrays are interesting). I don't see either why I would especially forget all those design patterns outside of imperative code : for instance the presentation of Connal Elliot "Tangible Functionnal Programming" is a great exemple of the use a kind of MVC pattern precisely to avoid using imperative constructs.
For me at least, the balance lies more in the use of state (easy in python) or the cost of abstraction (no inling and TCO).
Dude, it's a joke. Going to one extreme (trying to write Haskell-style code in Python), then the other (OOP code dripping with Design Patterns), then finding a balance.
(I know what he's talking about with Haskell-in-Python, though. I did that. Briefly.)
For me at least, the balance lies more in the use of state (easy in python) or the cost of abstraction (no inling and TCO).