Smalltalk as a technology, philosophy and community has always evolved - to the future (to what else?). Claiming that one leaves a community in emphasizing that one wants to move to the future silently implies that that community didn't move to the future, i. e. stays as is. I don't think that this is a correct observation with regards to Smalltalk.


The problem with the Smalltalk community is that it holds itself back.
For example there are no Smalltalks with a decent namespace implementation (although there was Dave Simmons' S# for a while). The single survivor seems to be NewSpeak which clearly chose to 'divorce' itself from Smalltalk 'proper'.

I recall Pharo was created because Squeak did not cater to the professional market and Pharo would conquer the FLOSS portion of that niche. Seeing that Pharo did not get host window support, nor decent namespaces it seems fair to say that the community did not get its act together -- and if we stretch it we might say that the community held Pharo back.

What I see in the Smalltalk community is a giant circle-jerk (direct object manipulationz! refactoringz! TDDz! xUnitz! we are greatz!) with people wallowing in past greatness.

The reality (a 'correct' observation as per the above?) is that people are experimenting with new(ish) software development methodologies in *other* environments nowadays.
The example-du-jour is of course Bret Victor who proposes an IDE where we can flatten abstractions (like time) into 2d so our brains can readily grasp and predict consequences of code alterations. Seeing that Apple xCode IDE adopts this paradigm (with Swift) before the Smalltalk IDE did is telling.

Seeing that Pharo and Squeak are still producing browser framework after browser framework and -oh yeah- let's reify packages as objects and we still need a JIT, I observe a lot of ant-like activity at ground level and very little 'giants' activity at the 'how to encode my abstractions' level. (Another example: there still is no accepted paradigm in the Smalltalk community that instructs us how to document implementation requirements and decisions -- go figure).
So the programmer's discourse with the Smalltalk machine has not changed many times in the past, perhaps just once during the introduction of refactorings and TDD at roughly the same time.


What the Smalltalk community seems to miss is that 'Smalltalk 2.0 is dead, long live Smalltalk 3.0' feeling.

Perhaps it behooves ESUG to create a session where the community *finally* buries Smalltalk 1.0 and perhaps also pick the date where we sunset Smalltalk 2.0.




Go Doru,
  Pharo desperately wants to escape Smalltalk 1.0 but the community won't let you.




Reinout
-