[PataPata-discuss] Freedom: some Smalltalk history and Python implications

[Paul D. F. <pdf...@ku...>]

kirby urner wrote:
> On 8/9/06, Arthur <ajs...@op...> wrote:
> Yeah, because after years of OO in commerce and industry, it's not
> this big elitist thing any more to have mastery of that jargon.
> Smalltalkers were impressive, in their day and age, to the great
> unwashed.  But no longer.  In and of itself, just knowing OO is not a
> mark of anything special.  Knowing a dead language implementation of
> the paradigm is also not a turn on for young people.

While you can repeat "Smalltalk is a dead language" until as many people 
believe it as "Iraq had WMD" (i.e. too many :-), but Smalltalk remains 
quite a live language, thought smaller in adoption than many others and 
often a "secret weapon".
   http://www.cincomsmalltalk.com/blog/blogComments?entry=3331578947
"Old" might be more appropriate. :-) Or maybe, "mismanaged", or "less 
popular". Unfortunately (for me :-), general consulting rates have fallen 
for it from the heydays of the mid 90s when I did it commercially, as have 
the number of new gigs. Still, VisualWorks Smalltalk as a cross-platform 
stable environment useful for mission critical software where performance 
matters has never been surpassed IMHO (although Python comes closer every 
day, but will never match it for syntax reasons IMHO).

While there are other Smalltalks,
http://wiki.cs.uiuc.edu/VisualWorks/Overview+of+different+implementations+of+Smalltalk
the flagships in the mid 1990s, mainly VisualWorks, and secondly Digitalk, 
determined much of the landscape. Hard to even remember what that 
landscape was like before so many free and open source projects became 
popular, like Python (but also CommonLisp variants, Ruby, Perl, even GCC, 
and so on).

Rumor has it VisualWorks missed its biggest chance when Sun wanted to 
license it for their set top box work, and PPD wanted too much in run-time 
fees, and so Sun turned to what became Java instead. The chance not being 
to make money from Sun, but instead to have forestalled the development of 
Java. Short-sighted greed. Sigh.

If VisualWorks had been open sourced instead of sold for a song to Cincom, 
I maintain ParcPlace/Digitalk/ObjectShare might still be a going concern 
with consulting, the way, say, the Zope Corp is. And surprise, I (and 
others) advocated that in 1999. :-) See my post here:
http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/3b3a67ab0ab756e0/6d08b70aa9f6aea1?lnk=st&q=&rnum=1&hl=en#6d08b70aa9f6aea1

One snippet of my post there back in 1999 (which also pertains to Python):

===================
"Because of these factors, I think there is much residual anger at
ObjectShare. After all, it is unpleasant to think about how the most
advanced development tool and OO language on the planet has been
mismanaged and mismarketed into relative obscurity over the past twenty
years. It has caused real suffering to programmers forced to take work
in other (painful) languages like C++ or Java or VB. Nonetheless,
Smalltalk is still in my opinion the best OO language (although Python
is easier to learn for C/C++ coders and more modular).

I've been having more success lately getting people to consider Python
for places where Smalltalk might be the better tool and price is not a
factor. The reason for this has to do with the license and availability
of source (and smaller download footprint). It also (sadly) has to do
with it looking like C (although I see no reason Python could not run on
a Smalltalk VM as a combines Smalltalk/Python product).(*) It also has
something to do with the community surrounding Python. This is a bunch
of people who are using Python every day in mission critical
applications (like web servers, data reformatting, spacecraft launch
operations, industrial facilities, and complex simulations). They make
sure it works, and have a great set of add-ons. This is all enhanced by
the fact that Python supports modules well (each with its own
namespace). Squeak has much potential, but is not used as much (at all?)
in mission critical applications. It also has a license that makes it
awkward to use in embedded systems (GPL actually is better in that
respect). VW NC has potential, but will forever be hampered by not being
a completely open solution (unlike Squeak or Python). The same thing
happened with the ST/V free release, where without an open VM, interest
in working with it has been marginal (compared to Squeak).

I think it will be difficult if not impossible for ObjectShare to
overcome this two decade legacy by conventional marketing tactics. A
name change is not sufficient. My suggesting to ObjectShare is that
since the bulk of their revenues (73%) is now from service, make
VisualWorks open source under a Python-like license.
http://www.opensource.org

Then users will be assured of indefinite support of the product. Source
code escrow as many big users have is not adequate because no one at a
client's staff can keep current with the source. ObjectShare will be in
a great position to increase its service revenue, and achieve growth and
investors like Red Hat. Right now, VW has a huge support burden by being
multi-platform (keeping engineering expertise available for all those
ports). An open source VW will remove a huge cost for ObjectShare, as
well as result in more ports to other systems, all increasing the value
of the ObjectShare brand for services and custom development. "
==================

Well, too  bad ParcPlace/Digitalk/ObjectShare did not follow that advice 
and chose to go out of business instead.
  http://wiki.cs.uiuc.edu/VisualWorks/ObjectShare
Cincom (the purchaser of the VisualWorks asset) benefited from that 
decision, as likely did their customers, though I think in balance the 
Smalltalk community as a whole suffered. As I see it, the Smalltalk 
community wanted (and still wants) an open source "VisualWorks" which was 
cross-platform and stable enough to build neat stuff on (including the in 
1999 under development "Van Gogh" system, a native widget integration 
portable across Windows, Mac OS and X Windows/UNIX). But what they got was 
an antiquated and problematically-licensed Squeak with various limitations 
and instabilities (which the Squeak community is still struggling with, 
although admirably succeeding anyway). Squeak unfortunately diverted 
attention from the truly free GNU Smalltalk which was both better 
engineered and better licensed IMHO, and which otherwise might have gone a 
lot further without Squeak and Disney stealing the limelight.

So anyway, if Smalltalk is a "wounded" language, I'd say it has little to 
do with the language or leading (proprietary) implementations, and more to 
do with mismanagement and missing the "open source" wave by the key 
players. And with several commercial versions out there, a free versions 
had a harder time getting traction. Python defined itself, and was always 
free, so in that sense, the Python community never had a diversion of 
attention the Smalltalk community did.

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).

So, for those reasons, I think it quite valid for Python people to look to 
Smalltalk and its successors (like Self) for ideas, both about technology 
and about education -- even if one accepts that a new free stand-alone 
Smalltalk (even a better Squeak, and even if pushed by an entity with deep 
pockets) will have a tough climb gaining adoption at this point in time.

And in my own case, the commercial viability of Python (i.e. because it is 
free, has a Java version, looks a lot like C, etc.) also makes it of value 
to learn and use for consulting because at the same time it is "not too 
shabby" a system. :-) And similar factors make Python a good language for 
people to teach with -- both easy to get started with and potentially a 
useful job skill.

I think the one thing that might resurrect Smalltalk in widespread 
popularity is a "killer app" which is open ended and scriptable. Croquet 
may well be that. So we'll have to see.

For me, when I went to port Squeak to the Newton (never finished for a 
variety of reasons)
http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-June/002775.html
what happened was that I discovered NewtonScript instead and became 
enamored of the Prototype-oriented NewtonScript programming I was doing to 
try to support porting a Class-oriented Squeak system (NewtonScript was an 
offspring of Self), and I have been dissatisfied with plain Smalltalk and 
classes ever since. :-) And that dissatisfaction flows over to a 
dissatisfaction with Python with classes, which PataPata has been an 
experiment to see if a prototype programming paradigm is a good idea in a 
Python setting.

Anyway, I think I've said enough on this for now, so back to programming. 
I have a (limited, quirky, experimental) Smalltalk parser and interpreter 
and related (wx) development tools I wrote in Python in 2004 lying around 
on my hard disk, and with this discussion I'm thinking of adding it to 
PataPata just for fun. It generated Pointrel triads for a backend (quirky, 
but my thing) and I'm experimenting with changing it over to spitting out 
Python code. And example of its output from today:

===========================================
|x y z|
x := 1.
y := 0.5.
z := x sin + y cos; rounded + 1.0 sin; rounded.

-------------------------------------------
x = LiteralNumber(1)
y = LiteralNumber(0.5)
_t1 = send_unary(x, "sin")
_t2 = send_unary(y, "cos")
_t3 = send_unary(y, "rounded")
_t4 = send_binary(_t1, "+", _t3)
_t5 = send_unary(LiteralNumber(1.0), "sin")
_t6 = send_unary(LiteralNumber(1.0), "rounded")
z = send_binary(_t4, "+", _t6)
return z
===========================================

Not sure if I will proceed on integrating that or not. It's not going to 
be that well performing of course, but perhaps might be useful for 
learning Smalltalk syntax on the Python platform. Might not be that bad 
under Jython if it some day compiled Smalltalk to Java source or bytecodes 
though, although there is already Bistro for that:
  http://www.ddj.com/dept/java/184405578
But Jython and Self-like hybrid on the JVM with 3D etc. might make a nice 
synergy. Jython to suck people in and Smalltalk-ish syntax and tools to do 
really big projects in. :-)

Here is something I wrote on that in 1996 (was that really ten years ago? 
my how time flies).
   "Squeak and the Babel of programming languages"
   http://www.create.ucsb.edu/squeak/9612.html#Letter94
So perhaps it might be possible to rethink that now with Python or Jython 
playing the coordinating role and delivering the core object model and VM 
interface. On the other hand, this dialog here over the past few months 
has made it clear how languages are very tied to communities (and 
libraries), so just learning the syntax or how to use it under another 
system may not be popular (except as a mind stretching exercise). Still, 
"mind stretching" is what a lot of education is about. :-)

--Paul Fernhout
(*) In 2004, L. Peter Deutsch worked on Python on VisualWorks as "pycore":
http://webpages.charter.net/allanms/2004/08/you-dont-tug-on-supermans-cape.html