Jecel Assumpcao Jr wrote:
 > [Something snipped on clean room implementations.]
 > But to understand what happened to Smalltalk you must look at the
 > history more than at technical aspects. I don't know a good text I can
 > link to, but Eliot spent some time on this in his AoSTA talk -
 > http://video.google.com/videoplay?docid=-8988857822906068209

I wrote some on this to a Python-related list (Edusig) about two years ago 
it various posts. Some excerpts:

   "[Edu-sig] Freedom: some Smalltalk history and Python implications"
   http://mail.python.org/pipermail/edu-sig/2006-August/006871.html
"""
In the syntax case, I am continuing to point out that Smalltalk's keyword
syntax (e.g. "Point x: 10 y: 20" versus "Point(10, 20)" ) produces code
where all arguments are labeled and so it is easier to read and
understand. As I see it, that is a fact independent of licensing, object
models, breadth of libraries, size or quality of community, or engineering
reliability of the VM, and so on (areas which Python often has as an
advantage over any specific Smalltalk). ... And I am still unable to bring 
across the massive decrease in  effectiveness and immersion I feel 
programming a large system in Python  compared to Smalltalk, like were when 
an exception is raise I cannot immediately change the code and then carry on 
from the point in the program where the exception was generated, without 
either restarting the entire application. ... Now, I have repeatedly agreed 
Python has many benefits over Smalltalk.  You've mentioned some. I'll add, 
Python is more "prototypish" than  Smalltalk because it uses a dictionary 
instead of fixed slots for  variables (at least, usually) which make it easy 
to specialize instances of a class. Python as a major language had a free 
license unlike the major Smalltalk dialects (i.e. there are free Smalltalks 
but they are still  marginal to the overall Smalltalk community, Squeak 
being the closest to  an exception). Python has had its internal complexity 
managed fairly well,  compared to say, Squeak because of having namespace 
from the start. I like  indentational syntax (though not as much as 
keywords). Metaclass support  is nice. And so on.
"""

   "[Edu-sig] Freedom: some Smalltalk history and Python implications"
   http://mail.python.org/pipermail/edu-sig/2006-August/006868.html
"Anyway, I don't want to drift too far off-topic. Suffice to say, if there
is any truth to Smalltalk being a "dead" language, it has more to do with
companies mismanaging the technology, and not the technology itself.
Python has been well managed as a labor-of-love by someone who cares about
it for itself (Guido) and as a community Python could ride the free and
open source software wave without distracting conflicts with "commercial
Python vendors". Squeak tried, but was both a latecomer and not completely
free, and had some other difficulties (including for a long time a core
team with priorities other than stability or supporting industrial use)."

   "[Edu-sig] Python & Smalltalk (was Re: OLPC related: pyGTK)"
   http://mail.python.org/pipermail/edu-sig/2006-December/007476.html
"""
Smalltalk came out of an industrial research lab (Xerox PARC). The people
who invented and then built it and refined it were paid industrial
employees working in the scope of their duties on company time (though
very unusual ones, even by such R&D standards. :-) Its subsequent history
for decades involved mainly development by commercial organizations
(either as Smalltalk or also as the Macintosh OS which in some sense was a
Smalltalk-derivative, but Steve Jobs just got the window system because he
left too soon. :-).
    http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html

...

Smalltalk's demise as a major player on the commercial scene in terms of
VisualWorks and its predecessor ObjectWorks (*the* leading Smalltalk
product, and still the most comprehensive and definitive and most
cross-platform -- excepting perhaps Squeak is more cross-platform in
theory) was mostly due to greed and mismanagement IMHO by a now defunct
company (the current VisualWorks owners bought it cheaply from them).
IBM's VisualAge Smalltalk's demise, on the other hand, was mostly due to
IBM's decision to back Java (shortsighted and unfortunate I think as IBM
had the clout to push Smalltalk syntax through to the masses IMHO).
Smalltalk is still actively used by many, but is more of a niche player at
the moment (like, say, OCaml or Haskell or Common Lisp), having been
eclipsed by Java. The support community for Smalltalk was (at first)
mostly commercially oriented, and remains so to some degree. While there
were academic users, and in the past decade, especially with Squeak, the
number of people using it for academic or free or open source type
applications has grown, that has not been the bulk of the history. Even
Squeak's most recent evolution was driven by work at Apple and then at
Disney, with the Smalltalk principals reprising their roles as employees
of large industrial research and development labs, with the licensing
ambiguity that sometimes entails in navigating for-profit corporate waters
in an emerging free-and-open-source way (i.e. Alan Kay claims Disney is OK
with the Squeak changes done there being released, but there is no "peace
of mind" letter from Disney signing off on them I am aware of, or related
licensing statement in the code).

Python on the other hand, was started as a hobby by one person who was
based in an academic research lab. It was always given freely. Excepting
one bobble with licensing issues (which was corrected and involved a
not-for-profit), the licensing situation has always been pretty
straightforward from a free software perspective (and is even now GPL
compatible). For most of Guido's time with python (except the last few
years) he was affiliated with one of two non-profits. Even now his job is
at a pro-"open source" corporation which is also releasing several other
free and open source projects. The community that grew around Python,
while with many commercial users, had a very different emphasis to it.
Part of that early community spirit was also from the "Monty Python"
humorous yet playfully radical themes (although Guido has said by now he
has heard enough Monty Python jokes. :-) Python also has one core
definitive free code base as a reference standard implementation (even as
there are spinoffs like Jython).

Personally, I feel Smalltalk is the better syntax for kids to learn as
that purpose was what it was supposedly designed for (if you ignore that
most adult programmers come from Algol syntax and have trouble adapting to
the syntax initially); Smalltalk keyword: syntax is certainly the easier
syntax to use to maintain large bodies of code using powerful tools and is
easily extendable by the end user programmer for many new uses including
new control structures and iteration concepts; Smalltalk historically also
has the better development tools (in part due to the syntax) and also has
a better library architecture (e.g. Streams, Magnitude) and better VMs and
garbage collection(especially in VisualWorks, and less so in Squeak), and
also has benefited from a culture of Smalltalk all-the-way-down (as Squeak
exemplifies); Smalltalk has a powerful notion of bracketed nameless code
blocks and is a tour de force of one paradigm (objects and message passing).

However, Python has the better community (from a free and open source
perspective), better license and licensing history, and better breadth and
modularity of libraries; Python also is more easily taken up by adult
programmers who already know C or a similar Algol-style language because
of its Algol-like syntax and also because you can use familiar
text-oriented tools like emacs or vi or Scite with it (which makes it
easier for it to gain commercial acceptance as a new thing); Python code
is clear and concise and maintainable because of the decision to use
significant indentation instead of braces or brackets (like Occam); Python
also is a standard defined by a reference implementation, which is much
better than a standard defined by an ambiguous or incomplete textual
specification; Python is easier to do small projects in for people who
only know a little of the language, so in that sense it has an easier
learning curve as a system.

I feel, especially with Ruby's increasing popularity [as effectively a
Smalltalk with Algol syntax plus some other bells and whistles], that the
*themes* in Smalltalk are the future of most programming. Even Python
continues to get more Smalltalk-like, such as the "new classes" changes.
Yet, I want to write some programs now, as part of a free and secure
ecosystem of such programs. :-) Ironically, in my own case as a typical
Smalltalk programmer, because of my own history as a Smalltalk developer
working on commercial projects with commercial versions which nonetheless
included source as most Smalltalks do, I am in some ways "contaminated" by
that experience and the current overly broad reading of copyright and that
puts into potential question anything I develop which is a
Smalltalk-derivative (unless I do it very, very carefully, say by using
mostly GNU Smalltalk sources); not to say I ever would use such commercial
code, just that I might face the effectively impossible task of proving I
had not if there was any coincidental similarity at all (which is a much
smaller problem when I am working with something very different like Python).

If I perhaps oversimplify, essentially the choice right now is between
elegant syntax, uniform abstractions, and powerful tools, embodied in a
system originally designed for kids by big corporate R&D (Smalltalk)
versus practical syntax, uniform community history of freedom, and
powerful economic forces, embodied in a system originally designed for
adult programmers by an academic researcher as a hobby project which grew
beyond initial expectations (Python). :-)

Both languages along with their communities have different strengths and
weaknesses, and also both have subcultures which are in opposition to the
main (e.g. mostly commercial Smalltalk has several free versions, mostly
free Python has heavy proprietary commercial usage where no doubt such
users have large interesting and yet proprietary libraries). That the
strengths and weaknesses are so different in different areas and that one
must also assess where trends are heading when embarking on big projects
is why I am in conflict about which to use (especially for writing
educational simulations), and that is why I tried to mix the best features
of the two in the PataPata experiment -- though perhaps ended up with the
worst features of the two in some ways (Smalltalk's . :-).

Barring moving that PataPata project forward somehow, I am left with a
situation that I either have to put a lot of work into a free Smalltalk
(Squeak, GNU, A Little Smalltalk, Bistro, Sharp Smalltalk, etc.) to make
it more to my liking (e.g. mainstream widgets for Squeak, build tools for
GST or Bistro, etc.) or I have can use Python + GTK or wxWidgets or Jython
+ Swing out of the box, and just accept greater maintenance issues down
the road (e.g. debugging and modifying a running program is so easy in
Smalltalk, in Python it doesn't quite work right, even with tools I have
built to make it easier [posted to the Jython list]). While I haven't made
a big point of it, in the past, my choice of Python in the past has also
been motivated by the "contamination" issue I mentioned above as well. It
may well be the deciding factor once again, sadly -- ironic to not be able
to use and improve a wonderful thing you have experienced precisely
because you have experienced it.(*) :-(
"""

   "[Edu-sig] Python & Smalltalk"
   http://mail.python.org/pipermail/edu-sig/2006-December/007482.html
"""
On a practical reality, I fired up the latest Squeak the other day and
beyond my usual confusion with it relating to not mapping right mouse to
popup a context-determined menu, :-) within minutes I was generating
exceptions and so on as I tried to use other-than-trivial code included
with the system (e.g. running the script to change underscores to colon
equals, as well as some other things I forget off hand). I knew more than
one person who in years past inspired by an Alan Kay presentation have
tried Squeak only to encounter lots of bugs and problems with the core
tools or trying to duplicate the demos he shows. Python never has done
that to me. That's why I tend not to recommend Squeak to anybody but
either die-hard Smalltalkers or people looking specifically to stretch
their minds (which of course in theory includes kids :-). Whereas almost
all the people I recommend Python to, on a practical basis, come away
impressed and become users; Python fits into their ecosystem of tools and
existing ideas fairly easily. That makes me sad because I know Smalltalk
does not have to be that way; I know if I recommended, say, VisualWorks to
people, they would not be experiencing those basic problems (and there is
no reason Squeak's features like eToys or 3D Croquet could not run on such
a stable platform, in theory). Unfortunately VisualWorks is not "free" in
a "free as in freedom" sense the mainline Python version is.

Of course I could fix Squeak's specific problems (as I see and experience
them) with enough effort (in theory, with enough free time, which is
limited at the moment), since the source is there. But then I am left with
the licensing issues including the status of Disney contributions (which
the community is slowly moving to resolve). And then I have my own fork to
maintain, which is extra effort. I have wrestled with the Squeak community
before on those issues, and realized, like any community and mailing list,
a self-selection process has already gone on a long time there, so if you
don't like Squeak how it already is, you are probably not hanging around
on the main lists there. So there may be plenty of people who want a
different Squeak, but most of them are not easily reachable (at least via
the Squeak mailing list).

The Python community is more inclusive by comparison, in the sense that
Python as a language is much more agnostic on several points (including
GUI and tools). So there is more room for experimentation there in some
ways. Or, at least, there is a bigger potential audience of users and
collaborators for a successful experiment, like perhaps the Pyglet OpenGL
GUI system you mention. Python better supports such effort in some ways
because of its modularity and community history (which I outlined
previously). Some Squeakers have been so defensive for so long (often,
though not always, with good reason) that innovation or adopting certain
standards is harder there (witness a recent conflict about whether
keyboard input focus should follow the mouse (Squeak) or follow a mouse
click to shift focus (almost everyone else), not to say there isn't a good
argument for the Squeak way).

Plus, the copyright "contamination" issue sadly will always remain; there
is no denying I have exposed to the source of commercial Smalltalk
incidentally in the process of using them. I could never work in a
Smalltalk-rebuilding "clean room" effort. In other free software
development contexts, say, people working on GNU ClassPath as an
alternative set of libraries to Java, the biggest "no, no" is to have seen
a related vendor's source and then contribute to that project. Example:
    http://developers.slashdot.org/article.pl?sid=05/03/17/0155235
"Read the fine license, in particular the definition of Modifications in
SCSL 2.3. Sun claims copyright on any code independently implementing any
portion of the SCSL-licensed technology *if* you agree to their license.
So please don't look at their code if you intend to contribute to free
runtimes in the future. It's the same as Microsoft's Shared Source in a
different wrapping."

There is probably almost no significant Squeaker who has not been exposed
to the core code of one of VisualWorks, Smalltalk/V, Dolphin, VisualAge,
or a few other commercial Smalltalks. Of course, how well an overly broad
attempt against Squeak would stand up in court is a different issue; it
certainly also would not play well politically in terms of negative PR to
the vendor. In some ways, in the end, this single issue may mean the death
of free Smalltalks long term (barring one major vendor freeing their
version) -- the fact that Smalltalk was "open source" (taken literally)
embodied in proprietary products for so long but not "free". Which is one
reason Richard Stallman dislikes the term "open source" as it deemphasizes
the freedom aspect. :-) In essence, the history of Smalltalk is
"brilliance shackled". Since its conception, the history of Python is
"pragmatism unshackled". :-)
"""

Personally, I still feel that now that the JVM is free-as-in-freedom, a 
Squeak derivative on the JVM has the possibility of being an amazing success 
(perhaps one built step-by-step using GNU Smalltalk parts to deal with 
licensing issues). But it would take most of the community here getting 
behind it. Maybe once the relicensing is resolved, this might be more 
possible. It is the *image* itself where the licensing needs to be cleanest, 
given the VM itself is very small. That's the problem IMHO with the current 
JVM implementations I've seen (like the one based on Dan Ingall's work) -- 
they take the image for granted when that is what matters. Spoon was a great 
step in the right direction (building the system up rather than stripping it 
down), but has received not enough support.

In the meantime, I mostly use Jython on the JVM and pine for the days of 
Smalltalk when debugging was easier and classes and their methods were more 
consistently named... But I would love to use a great Smalltalk on the JVM 
that had Squeak's following. Suddenly a lot of the issues I mention above 
would go away and others -- it would be deployable as a jar or with webstart 
or as an applet, it would have a new freely licensed core, it would play 
well with other code, it would be easy to do part of a system in Smalltalk, 
it would have access to standard widgets as well as custom ones, it would 
have robust libraries for 3D graphics and sound and other things it could 
easily call on all platforms it runs on, and so on. And then gradually, 
Smalltalk could expand outwards from there... But it's just a dream and I 
have too little time as it is. Sigh.

--Paul Fernhout