>>68-69
OOP in its purest form is just one way to abstract. It may work for some types of programs (window managers, games, large frameworks,...), but for others it may be unneeded. OOP is good when it's not forced and suits the problem domain, but at the same time you can use it or implement it without the language having support for it. You can write in an OOP manner in C, by just designing data structures and making functions which operate on them. Add some tagging/inheritance mechanism using the structures fields and you have OOP. On more capable languages like Lisp-based languages, it's possible to implement OOP in the language itself, even though CL has CLOS in the standard, but actually implementing a simple message passing interface can be done in a page or two of code. I think that CLOS' way of not forcing methods to be connected with data structures gives you what's best of OOP: extensibility, without actually having to forcibly link that method to some data structure. That way generic operators can be designed which work with all kinds of objects. The most common example of such an operator would be generic arithmethic operations:
(+ fixnum fixnum)
(+ fixnum integer)
(+ bignum bignum)
(+ bignum integer ... bignum) and so on, the actual result's type depends on the input's actual data.
What I'm getting at is that OOP is not bad by itself, and it should be used where it provides some advantage, but it should never be forced or unnecessarily restricted by other concepts. If you keep OOP as just a generic way to extend functions and keep structures with (single or multiple) inheritance of fields/slots separate, then it's fine.
What's called OOP in these days, C++, Java, is nothing more than a forced combination between the concept of method and structures with inheritance, which by itself is a common usage of OOP, but as a general concept it's bad and just leads to people inventing patterns to work around this forced limitation.