This simply equates OOP to all sorts of antipatterns, which can be done for any paradigm. “Look at all these functions and imports”, “look at all these types”,

This simply equates OOP to all sorts of antipatterns, which can be done for any paradigm. “Look at all these functions and imports”, “look at all these types”, “this big switch is slow and error-prone”. Thing is, if you have polymorphism in your OO program, you’ll have a set of non-trivial dispatch points in your non-OO program as well. If you use complex inheritance, you’ll have complex overshared abstractions in your function-based code too. Cause it comes from you, not from OOP. Non-OOP doesn’t magically save you from employing specific patterns and architecture. OOP groups functions by data and resolves names based on what’s to the left of a dot. That’s it. Everything else is optional and may be a bad idea independently. Stop chasing these pattern ghosts and use obj.do(things) instead of files 80% full of export-import boilerplates. OOP simply brings namespace with a value, for your convenience. It’s you who chooses to do the “bad idea” parts.