>>3
It's not like CLOS even means you have to use the so called `OO design methodology', or that you have to define classes ( which are just glorified structures with multiple inheritance ), CLOS is mainly about generic methods (with multiple dispatch), so in simple terms, you can write specialized functions on all kinds of data types, which have the same name, and when you call that function, CLOS would simply call the right function for you. There's at least a couple generic functions implemented that way in CL, so you're still using CLOS, even without knowing, but of course you could implement all of CLOS functionality only using normal functions and macros (check AMOP or ACL for examples), and someone can implement the popular OO(message passing) model, in like 1 page of code in CL, using only normal functions and macros.
In a more general sense, CL could be considered OO (not in the Java/Sepples sense) as each object has its own identity and can be operated on freely, take a look at symbols (with or without plists) for example.
P.S.: I incorrectly used to avoid CLOS because of misconceptions related to what's considered OO these days, but it was a mistake, as CLOS isn't nearly what they call OO in Java or Sepples( but if you really want that, it can implement such kinds of OO, however that is backwards and shouldn't really be done), instead CLOS is a more generic way to write extensible code. If you find yourself
typecase'ing around too much, or funcall'ing object properties, you should probably use CLOS.