Lambda the Ultimate

Prothon died a while back. It started when the author first decided to change it to work on .net, then changed the name to PyCS, then changed it again to Spry. Then the author had a crisis of faith and development pretty much ended.

Slate Smalltalk is still maturing, lacking an IDE, but we have recently added things like E-style concurrency.

Slate's implementation is very compact, and in fact the only reason I can surmise that you think prototype languages use more memory is that you're not aware of what Self does with memory: write lots of binary code and stuff them in polymorphic inline caches at runtime. The truth is that Self-style prototype-based languages use roughly the same amount of memory as class-based systems such as Smalltalk, since common criteria (like slot information or method-sets) between alike objects are stored in maps, which are equivalent to classes but not distinguished per se.

The one disadvantage of Self-style OOP is that slot-based delegation is a really bad idea, because there is no way to distinguish between methods on object X meant for object X, and those meant not for X but for those inheriting from it. Basically, it conflates the meta-level (behavioral composition) with the first-order level (slots and messaging). Alan Kay, the inventor of Smalltalk, noted this himself as the only serious objection he had to Self's direction. To avoid the problems inherent in this and the usual MI-graph issues, Slate has evolved to emulate the Squeak-style traits system and also to mark object-meta transitions in inheritance paths.

Slate also has the most powerful libraries available for taking advantage of the prototype paradigm - we've extended Smalltalk-80, Strongtalk, Dylan, Common Lisp, and other libraries and integrated them into one whole. Also, we use a design pattern of object creation messages which are always sent to existing objects and always refer to those argument objects as the template, so special implementation changes and specializations carry forward seamlessly. Also, as a result, as few hardcoded canonical references to other features as possible are in the actual code. This means Slate code is extremely loosely-coupled which allows for a lot of design freedom.

We also have language extensions via macros and other means that make Slate extremely powerful compared to most OOP languages. For example, we have function-composition operators, currying, and asynchronous message-passing with promises (unreleased just yet) as basic language extensions. However, despite the presence of a macro feature, our code is heavily oriented towards code blocks and multi-method dispatch, since we heavily favor genericity and flexibility in the code; macros are only used for syntax/semantic extensions per se.

I created my first prototype based language, Glyphic Script, in 1992.

About that time, we took a trip to Sun Labs to meet with the Self team in an exchange of show-and-tells. Dave Ungar complained that the demo of Self we were getting was too slow - turned out the demo machine had only 32 Meg of RAM, and we should really go to a 64 Meg machine to see it fly. Remember that at this time, even having 8 Meg in a desktop computer was seen extravagant!

In contrast, we fired up Glyphic Script and the Codeworks environment in a 2 Meg partition (this was old Mac OS!) and it ran beautifully, though probably 50x slower than Self. Glyphic Script could be made to run in even as little as 1/2 Meg: It was designed for the state-of-the-art portable computer: The Eo, running PenPoint and if I recall you couldn't count on there being even 2 Meg in the unit.

As for slot based delegation, in both Glyphic Script, and my newer prototype based language, Wheat, we've handled the issue of "is it for just me", or "for me and my inheritees" or "just my inheritees" by adding a scope concept to slot. Our experience has shown this to be sufficient.