---------------------- Forwarded by John Gardner/DMR/CA on 03/22/2000 03:03 PM
---------------------------


John Gardner
03/21/2000 01:36 PM

To:   stp at create.ucsb.edu
cc:   John_Gardner at dmr.ca
Subject:  Future Direction for Squeak Comments

Hi Stephen,

You do not know me, but I've been following the Squeak End notes and other
discussions with interest. Why? Because I'm a former UNIX/C/Java architect who
is striving to convert to Squeak. I'm writing this email to you because of your
role and I was not sure where my ranging comments belonged on the Squeak SWIKI.
My comments follow:

1. The dream.
For many years, I have been looking for one language with the flexibility and
portability to do it all. System programming, application programming,
scripting, ... everything. And it must be able to run on practically everything.

2. The reality.
The OSF ANDF proposal held great promise. But, vendor interests killed it. Java
held great promise, but once again, vendor interests have effectively killed it.
Even Smalltalk has suffered from vendor encroachment, resulting in a number of
dialects. Alan Knight and others are trying to bridge this gap.

3. The marketplace reality.
It used to be C++, now it's Java. I really do believe that a well designed
implementation of Squeak can beat those languages. However, as addressed in
SqueakEnd 00, there are some things to change. Even so, I know that Squeak has
some architectural advantages over C++ and Java.

4. Some recommendations.
Anyone wanting to learn Java has access to a large body of full tutorials,
examples, and books. These resources do not assume a previous knowledge of Java,
unlike the perception I get from Squeak resources. Possibly a "Squeak in 21
Days" approach is useful.

Java has JAR files, Beans, a full set of Widgets (not including the Swing API),
full support of a number of Internet protocols, messaging through RMI, IIOP,
compression support, security and so on. I know that Squeak can compete.

A category, or class, which performs the code removal of unwanted classes,
disabling/removal of all development tools and external access,  and "packaging"
of the application into a production Squeak image (similar to JAR file) with
authentication and compression characteristics allows Squeak to compete with
Java.

Even though support for RMI/IIOP is important so that Squeak can interoperate
with other objects (EJB, Corba, ActiveX) a native protocol for Squeak to Squeak
communication can take a different tack. Possibly, extending the HTTP protocol
to support method calls (methods), or perhaps an implementation of RPC-type
capability.

Where are the Widgets? We need more widgets. An OutOfBox developer experience
should perhaps use MVC-based widgets and core Squeak classes. Morphic and Alice
should continue to be delivered as separate categories to a "base" Squeak set of
classes. Just as Java developers view Swing as an alternative to AWT.

Java aficionados declare you can learn what you need to know in a few hours a
begin coding useful applications (applets, etc) right away. We need a Squeak
equivalent.

Primitives, This area is very interesting, especially within the context of a
modular VM, built up to a full Squeak VM. As well, generating primitive code (in
C) is a terrific idea.

Squeak has something that Java does not. That little option to "update from the
server" to retrieve upgrades dynamically. This holds great promise as a
mechanism for updating production images at customer sites. The closest that
Java comes is downloading a new applet. This update mechanism holds great
promise for distributed Internet based applications and their maintenance.

As I learn more about Squeak, and start to write some real code I hope to
contribute to the open source community. I admit that I do have a commercial
interest in using Squeak, however, I do firmly believe in sharing non-product
code, as per the Squeak license.

Hopefully this email is useful as a perspective from someone who has not been
part of the Squeak/Smalltalk community for many years.

Thanks,

John.