[c_shu]

One of the common nice features in OOP is polymorphism. You have a list/set/collection of objects which are of the same type, but also of different subtypes. They have the same behavior when calling some method and different behaviors when calling another method.

OOP is not a failure. But overengineering is another thing. (Sometimes I heard "Never write static function/method! Do it in OOP way!", though it doesn't make the code simpler or cleaner)

[rdnetto]

A counter-point to this is that OOP languages lack support for ad-hoc polymorphism. i.e. the ability for third-party code to define an implementation of an interface for a pre-existing type. The two approaches used to work around this are the adapter pattern, and explicitly taking an object implementing the desired behaviour as a second argument (e.g. Comparators in Java).

In contrast, most (typed) FP languages support typeclasses / traits, which makes a lot of code considerably simpler.

[jstimpfle]

The examples you mention are very good examples where there is much less benefit in polymorphism (ADTs) than you think.

For one, many implementations have actually different names (such as append/add/__setitem__ in python, or push_back/insert/operator[] in C++).

For another, data structures are important for efficiency. It doesn't make sense to abstract those. You shouldn't use an array where a tree or hashmap is more efficient, etc.

By contrast, look at how polymorphism in datastructures is actually done in C++, i.e. STL. That's not your typical OO approach.