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
|