Smalltalk critics

Smalltalk is pure object-oriented and there are very very few people which decided to go back from Smalltalk to a mainstream language. But Smalltalk lost market share continuously since today. That may change because the attention Smalltalk got recently by the event that the "Inventor" of Smalltalk Alan Kay recently won the Nobel price of Computing science the Turing award. So hey - why Java and now C# is so much popular than Smalltalk ? One explanation which is often given is bad marketing - but maybe there are other reasons and maybe these are even technical ?

Smalltalk has a problem - b.t.w it is the same problem why Java never succeeded to enter the Windows Desktop market - it is the Operating-System-Integration - For some technical reasons it is difficult for Smalltalk.Implementations to be callbacked by the Operating-System Services recursivley - Of course it is not really difficult it is merely somewhat "tricky". But in the days the major Smalltalks were created maybe Smalltalk "creators" where somewhat ignorant about OS'es and they decided to emulate the "few" features which are present these early days and used only basic features ( e.g. creating a desktop window ) inside the window they did everything themthelves. Also the approach to use an underlying GUI layer which didn't require recursive callback was taken. And that was IMHO a fundamental wrong decision.

Today Windows client services can't be emulated - they are simply too complex and so Smalltalk lost the connectivity to the current art of desktop OS.

There was Smalltalk/V ( later Visual-Smalltalk ) which was designed to handle these recursive callback to a certain extend. Today only Dolphin is capable of doing that ( Smalltalk-MT is also nicley Windows-integrated but didn't require a RCB mechanismn because it elimiates the Virtual Machine by emitting Assembly code - introducing other limitations )

The other problem is the missing integration of Native thread support - Smalltalk has its own Process implementation.

But I delved too deep into the recursive Callback ( RCB) issue ( of course my own Smalltalk-VM can do RCB ). Now I come to a much much more problematic issue - which is more a problem of todays framework architecture found in most Smalltalk's - the mix of Runtime and Design-Time code...

It is much more easy to write code in Smalltalk which uses reflection than in other languages - In fact there is no real border between sending the message allSubclasses and new to Array - the first is regarded as a reflective message. Using reflection at Runtime is very dangerous it is IMHO bad programming style.

Types of reflection:

aNumber class == Float ifTrue: [ ,,, ]

anObject isClass ifTrue: [ ... ]

' xyz' isPrefxOf: aMessage selector ifTrue: [ ]

There is a technique to add attributes to existing classes without the need of recompiling the class - the use of Properties

so you will see

 self propertyAt: #someAttribute

And there is a known technique to allow to "add behavior" ( extend methods ) without changing these methods - so called events

self triggerEvent: #changed: with someObject

Finally Object mutation

anObject become: anOtherObject

can be seen in a lot of places ( Stream, Collection hierarchy ). Design can be always changed to avoid become:

All these techniques spoils the program ( by making it imperformant ; making debugging difficult and make it unstable by making side effects more probable to occure )

I subsume these "technics" as infiltring Runtime code with Design-time code and you will not be surprised that my own Smalltalk doesn't use events / DNU / properties / isType or == SomeClass in any place where code is ready. Of course all these Meta-Programming is very usefull at Design-Time but should be avoided at Run-Time.

One can find mixing Design-Time and Run-Time even to my surprise in the newest Software-Framework namely Microsoft .NET.