Is Smalltalk Complete

As a newbie to Smalltalk, I was quite surprised to read in an article by DanIngalls in the Smalltalk issue of Byte (Aug. 1981, p. 286 ff.) the following words:

: As might be expected, work remains to be done on Smalltalk. [...] For example, the Smalltalk-80 system falls short in its factoring because it supports only hierarchical inheritance. Future Smalltalk systems will generalize this model to arbitrary (multiple) inheritance. Also, message protocols have not been formalized. The organization provides for protocols, but it is currently only a matter of style for protocols to be consistent from one class to another. This can be remedied easily by providing proper protocol objects that can be consistently shared. This will then allow formal typing of variables by protocol without losing the advantages of polymorphism. [...]

Question: Imagine you were given the task of defining "Smalltalk-99". Which, if any, features would you add to Smalltalk?

-- FalkBruegmann

Name spaces. And that's low priority. The other big things it needs aren't language-related, they're things like 20th-century browsers, built-in refactoring browsers, decent code management. In short, stuff you can borrow or buy already. I'd specifically not add multiple inheritance, because I believe it adds too much complexity and is an irresistible temptation to idiots like me to mess with it. I don't much care about protocols or formal typing. Of course, I've used it only for small projects like C3, with only a couple of thousand classes ... -- RonJeffries

After Dan Ingalls wrote that, he implemented multiple inheritance for Smalltalk, and described it in a POPL paper with Alan Borning. Lots of other people have implemented multiple inheritance for Smalltalk. It is widely regarded as not needed for Smalltalk, and when Dan Ingalls talks about what he would like to add to Smalltalk, he still talks about a protocol-oriented type system, but does not mention multiple inheritance.

I agree with RonJeffries that name spaces are the one language feature most needed. I would give it higher priority than Ron. -- RalphJohnson

What has been the approach so far in adding types to Smalltalk? Have the schemes tried to emulate the type-is-class approach of other languages? Where can one find out about TypedSmalltalk?

Assertions/DesignByContract? MultipleDispatch?

Smalltalk may be in a local maxima. Other languages have features I like very much, but I wouldn't want to add those to Smalltalk because they would break it. -- DaveHarris

Adding (safe) assertions to Smalltalk is much harder than it sounds. Consider what happens in C when you do:

 assert(i++);

Now if you compile with -DNDEBUG, i won't be incremented by the assertion. Just imagine if you added assertions or dbc to Smalltalk. An expression evaluation could call a method that changes the state of the thing being tested. (In other words, you can introduce HeisenBugs.) To add assertions with no fear of HeisenBugs, you need to introduce Eiffel-style queries. In Smalltalk, that means adding a new programming construct - a method that can't change the state of the system. Given the fact that "everything is an object" this new construct will have to fit into the existing hierarchy of classes that form the core of the system.

No - Eiffel itself doesn't have Eiffel-style queries. There is nothing to stop an Eiffel query from changing the state of the system other than programmer self-discipline. (This is because of things like caches, which change the physical state but not the logical state, and because the compiler can't tell the difference between physical and logical changes.) If Eiffel doesn't have a special construct, Smalltalk doesn't need one either.

Another way of putting it is that we already use Eiffel-style queries all the time in Smalltalk. Consider methods like #collect:, #select: etc. Much of the collection protocol is side-effect-free, and safe to use in assertions.

Incidentally, C++ does have a construct, namely const as applied to methods. It would make sense for a C++ assertion mechanism only to allow calls to const functions. Of course, you could still get HeisenBugs by using mutable or const_cast<> or other workarounds. (The difference between logical and physical state is the reason these workarounds were added to C++.) -- DaveHarris

It would be nice if Smalltalk code were defined in text files that lived in the filesystem instead of in a memory image that is indecipherable! Source code management would then be a non-issue - just use CVS (good for most) or new-breed (opencm, subversion, arch, vesta, etc). -- StevenShaw

The code is stored in text files, the sources and the change file contain it, the image isn't for the code, it's for the instances created from the code, the object memory.

The SmalltalkLanguage doesn't need MultipleInheritanceInSmalltalk because Smalltalk has loose typing. To achieve polymorphic behavior in C++ you must call virtual functions by pointer or reference from a common base class. This forces you to use lots of inheritance and abstract/base/interface classes. In Smalltalk, any two classes that respond appropriately to the some common set of message signatures are polymorphic -- you can substitute one for the other. -- JeffGrigg (...still a Smalltalk beginner, after all these years.)

A nice model for composing/sharing behaviour across classes is Traits http://www.iam.unibe.ch/~scg/Research/Traits/ available in Sqeak dev images from at least 3.10

-- PeterGoodall

Interfaces - like in Java? "Adding Dynamic Interfaces to Smalltalk" JOT May-June 2002

Interfaces are needed in a statically typed system only to gain PolyMorphism, Smalltalk already has polymorphism at the method level by default. Interfaces have no place in a dynamic type system, hell, interfaces are trying to simulate a dynamic type system in the first place.

Is Smalltalk over-full? What would you delete?

Top of my list would be classes. Move to a prototype-based system like Self.

Also, be sure not to miss the LanguagePissingMatch. ;->