Thierry -

Clearly Squeak has many people using it for many different reasons. 

Thierry Thelliez wrote:
> I am impressed by the Squeak technical efforts but I don't understand
> the 'marketing' directions.

The best reason I see for using Squeak is to learn about a standard code
base to support Smalltalk-like systems across many platforms (Mac, PC,
UNIX, Acorn, WinCE, etc). One can often learn best by adding to the code
base one's self of course. This code base could become an open
standard for many sophisticated dynamic object programming efforts -
like LINUX, GNU C++, or Apache are open standards in their respective
fields. Especially with the imminent 2.0 release including an improved
Morphic interphase, Squeak is poised for greatness. But the great thing
about Squeak is that even without a version 2.0, you can make your own
version 2.0, perhaps in a totally different direction (perhaps with
prototypes, or native widgets, or TK widgets, etc.).

> I am using VRML plug-in and this is accepted by my customers. 
> Why not a squeak plug-in ? 
 
John Maloney already worked on a Squeak plug in for Netscape; maybe that
work could be dusted off? I'd certainly love to see plugins for IE and
Netscape. Maybe bringing John's work up-to-date that would make a good
first project for someone?

> Probably like in a lot of places, my organization is getting 
> crazy about Java. You have to be 'hype-compliant'. And justifiying
> Smalltalk is certainly not an easy task; especially with ObjectShare
> and GemStone pushing so much for their Java products. 

We must distinguish between the "Why Squeak?" and the "Why Smalltalk?"
questions implicit in your post.

Why Smalltalk?

I'd be curious to hear business justifications for using Java over
Smalltalk. Why would anybody use Java? It is a recently cobbled together
language and API that no one (well, hardly anyone) has ever used
successfully in mission critical applications. I'm not saying Java
doesn't have some features that Smalltalk does not have out of the box
(security, standard object format for transmission across networks,
etc.). But these are mostly doable in Smalltalk (especially when you can
change the VM as in Squeak) -- maybe the problem is there
are too many ways to do these in Smalltalk. Some Java features may also
not always work right in Java across multiple versions (1.0, 1.1, 1.2)
anyway, so what's the real advantage? The biggest single advantage Java
has is being built into Netscape & IE (which have become popular
applications with the explosion of the internet over the last two
years), and that is not as much as an advantage as one would think
because you are locked into an outdated 1.0 standard for applets if you
want to reach a wide audience, and that 1.0 standard has flaws and major
limitations.

Java's success could be another instance of the old saying: when a C++
project fails they fire the manager; when a Smalltalk project fails they
fire the language. Now it is: when C++ project fails, they turn to Java
(and then when that fails they fire the manager).

Many people pushed C++ over Smalltalk because of the supposed
importance of execution speed over portability, multiple inheritance
over single inheritance, manual memory management over garbage
collection overhead, and because it looked familiar to C programers. The
same people watched projects fail because of portability issues,
unexpected interactions due to complex class hierarchies, too much time
spent debugging deallocation errors, and poor designs made by
programmers who didn't know OO. And if the project gets done despite
this, it may well fail as soon as it has to be changed. These same
people who pushed C++ on doomed projects are now raving over Java
because it kind of looks like C++ and kind of has those other features
they criticized in Smalltalk. Clearly Java is better than C++ for most
business purposes. I guess that's all they see -- not that, for those
same business purposes, Smalltalk was better than C++ then, and
Smalltalk is better than Java now.

I've been looking into writing a Java applet for a project where it
might make sense. This would be an educational applet for NASA (related
to a space habitat simulator and manufacturing technology database). The
key feature Java has over Smalltalk for this is that a Java applet
doesn't have to be installed by teachers (who often have much trouble
installing software and little time to deal with installation problems).
To take advantage of this "no installation required" "portability", the
applet would have to be written in the outdated JDK 1.02 so it can run
on browsers almost everywhere. It would still require much testing to
find and work around bugs in old Java VMs especially in older Netscape
versions on different OSs so everyone could use it. I'm still hoping to
convince them to consider Squeak, based on the notion that any serious
application could not be an applet, and installation will be required
eventually anyway, and Squeak is then the best cross platform solution.
This will be a long road... Maybe I can convince them to have a one time
install of a self upgrading Squeak system that could support multiple
educational applications (if such a thing could be created)?

It is quite likely I would have to do a Java applet first, push the
limits, and then step in later with a Squeak solution when the Java
applet hits its limits. Because I love the subject area, I'm willing to
consider this round about approach. Otherwise I wouldn't bother with
Java at all. Java's not as much fun as Smalltalk, and developing
software is hard enough to do even when it is fun much of the time (as
with Smalltalk). Happy programmers are better programmers. Of course,
clearly Java is more fun that C++, which is why it is gaining in
popularity as people leave C++ for it.

Why isn't Java fun? Based on a scanty bit of research, here are the sort
of "gotchas" any Java project is likely to encounter: "Whoops, you mean
you can't actually print that Java applet's output?" No problem, just
get everyone in the world to upgrade to the latest browsers (and then
patch them afterwards as well). "Whoops, you mean you used JDK 1.1 or
1.2 instead of 1.0 because it fixes bugs and provides new features?" No
problem, get everyone to abandon Netscape and Internet Explorer and use
Sun's HotJava browser instead. "OK, we're going to create standalone
applications and not applets because then we can use the latest
features! That sure will be better than doing it in C++!" But then, why
use Java for a stand alone application when it doesn't have many of
Smalltalk's features and is in a constant state of flux?

Oh well. At least with Java people now acknowledge the virtues of
portability, single inheritance, and garbage collection. That's a big
step forward.  Now if they could just see the benefits of having
everything being a first class object, creating blocks easily (not inner
classes with six lines for a block), modifying code while it runs
(easily and routinely), using a function call syntax that provides named
arguments, browsing system sources, etc.  Until then, Smalltalk remains
the greatest well known "secret" weapon of people who invest in learning
how to use it well.

If Smalltalk, why Squeak?

Because Squeak is free, both economically and source wise. It does not
lock you into a specific vendor. You can change it to fit your needs. As
the Squeak community grows, more and more people will know it well and
be able to support it. How any people know the VMs of ObjectShare or OTI
well? Squeak is the future. Many people get paid to use GCC (GNU C++) or
LINUX or Apache at work. Why not have people get paid to use Squeak?  

Squeak is a bit like the story of "stone soup". If enough people add
things to the soup, it will be delicious. A year ago Squeak was pretty
good soup. Judging from the contributions since then (morphic, web
servers, ports, jitter, sound I/O, sockets, MIDI, etc.) it is turning
into a hearty stew. 

The major weaknesses I see with Squeak right now are speed (that of a
Java applet in some browsers, 1/40C (1/20 with Jitter?)), the lack of
standard GUI components (like comboboxes), lack of standard exception
handling, and lack of local block variables (not shared in the method).
People are working on all those issues, and I have more confidence those
will be improved or that speed won't matter as computers get faster,
than I do that Java will ever become an open standard with the features
I want (which Smalltalk has right now, like first class objects
everywhere).

I already have a $9000 (just the software cost) VisualWorks/ENVY system
on my desk, and I have Digitalk Mac&PC, QKS, VA/ST trial, etc. sitting
on the shelf along with more other development systems in various
languages than I care to name. Why do I want to use Squeak? With one
exception, I'm not interested in Squeak because it if free economically.
I am interested in Squeak primarily because it is free to be changed in
the ways I want. And after I change it, I can then ship apps that
include the compiler and development tools. 

That last point is an economic issue, since I'd like to use the compiler
and debugger etc. as part of some simulation development tools, and I
(or the potential end users) can't afford any Smalltalk vendor's open
run-time fees. So in that one sense, being free economically makes a big
difference to me, as someone who wants to ship open tools. Technically,
Dolphin or ST/V Express or LearningWorks might also fit the economic
freedom issue (although their licenses may still prohibit distribution
for profit in a bundle without prior permission), but they are certainly
not free in the "modification" sense, especially at the VM level.

As a programmer, I've had many vendors let me down (in Smalltalk and
other languages), after I paid much money for their systems. Bugs don't
get fixed; enhancements I was counting on get scrapped; ports don't
materialize; to a small developer, advanced technical support is often
unavailable, overburdened, or useless (even at $3 / minute over the
phone). Squeak provides an alternative where you can fix it yourself, or
at the very least, pay someone else to fix it for you on your schedule
-- not the vendor's. That ability to improve the system draws many
people to Squeak; it is the essence of the original Smalltalk
philosophy. In a sense, the term "Smalltalk vendor" is an oxymoron. 

Given all that, here are two suggestions for promoting Squeak:

* For the near future, if you are a Smalltalk consultant, offer to work
for six months or so at a significantly reduced rate on a project in
Squeak. This will give you as "industry" experience in this great
technology, and will get companies moving in the Squeak direction to
their own short and long term benefit. This is an investment by both the
consultant and the company in the open software Squeak future. Since
much of most projects isn't really platform specific programming anyway,
this is a great deal for a company willing to try out Squeak (even
though some of the applied work will be wheel reinventing compared to VW
or VA and will hopefully be given back to the Squeak community). If you
really have confidence that Squeak is the future, you know that after a
while you will be able to raise your Squeak rate when everyone is using
Squeak and experienced Squeakers are in great demand. Of course, you
have to be in Squeak for the long haul, and it helps to have a spouse
who can earn money if you're wrong :-)

* Encourage other companies (besides Disney and Apple) to contribute to
the Squeak effort, by either investing in developing technology directly
in Squeak, or by purchasing technology and donating it to the Squeak
effort under the Squeak license. Why does this make sense for a big
company? They gain an edge in riding the wave, getting involved, and
helping shape the Squeak standard so it includes and adequately meets
the company's needs. Will other companies (even competitors) benefit?
Yes, but that doesn't mean the orginal company won't benefit greatly
(and probably much more than companies not directly involved). With
Squeak as an "open" secret weapon, it will be years before the company's
competitors come to believe in it, and by then the company will have a
huge head start in integrating this open standard into daily operations.
I would encourage any big company out there to follow Disney's and
Apple's lead, and make an investment in an open Smalltalk (even a small
one). Open software is the wave of the future -- just ask Netscape.

I'd be curious to hear other people's insights into Java vs. Squeak (not
wanting to clog up the Squeak list with Java flames though, so maybe
this would be a good Wiki topic). I'd also like to hear more ways to get
companies using Squeak on supported projects and investing in its
improvement. Of course, ultimately, Squeak's long term success will
probably depend more on individual efforts than corporate support, but
corporate support might speed things along (although in what direction
I'm not sure).

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the StoryHarp(TM) Interactive Story Authoring System
http://www.kurtz-fernhout.com