<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> The definition and essence of "object" is not always agreed upon (encapsulation, polymorphism, state, ...), but since you're wondering about objects versus functions (purely functional), the "versus" implies a difference about an object that makes it impure, or the comparison isn't so helpful.  If an object was simply an enhanced pure function it would just be better.  So the key is that it is impure. In terms of your first question, multiple dispatch is therefore a different kind of concern (polymorphism) than the opposing difference between object and function (purity).  One can achieve polymorphism either through doing something different based on argument types (multiple dispatch) or doing something different based on the actual type of thing being operated on (sub-object type of generic object method--single dispatch). If you're doing collision detection, multiple dispatch is useful.  You can write something like "(cartesian-prod collide? objects)" which presumably passes every object paired with every other object to collide?, which depending on the object types, handles the collision appropriately (e.g. friendly fire is disabled by not detecting player missiles hitting friendly infantry). If instead you want to accelerate a vehicle, you can use the vehicle itself with its polymorphic accelerate method "(send vehicle accel)" to accelerate either a motorcycle or truck without caring what the actual subtype is.  The thing is, multiple dispatch generalizes this (multiple dispatch generalizes single dispatch clearly...).  The vehicle acceleration is also handled by a multimethod that could be called "(accel vehicle)".  It's like collision detection in that it accelerates based on the argument type--there just happens to be exactly one argument. So there's really nothing special about objects and polymorphism *gasp* as they are just a gimped way of dispatching compared to multimethods!  This brings us back to state.  An object (really a closure) is useful because it contains state (so does a plain "structure" type, so arguably I'm implying the encapsulation is useful as well).  If one is attempting to maximize the use of an object/closure, it seems they would have to take advantage of this state.  So one would use an object not so much for "extensibility" (which is inferior to the kind granted by multiple dispatch) but for mutable state. I must therefore conclude objects are for things like simulations and other real-time, especially interactive applications where things change over time.  There is also functional-reactive programming, which aims to bring "pure state" through functions that take time as an implicit parameter, and this has advantages and disadvantages (space/time leaks, sometimes getting infinite loops from difficulty reasoning about whether an update affects something "immediately" or in the next full "update cycle" (e.g. Yampa has both various switches and various comparable delayed switches to implement either)).  But ultimately, if one is choosing an object-oriented approach, they should be doing it for the mutable state (or at least encapsulation). If you just want polymorphism, multiple dispatch is flat out more powerful. </body> </html>