Inconsistencies in smalltalk

Question

I'm a new comer to Smalltalk, and learned it in Squeak. But I find many things confusing in Smalltalk. In Squeak, MetaClass and MetaClass class are each other's class mutually. If I want to create the object MetaClass I should send a message new to its class which is MetaClass class. But it must have already existed as an object in the first place to accept the message. So I must create the object MetaClass class first, which can only be done by sending a message new to the object MetaClass which has not been created yet. So it is a chicken-or-the-egg problem.

Of course I can create the objects in Squeak now, because the MetaClass and MetaClass class objects have already been created auto-magically when Squeak is opened. But I don't know how. Maybe they are created somehow rather by sending messages. But then it contradicts Smalltalk's spirits: everything happens by sending messages except a few points (variable declaration, assignments, returns and primitives).

Is there something wrong with the above reasoning? Thanks in advance.

Answer 1

Your question is twofold, lets answer them separately.

How do mutual dependent classes get created?

You are right, Metaclass and Metaclass class are a singularity in the parallel hierarchy of the Smalltalk classes and metaclasses. How are they created?

That depends on the Smalltalk you are using. For GNU Smalltalk I am unsure, but for the descendants of the original Smalltalk-80 (VisualWorks, VA aka VisualAge, SqueakPharo) the are created in a Bootstrap process that creates an initial image.

However, at least for Squeak, this bootstrap happened at least 15 years ago, if not more. Metaclass and its class may even be as old as 30 years.

Long story short, both classes are created outside the typical image processing and linked together manually.

But if the objects are years old, that leads to the question

What happens at Smalltalk’s startup?

Contrary to languages like Ruby or Python, which are object-oriented, too, Smalltalk does not need to create a basic object environment with things like Object on every startup. Why?

When Smalltalk saves and shuts down, it basically takes a snapshot of all its object and saves those live object to a file. When it starts up again, it just has to read the objects from the snapshot and “revive” them.

Hence, for Metaclass and Metaclass class, both objects are read from the snapshot and revived, and from this point on, they are fully functional; they don’t need to be manually created anymore.

Answer 2

The 'automagically created' process actually is called bootstrapping. This is how the chicken-and-egg problem gets solved. Once the system is bootstrapped, all the rest can be expressed in terms of the system itself. So, there is no contradiction with Smalltalk's philosophy that everything happens by sending messages because it only becomes a Smalltalk system once it's bootstrapped.

Answer 3

Metaclass class class = Metaclass is a classical academic example of strange loop. But if you inquire a bit, you could find many others in Smalltalk.

• Object superclass is nil which is an instance of UndefinedObject which is a subclass of Object (longer chain via ProtoObject in Squeak Object superclass superclass class superclass = Object)
• The methods of MethodDictionary are stored in an instance of MethodDictionary (MethodDictionary methodDictionary class = MethodDictionary).
• The name of Symbol is an instance of Symbol (works with ByteSymbol in Squeak ByteSymbol name class = ByteSymbol).
• The subclasses of ArrayedCollection are stored in an instance of Array which is a subclass of ArrayedCollection (Array superclass subclasses class = Array).
• Smalltalk is a SystemDictionary which points to Smalltalk via the #Smalltalk key (This is less direct in Squeak, (Smalltalk globals at: #Smalltalk) = Smalltalk).

I let you continue the list by yourself.

Whatever the implementation, the ultimate question is whether or not you can devise a self-describing system like Smalltalk without these strange loops, and you may glimpse a not so positive answer if you follow the sublinks of http://en.wikipedia.org/wiki/Kurt_G%C3%B6del#The_Incompleteness_Theorem

Related to the the bootstrap problem encountered with such system, an efficient way is to clone oneself to change oneself, and this is particularly true in Smalltalk image when you want to change base classes that you are using for changing / describing classes.
Hence my previous and concise answer which was deleted by applying the letter of the rules (https://stackoverflow.com/help/deleted-answers) more than the spirit in my opinion:

And here is how it was resolved: http://en.wikipedia.org/wiki/Drawing_Hands

Last point, I would have preferred to read, Incredible Consistency of Smalltalk, but I'm definitely biased.