Если автор не бредит, то ему скорее нужен не Smalltalk, а Self



Traditional class-based OO languages are based on a deep-rooted duality:

Classes define the basic qualities and behaviours of objects.
Object instances are particular manifestations of a class.
For example, suppose objects of the Vehicle class have a name and the ability to perform various actions, such as drive to work and deliver construction materials. Porsche 911 is a particular object (instance) of the class Vehicle, with the name "Porsche 911". In theory one can then send a message to Porsche 911, telling it to deliver construction materials.

This example shows one of the problems with this approach: Porsches are not able to carry and deliver construction materials (in any meaningful sense), but this is a capability that Vehicles are modelled to have. One way to create a more useful model is use subclassing to create specializations of Vehicle; for example Sports Car and Flatbed Truck. Only objects of the class Flatbed Truck need provide a mechanism to deliver construction materials; sports cars, which are ill suited to that sort of work, need only drive fast!

This issue is one of the motivating factors behind prototypes. Unless one can predict with certainty what qualities a set of objects and classes will have in the distant future, one cannot design a class hierarchy properly. All too often the program would eventually need added behaviours, and sections of the system would need to be re-designed (or refactored) to break out the objects in a different way.[citation needed] Experience with early OO languages like Smalltalk showed that this sort of issue came up again and again. Systems would tend to grow to a point and then become very rigid, as the basic classes deep below the programmer's code grew to be simply "wrong". Without some way to easily change the original class, serious problems could arise.[citation needed]

Dynamic languages such as Smalltalk allowed for this sort of change via well-known methods in the classes; by changing the class, the objects based on it would change their behaviour. But in other languages like C++ no such ability exists, and making such changes can actually break other code, a problem known as the fragile base class problem. In general, such changes had to be done very carefully, as other objects based on the same class might be expecting this "wrong" behavior: "wrong" is often dependent on the context.

In Self, and other prototype-based languages, the duality between classes and object instances is eliminated.

Instead of having an "instance" of an object that is based on some "class", in Self one makes a copy of an existing object, and changes it. So Porsche 911 would be created by making a copy of an existing "Vehicle" object, and then adding the drive very fast method. Basic objects that are used primarily to make copies are known as prototypes. This technique is claimed to greatly simplify dynamism. If an existing object (or set of objects) proves to be an inadequate model, a programmer may simply create a modified object with the correct behavior, and use that instead. Code which uses the existing objects is not changed.

Компашку которая разрабатывала Self промежду прочим купил примерно в 2003 году Sun. Чем сильно улучшил свой JIT.

Как мимнимум вы можете получить версию от SUN 2004 года

http://research.sun.com/spotlight/2004-05-24.self.html