Ian Bicking: the old part of his blog


Hmm. Smalltalks OO is quite different from most all other OO implementations. The only systems that are a bit like Smalltalk OO are those implemented in Scheme or other Lisps. So it's not like much other implementations :-)

But OO itself is a rather weird concept, allmost every class of languages has it's own idea what it is. Most Algol derived languages see OO as structures with code. Most scripting languages somehow have a objects/classes as hashes (or something similar) idea. That's easy to see why it happened: hashes are quite handy when modelling OO in those class of languages.

Scheme usually uses different approaches: Objects are much more encapsulated, often they are implemented as a bunch of defines (the methods) over some closure (the state). So someone coming from Scheme background will see much more the control flow aspect of objects than the data representation aspect! That's where this special criticism might come from: for someone coming from a defines-over-closures-over-instance-variables aspect, this hashes/dicts-as-objects must look really ugly.

I used to upset Common Lisp programmers by giving references from Common Lisp idioms to Perl idioms and showing where similar concepts existed. Most times they didn't get over the step to accept that Perls object _implementation_ are hashes, just because that was a handy datatype to use. Common Lisp people are _really_ weird with respect to OO, as their CLOS is much more than what people usually see in OO: they have structure implementations, that's standard. But methods in Common Lisp are not bound to one class, they are specified on all parameters. So you actually don't have the view on objects as code+data - you have objects as data and generic functions as code, where the compiler (and sometimes the runtime) does the magic to automatically find the most specific method for a generic function. This is very nice if you think in functional programming terms. Actually I would prefer that every day over Pythons rather crude object system. Only problem is that I would need all those nice extension modules and especially the nice and terse syntax of Python. I can't stand the bloated identifiers common lisp uses :-)

And let's don't even start to discuss Haskell Type Classes ...

There is a very good book on all this: "Theoretical aspects of Object-Oriented Programming", MIT Press, Gunter and Mitchell Editors. Highly recommended if you want to see what OO actually can be. Other stuff to study would be the AI stuff about frame languages like loops or flavors - those were predecessors to the Common Lisp CLOS system and heavily propagated the objects-as-data-chunks-with-slots with seperate function binding ideas.

It's rather bad that nowadays primitive object oriented systems like Java or C++ dominate the thinking of language designers, as that largely hinders language design. Ok, there is allways Ruby, that seems to be written by a Smalltalk+Scheme-Fan.
Comment on Hash table accused of impersonating OO
by Georg Bauer