> "Oh but you can replace this with a derived class", it's not as flexible (for example, mix and matching, etc)
What do you mean by "mix and matching"? I feel like a concrete example might help me understand what you're thinking of in this thread.
> Sure if you only do CRUD you probably won't run into those cases. Math heavy, scientific code, simulations, etc might disagree
Ha, it's funny because I've recently started doing more math-y / scientific / simulation work in python, after a career spent mostly doing CRUD-y things in not-python, and I've never been more convinced that it is best to make code as statically legible as possible. It's hard enough to make sure the math and the algorithms are right, I don't want to also be reasoning through dynamic abstractions.
But again, maybe there's a concrete thing you're thinking of here that I'm not seeing!
"Oh but you can replace this with a derived class", it's not as flexible (for example, mix and matching, etc)
> than to have to reason about runtime behavior to determine those things.
Sure if you only do CRUD you probably won't run into those cases. Math heavy, scientific code, simulations, etc might disagree