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<p>class Bicycle {<p> // data fields<p> void fix (void) {
...
}<p>}<p>b = Bicycle();
b.fix();<p>In Lisp, you would say:<p>(defclass Bicycle ...)<p>(defmethod fix ((bike Bicycle)) (...))<p>(fix b)<p>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...<p>(defmethod sheer ((sheep Sheep) (shep Shepherd))...)<p>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.<p>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.<p>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.