> however, is that in CL generic functions are opt-in rather than the default In the default standard this might be true to some extend. We are talking about A

> however, is that in CL generic functions are opt-in rather than the default In the default standard this might be true to some extend. We are talking about ANSI Common Lisp here. Though ANSI CL has several places where CLOS comes into play. In real implementations it's not true at all. ANSI Common Lisp is a minimum standard (even though it is large) and implementations are free to extend the use of CLOS - which they do. Even though Dylan had the goal of efficient CLOS-like OOP, the Dylan spec was not very detailed about that - there were individual implementations. But how fast were they really? Difficult to say: Apple Dylan was only published as a technology demo. Harlequin Dylan was short-lived. Julia OTOH is a language and its implementation. It brings some good ideas how to make OOP performing better. If you compare Julia with CL implementations like CCL, LispWorks, SBCL or Allegro CL - you will find that CLOS is widely used there. Much more widely than the ANSI CL standard defines. For example the base LispWorks on my Mac implements 1600 classes. It has 32000 functions of which 5182 are generic functions - and 10000+ methods. So claiming that Common Lisp implementations are mostly not extensible via CLOS is not giving the whole picture. I/O Streams are not CLOS based. In most/many implementations they are. There are one or two quasi-standards for that: Gray streams is one. Conditions might be CLOS based. In most implementations they are. CLOS is somewhat CLOS based. In most implementations it is fully CLOS-based with a meta-object Protocol. There is a minimum ANSI CL, which makes it possible that individual implementations are mostly CLOS based. Then there is a larger Common Lisp, which assumes CLOS-based error handling, streams, CLOS itself, CLOS-based networking, CLOS based software management (ASDF). Dylan and CLOS had different goals. Dylan was developed for application development where delivery and performance was focus. CLOS focus was on flexibility, expressiveness, extensibility, meta-object protocols, etc etc.. Performance was a topic in two ways: First: it should be possible to write large extensible libraries and applications in CLOS (like the typical GUI or networking code). Second: for applications that use CLOS for more performance critical things (like a CAD system with zillions of CLOS objects describing a 3D model) it was assumed that individual implementations provide additional features (like sealing, efficient slot access, etc.). Writing high-performance numeric code (or similar) in a CLOS based way was not really thought of. It's definitely useful to extend higher-performance implementations with an optimizing compiler (like SBCL, ACL, LispWorks, ...) so that more performance critical code can be written in CLOS. But keep in mind that not all CL implementations have this goal of highest OOP performance. Many have other goals and already lack the attempt to provide an SSC. SSC = sufficiently smart compiler