Hmm... that assumes the Java/C++/Python technique of methods belonging to objects. The CLOS (from Lisp) technique is to define the methods independent of the o

Hmm... that assumes the Java/C++/Python technique of methods belonging to objects. The CLOS (from Lisp) technique is to define the methods independent of the objects. That is, in C++ you might say class Bicycle { // data fields void fix (void) { ... } } b = Bicycle(); b.fix(); In Lisp, you would say: (defclass Bicycle ...) (defmethod fix ((bike Bicycle)) (...)) (fix b) So now, for the sheep/shepherd example, you no longer need to decide which class the method belongs to. You simply define a shepherd and sheep class and then... (defmethod sheer ((sheep Sheep) (shep Shepherd))...) I guess what I'm trying to say is that OO doesn't necessarily suck for the given reasons. The examples that the author gives are a good case why the C++ version of OO sucks, but OO in general is much more interesting. That's not to say that everything has a good OO solution. I am definitely in agreement with pg that OO is hardly necessary for the vast majority of problems, and that it typically leads to spaghetti code. I recently wrote a small Lisp interpreter in C for a Programming Languages class. I found it quite interesting that after defining S-expressions and a few operations on them (cons, car, cdr, ...), I didn't really need any other data structures. One simple, powerful data structure makes all that other object cruft unnecessary.