[NinetyNine]

There's a certain allure to saying code should be a certain way because of natural properties of computing, or our own feelings on what things are different and similar from what other things.

The reason OO shines is because it allows you to make that distinction at the domain level rather than the code level. You organize your software into business objects, or components, and have these interact with each other. They allow you to separate it out in a way that a new developer can come to the project, understand what the code should be doing, and look for the classes which seem the like objects involved, including the types of data it has and the things it can do.

There are all sorts of nasty things we've invented in OO over the past few years (mixing up inheritance and composition, using way too much state), but it gives us a lot of advantages from an engineering point of view.

[stock_toaster]

Isn't that a bit of a false dilemma though? Can you not have clean interfaces and separation of concerns without OO -- even with something as 'simple' as python namespaces and dicts?

[el_presidente]

Dicts are objects.

[stock_toaster]

That is an implementation detail due to python's object support. Dicts are a native type, that are hashmaps.

Unless you mean "object" as in "a thing"....

[Maro]

I think he means dicts combine data, state and functionality, expose a clean API and hide the details.

[einhverfr]

This is true to some extent, but a lot of it has to do with the fact that some OOP environments abstract too much.

The tricky part is in defining your interfaces and getting that right. OOP is one option, not the only one, and not something which is strictly an either-or thing.

The object oriented paradigm is a useful tool, but not every problem is a nail, and not every hammer is useful for driving nails.

[pessimizer]

OO isn't the only way to implement the Actor model.