[kbuchanan]

I offered a counter example to the comment author too (Clojure has been wonderful for us), but I do wonder if there is one area where OO languages excel above functional: the shape of the code hints at the shape of the data.

In Lisp, function names describe actions. In OO, classes, inheritance, static properties, and getters and setters give at-a-glance hints as to the shape of the application's data model. In Clojure, we compensate, as you pointed out, with forms of documentation. I'll take that trade-off any day—I never want to go back to classes! But it's perhaps one reason for which Clojure has a reputation of being hard to read by other devs.

[lispm]

since around the early 80s it was common to write large Lisp software using class-oriented or even class-based OOP (a few used also prototype-based OOP). For example Flavors for the MIT Lisp Machine was class-based: multiple-inheritance, mixins, message sending with single dispatch, ... CLOS (the Common Lisp Object System) then changed OOP such that it better fits into Lisp: generic functions with multiple dispatch, classes, multiple-inheritance, meta object protocol, ... One of the drawbacks of those systems is that the code gets assembled at runtime (though cached) and thus to read and understand code one might need support from class/function browsers.