Design Principles Behind Smalltalk, Revisited

Paul D. Fernhout pdfernhout at kurtz-fernhout.com
Thu Dec 28 13:30:38 UTC 2006


Jimmie-

I'll agree options are good; on the other hand, there is only so much time 
for exploring them (especially when you have kids, though older ones can 
do some of the exploring for you, I guess. :-)

You're not the first person to recommend Lua to me, so I've installed a 
later version, and will look some more at it. In the past I have evaluated 
Lua mainly from the documentation from the point of view of being a VM to 
put other Squeak-like work on back when I was also looking at Parrot (and 
the JVM comes out higher for me as a value proposition, now that Sun has 
announced its move to GPL for Java code).

Just out of musing, lets us consider this issue of picking what system to 
build on abstractly out of all the known options.

There is a such a thing as a language or programming system  being 
"entrenched" in a company (or even in a programmer's toolbox in some 
sense). (Entrenched literally meaning "dug in" or "in a trench").
   http://wordnet.princeton.edu/perl/webwn?s=entrenched

New things rarely start out "entrenched" -- unless, in a few special cases 
they have, say, lots of sales and marketing money behind them (Britney 
Spears? :-) or Java marketed by Sun and IBM). Or they somehow spin off 
from another already entrenched group (say, Microsoft taking the torch 
from IBM when IBM carelessly picked an OS for its internally unimportant 
IBM PC, or Java gaining ground being linked with Netscape browsers, or 
Java syntax looking a lot like C++). So, as an unusual case, Java started 
out "entrenched" in several ways, and only got more so, as it was actually 
used over the past decade (very painfully at first). That's one reason 
Smalltalk did not have much of a chance against Java in 1996 -- Java was 
one of those rare systems that was entrenched multiple ways from the 
start, and Smalltalk had missed tis chance to stop Java (and the major 
Smalltalk player, ParcPlace etc., actually embraced Java for a time and 
tried to reposition itself as a Java tools company!)

Now, most systems do not go from nonexistent to entrenched overnight. Even 
Java internally had various steps internally from VisualWorks/ST-80 
(runtime fees too high! :-) to Green to Oak Java. Yes, I say Smalltalk, 
because from what rumors I hear, Sun did want to use Smalltalk for the set 
top box first, but was rebuffed out of greed. You see there that a 
somewhat-entrenched Smalltalk had a chance to nip Java in the bud but a 
failure of management vision coupled with short-term commercial greed got 
in the way IMHO. And all Smalltalkers have paid the price -- both for that 
failure of vision but also for our own personal decisions to couple our 
fortunes (money wise and aesthetics wise) to a commercial vendor. That is 
the main reason why the personal copy I purchased of VisualWorks + ENVY 
Client + ENVY Server (at almost $10000 all together) sits gathering dust 
on a shelf and instead I use Python and explore Squeak or other free 
Smalltalks; I just don't want to be on that path anymore -- entrusting my 
fate mainly to someone else's greed; it has brought me and many other 
Smalltalkers years of pain of having to work in other languages and 
related environments like Java (or, even, to a lesser extent, Python, when 
you know what an programming environment could be like). Maintaining large 
complex business apps in Smalltalk was often fun; maintaining them in Java 
is mostly work. (Python is somewhere in the middle.)

The usual progression to becoming "entrenched" is probably somewhat like this:
* ignored.
* experimental (you downloaded it and are playing with it)
* first useful task (you actually did something with it, probably where 
you don't need to maintain the code, like reformatting a text file).
* multiple minor useful tasks.
* first major task (you did something very important or profitable with it).
* multiple major tasks that need to be supported.
By the last phase, the tool has become "entrenched".

I think an important "design principle" should be that a system should 
easily move from one stage here to the next. :-) Because, all other things 
being equal, ultimately, entrenched systems are easier to use. :-)

Things can also become "un-entrenched" when the applications they support 
get replaced or diminish in importance. VisualWorks was entrenched in many 
large companies in the early 1990s; it is less so now, even as it remains 
a niche.

While people often talk about "the industry", in reality the programming 
industry is a lot like a big city, with lots of niches and variety. Sure 
there is a big Java convenience store on every corner, but that does not 
mean there is not a nice Smalltalk boutique on 5th Avenue doing a brisk 
business in dynamic objects. So, being entrenched is often relative to the 
person or company under consideration (if you live on "5th Avenue" in this 
hypothetical programming city, Smalltalk is then a lot more convenient 
than Java).

For Lua or Squeak to make it all the way to entrenched for me personally, 
it needs to make it through all those phases. Python has already done that 
for me, and so is "entrenched" for me. However, in the past, VisualWorks 
was entrenched, just like Delphi, C, and some other programming systems, 
which have all fallen out of daily use with me for one reason or another. 
Squeak itself was even almost entrenched for me about six years ago (but 
then lost out to Python as I found I could convince people in industry to 
try Python, whereas most people would not even look at Squeak, both for 
licensing reasons and also for syntax issues).

To progress from ignored to experimental, through useful, and then to 
entrenched, is not an easy thing. Tools either need to be so easy to 
install and use (Python, the programming language?) in terms of low 
hurdles at each stage that you can make it over one hurdle to the next 
easily, or they need to be so powerful or fun to use (Squeak, the idea 
processor to boost creativity?) that people are motivated to jump higher 
hurdles. Ideally, things are both powerful and easy to install, use, 
deploy, and support; unfortunately Squeak doesn't fall into this category 
for the masses (being powerful but quirky and unstable and incomplete and 
still problematically licensed).

For me, while I'll still consider learning other systems, Python (mostly 
Jython these days) is the entrenched tool with an Algol syntax. Lua just 
has no hope I can see of displacing Python for me anytime soon (barring 
external forces or some new need I come up with). Sure, I just downloaded 
the latest version and will experiment with it (so, it has made it to the 
first phase beyond "ignored"), but it has a long road to go. And it is not 
clear to me that it offers a big enough value proposition to move forward 
for me. Granted, if say "COBOL" or "C++" was what was entrenched for me, 
then Lua might have a level playing field with Python and Ruby and 
Smalltalk (ignoring user community size).

This is not a slur on the value of Lua. This is just to say that to 
compete head-to-head against an entrenched alternative (say like 
Python/Jython vs. Java in many businesses today) a programming language 
has to offer not just 10% more value (1.1X), but more like 300% more value 
(3X). Python (as Jython) does offer that 300% over Java for most Java 
developers who will use it. Lua does not offer 300% more value to me than 
Python (at least as far as I can see right now; time will tell). No 
language is perfect; but some meet current needs better than others; as 
needs change, so does the landscape of sensible possibilities.

Squeak's big value proposition is that it is four things:
* an effective self-documenting programming language,
* a set of cross-platform libraries and runtimes,
* a complete IDE, including a fantastic debugger and source code control,
* an idea processor for enhancing creativity (its ultimate purpose).

And that is why I find Python or for that matter, probably Lua, 
unsatisfying in contrast. Python has the first being a language that has 
been called "executable pseudo code", for sure, but the other three ares 
are where it starts to falter and then fall short. For example, it's 
difficult to alter a running Python program, and almost impossible to 
restart a function, which is easy to do in Squeak and a big part of 
Smalltalk productivity -- especially in large programs. I had no problem 
maintaining huge things in VisualWorlks+ENVY or participating in a 
development process involving lots of people (many of them relatively 
inexperienced), but even a mid-sized Python program developed by one or 
two experienced people begins to get a big of a bear to maintain and 
refactor and incrementally improve (not impossible, just harder than I 
know a similar application in Smalltalk would be).

However, issues like familiarity, stability, completeness, modularity, and 
licensing have trumped those other Squeak advantages (for me) which is why 
I usually turn to Python. Most projects I do are not that huge anyway, or 
can be refactored into smaller parts. So, to be a better value 
proposition, Squeak (or Lua :-) either has to become an even more 
compelling "idea processor" (e.g. even beyond OpenAugment), or gain those 
other advantages Python has, or really *now* needs to do both, since for 
me Python is already "entrenched" and Squeak needs to now be 300% better 
to compete against it. Ten years ago, Squeak could have been as good as 
Python; now it needs to be vastly superior. "Just as good" is not "good 
enough" when the alternative is already "entrenched". Granted, however, 
some specific issues about Squeak (licensing, GUI feel, internal 
complexity) have kept me from giving it a lot of chance to grown on me as 
an idea processor.

Now, I'm only bothering to write this not to point out Squeak-ish 
competitive disadvantages by themselves, but because I'm willing to put a 
little work into those directions -- since I still believe in a lot of the 
Smalltalk ideals (and remember its accomplishments when I used it) and 
still prefer keyword syntax (though I still have to trade that off against 
getting other stuff done now with Python). Perhaps a Squeak 1.1 under the 
Apache license on the JVM the same way Dan did a Squeak 2.2.
   http://weather-dimensions.com/Dan/ForwardToThePast.jnlp
might be a start. Then I could leverage Java's ability to provide some of 
those other things (stability -- after ten years of Sun working on it, 
ease of installability -- one click web start, and so on). Essentially, an 
"idea processor" for the JVM? Unfortunately, Squeak 1.1. reaches so far 
back (and I remember the early problems with 1.13) that there is a lot of 
work to bring 1.1 back up to something really usable. And even then that 
system might be in the same position Lua is in now, great, but not 
"entrenched". :-)

And, as for your question on license, what matters to me in that regard is 
being able to put GPL'd applications on top of the platform.  (I don't 
care that much about the licensing of the platform otherwise, as long as 
it is "free"). If that is possible with an Apache version of Squeak, 
that's fine. If it is not, then that is a big difficulty. I like the GPL 
as a constitution for defining cooperation on an application and have used 
it before with success to that end. About half the free software out there 
is under the GPL, another big chunk is under a GPL compatible license 
(X/MIT or BSD), and then a smaller part is GPL-incompatible (Apache, etc.).
   http://www.fsf.org/licensing/licenses/
And it's a sad situation, as the FSF themselves writes about the Apache 
2.0 license: "This is a free software license but it is incompatible with 
the GPL. The Apache Software License is incompatible with the GPL because 
it has a specific requirement that is not in the GPL: it has certain 
patent termination cases that the GPL does not require. (We don't think 
those patent termination cases are inherently a bad idea, but nonetheless 
they are incompatible with the GNU GPL.)"
Here is Apache's take on this:
   http://www.apache.org/licenses/GPL-compatibility.html
Anyway, it's still not clear to me what the licensing issues are for an 
Apache-licensed Squeak in terms of derived works built on top of it, and 
then how that interacts with added GPL code. But, after having been burned 
before on this, I prefer to know exactly what the most likely licensing 
implications are up front before committing a major effort to something 
(so I don't find out afterwards I can't release it).

--Paul Fernhout
(By the way, our garden simulator and other free software runs under Wine 
under GNU/Linux, last I tried it).

Jimmie Houchin wrote:
> Paul D. Fernhout wrote:
> 
>> I've looked at lua a little, but I really like Smalltalk syntax. :-)
>> It seems there are several prototype based systems (including IO the 
>> language) but they all seem to start out thinking Smalltalk (or Self) 
>> keyword syntax is a problem, whereas for me I see it as a solution.
>>
>> All the best. You might find our free software, especially the 
>> PlantStudio program, of interest for homeschooling for your kids. :-) 
>> That's the biggest thing I want to port to a dynamic language like 
>> Squeak or Python (from Delphi).
> 
> 
> I too love the Smalltalk syntax. It enabled me to learn Smalltalk 
> rapidly. The environment kept me comfortable as I learned the libraries 
> and provided me tremendous availability to learn.  But the syntax is 
> attached to Smalltalk. Now that isn't a bad thing necessarily. But if 
> you are looking at options which are not Smalltalk including Python and 
> Ruby which were mentioned in your essay. And I know you have worked 
> extensively with Python even tho' seemingly with angst. :)
> 
> In the options category I offered Lua. Lua is as much like Smalltalk and 
> more than some. 1 based indexing. Yeah! Blocks. do ... end.  No it isn't 
> Smalltalk, but if non-Smalltalks are an option then consider Lua. :)
> I think it is much closer to the philosophy of Smalltalk, Self and also 
> the syntax than either Python or Ruby. Now, I know you have a 
> significant investment in Python. But if alternatives are an option 
> consider improving Lua. :)
> 
> If not, then please tell us what lacketh an Apache licensed Squeak 
> requires for you to use? What compels you to look beyond Squeak? And if 
> you look beyond Squeak then the Smalltalk syntax isn't an option. As an 
> option Lua is nice. But it does desire libraries.
> 
> Unfortunately, can't try anything that's not Mac OS X or Linux. I don't 
> do Windows. So until your software is ported, can't try it.
> 
> Portability is one of the beautiful things about Squeak. Lua also is 
> incredibly portable. But graphics depend on the specific library. But of 
> course your accustomed to that. ;)
> 
> Squeak and/or Lua are very nice options.
> 
> Options are good.
> 
> Jimmie



More information about the Squeak-dev mailing list