Smalltalk-87 | Hacker News Reader

Smalltalk-87

wirfs-brock.com

115 pointsfniephaus17 comments

This raises an interesting question, what added value do "classes" provide over prototypes?

The way I see it is if every object (-instance) can be derived from another instance that makes programs harder to understand. Classes are invariants of behavior which all their instances obey, which makes it possible to reuse your understanding of a class to understand all its instances.

It's a bit like the certificate systems we have in the human society. When someone is a certified medical doctor we know more or less what they can do, we don't have to investigate in detail do they have the skill to be a physician.

But I'm not sure this is all there is to the benefit of classes. Is it?

Classes have several roles. They can indicate type. They allow meta programming (where a car is seen not as a car but as a bunch of stuff in the computer's memory). They allow shared state for their instances.

With objects that can directly inherit or delegate from each other you can put shared state in a parent object.

For the role of type the Self VM used things called "maps" that were not visible at the language level.

For meta programming Self introduced "mirror" objects.

Around this time, Sun Microsystems Labs was developing Self, a child of Smalltalk that ditched classes for prototypes. Work on improving the VM's performance using a JIT and generational GC helped when developing Java's VM a few years later.

Actually, Self was one of the three proposals for the Smalltlak-86 project described in this page. David Ungar (from Stanford) joined forces with Randy Smith (Xerox Parc) who had done ARK (the Alternate Reality Kit). ARK had the visual equivalent to classes but users ignored those and preferred to just copy and existing instance instead. They wondered if a whole language could be based on this.

Randy moved to England after they published a paper at OOPSLA so David put his PhD students at Stanford to try to actually implement their proposal. Since David just wanted to do research instead of working as a professor, he moved his whole team to the newly created SunLabs (in 1991, I think).

As I understand it, when Sun developed Java, they ditched Self. Some of the Self team left, and created a Smalltalk VM using the Self VM techniques called Strongtalk. Sun belatedly realised they needed a fast VM, and rehired the team which formed the basis of the HotspotVM.

That same team--led by the same guy: Lars Bak--was later hired by Google to develop v8 for Chrome and later built the VM for Dart (which has some really powerful features in static object layout and AOT support). Virtually every single seminal VM for decades was designed by this same group of people, with almost all other VMs you see just borrowing those same techniques to apply to other languages.

And then Lars Bak left, I guess desilusioned with out things turned out for Dart, and is now doing "Dart for IoT" back in Denmark.

https://www.youtube.com/watch?v=mPna6D21Eqg

It’s an era only just ending now with the emergence of Truffle/Graal.

One of my favorite JIT techniques from the era is PIC, polymorphic inline caching. A method send (virtual function call) would be statically coded to call the hottest implementation of a virtual function. The virtual function itself would check that the incoming object had the right type. If not, the fully polymorphic dispatch mechanism would kick in. Statistics would be tracked and could lead to a decision to overwrite the static call with a call to the new hot implementation. I think this was demonstrated on Strongtalk.

ParcPlace’s Smalltalk VMs (PS and HPS) were JIT VMs in the same period (if not a bit earlier).

PS and HPS did indeed implement the dynamic compilation technologies created by L Peter Deutsch and Allen Shiffman at Xerox Parc. Self 1 and 2 were even fancier JITs by Craig Chambers, but Self 3 (and 4) by Urs Hölzle implemented adaptive compilation which uses an initial simple compiler for all called code and then a second fancy compiler for the hot spots. The execution of the code from the first compiler not only measured execution to find the hot spots but also accumulated type information to make the second compiler simpler (compared to the type inference in the Self 2 compiler).

I gave a talk about this a few months ago: "Adaptive Compilation" -

video: https://www.youtube.com/watch?v=TO53xFACfuQ

pdf slides: http://www.merlintec.com/download/2019_slides_jecel_fast2v2....

open office slides: http://www.merlintec.com/download/2019_slides_jecel_fast2v2....

As the name of the Sun Java VM indicates, it is an adaptive compiler like StrongTalk and Self 3/4.

quote:

"Before I started down the path of making Java fast, I was told "you can't JIT code that will touch a static compiler" . Afterwards: all new languages start with the assumption "we can JIT this" in the implementation." - Cliff Click's LinkedIn (1997-2002 @ Sun Micro)

Were prototypes like C# or Go interfaces?

Also your username scares me a little

Prototypes as in object-based inheritance and the username is just based on finding goats to be kind of funny.