Belling the cat of complexity (was: Ship it with Squeak)

john.g.gardner at ca.pwcglobal.com john.g.gardner at ca.pwcglobal.com
Fri Jun 30 14:17:38 UTC 2000



I agree.

It also looks like many people on this list agree with the following principles:

1. Squeak should be open and usable by everyone, with base class/VM changes
submitted for everyone's benefit.

2. A modular Squeak, built up from a core functionality using images or plugins.

3. A packaging utility which strips unnecessary classes from the distribution
and wraps some installation functionality around a shipping product.


I would like to add the following principles:

a) Fully documented classes. If we are taking the time to create the
class/method, surely we can take a few minutes to describe its purpose.

b) The ability to lock your image when you are distributing a product, to
prevent reverse engineering of code.

*** Please note: this is only for a production image. This does not apply to the
development image and contributions made to it.

c) The ability to combine the VM and the image file into one executable for
shipping a product. This may help with b).

d) Leveraging the "update from server" functionality as a way to update
customers with new features or patches.


My personal position is this:

1. I would like to see that Squeak becomes a viable tool for creating software
products for sale. An open source version of Smalltalk is a powerful competitor
to Java, C++ and commercial Smalltalk.

2. As open source, we would still freely contribute new functionality to the
base class or VM.

3. Right now, today, I still find more functionality in public domain versions
of Java/IDE than Squeak. And yet, Squeak is a better environment for
development.

4. It appears that Squeak suffers from class bloat and bolt-on functionality
through categories. I saw this start to happen with Java after version 1.0.

My spirit is with Squeak, but my wallet is still with Java. This won't change
until Squeak incorporates the changes outlined above, to become a superior
language to Java, C++ and others.

Thanks,

John.





Paul Fernhout <pdfernhout at kurtz-fernhout.com> on 06/29/2000 10:17:47 AM

Please respond to squeak at cs.uiuc.edu
To:   squeak at cs.uiuc.edu
cc:
Subject:  Belling the cat of complexity (was: Ship it with Squeak)



Squeakers-

There is an old story of how a bunch of mice get together and a have a
long debate about what to do about the cat who they live in terror of.
The cat is so quiet it can sneak up on a mouse before it knows it and
devour it. After long deliberation they hit upon a great idea -- if the
cat had a bell around its neck, they would all hear when it was coming
and could scurry to safety in advance. The mice relax, all satisfied,
until one of them asks, "Well, who is now going to bell the cat?"

Squeak complexity in 2.8 has become a complex cat from the simple kitten
complexity of 1.13(?) in 1996. Back then, Dan Ingalls wrote on 10 Nov
1996 those prescient words: "The Squeak team has an interest in doing
the world's simplest application construction framework, but I suspect
that we will get sucked up with enough other things that this won't
happen in the next two months (but who knows...)."

Squeak 2.8's complexity is now quiet (in terms of walkbacks) and
stealthy (in terms of growing between releases without a complaint). And
the complexity could be deadly. Witness the recent issue Stefan raised
about some Squeak fonts possibly violating a Microsoft EULA. The
question should never even arise of the legal integrity of the core
release. We might as well just leap right into those jaws of complexity.

I appreciate all the comments on "Ship it with Squeak". There were many,
many useful suggestions and comments. I have read them all with great
interest. Les Tyrrell put the issues very eloquently, and makes me
realize this issue for shipping is really best put as "managing
complexity in Squeak to reduce the risk of unexpected behavior in an
application to an acceptable level".

The complexity in Squeak comes in two areas: code issues and license
issues. The complexity of the code mudball has been discussed at length.
The complexity of the license issue comes up occasionally, and Stefan's
point about licenses is an example. Using software without a clear
"title" is like buying a house without a "title search" -- someone can
always come along later and make a claim against the house. People can
always make claims, the issue is that a title search (and related
insurance) reduces the risk to the point to reasonable levels.

I would recommend looking at the (older) Python submission guidelines
for some
ideas on what to ask from contributors:
  http://www.python.org/patches/bugrelease.html
  http://www.python.org/patches/wetsign.html
These are basically statements of originality and disclaimers of
contributor's liability. If all contributions to Squeak came with such
disclaimers, the licensing concerns would be greatly reduced. The
legality of contributions flows through from contributors to CNRI to
official legal releases. Now that Guido has moved to the private
Pythonlabs, things have changed to:
   http://www.python.org/patches/
and I don't know the exact status of what is signed to ensure the
contributions legal. Who would replace CNRI here in the Squeak case (if
anyone) is an issue.

A mouse probably can't bell a cat. It's just too hard. But maybe, just
maybe, a mouse could bell a kitten.

I brainstormed some with Doug Flower about steps to bootstrap Squeak
towards usability in business. What came out of that was a sense that a
Squeak useable in many of the same areas of Perl might be a good start.
He and many others who know Smalltalk have an immediate business need
for such sorts of activity. Such a system would be useful if it only was
able to read, write, and process text files. And enhanced version might
handle sockets and other text streams. Ideally, this system would have
an end-user GUI useable for setting parameters for such operations (in
dialog fashion), but that is less essential since parameter files could
handle this.

The reason why this application area is interesting is that it is of
real business need, but it does not have all the deployment issues that
shipping applications does. A Squeak operating in this area can have
more rough edges and still be very useful. People are already doing this
with Squeak, and might see the benefit to a smaller size system they
could leave with clients or carry on a floppy. So that is what I think
makes a good first step towards belling the cat of complexity -- trying
to first bell the kitten of file handling utility applications.

How should I proceed on this?  Here is one approach, although obviously
it may have problems and another might be better.

Think of this as a "harvesting" process. The Squeak community has
generated much useful work -- the time is ripe to harvest it into a
stable, legal platform. My first impulse is actually to go all the way
back to the first Squeak release (or possibly the last one done at Apple
if it is pure Apple code with just minor patches). Then, that version
can be reintegrated with later patches that people have made, as long as
the contributors are willing to agree to something like the Python
disclaimers. Note, these disclaimers might be rewritten to be just
general disclaimers, not specific to giving special rights to a company.
The disclaimers might also put rights under a Squeak-like license, not
as broad a license as Python, depending on what people on this list have
to say.

One reasons for going all the way back to Apple code is that frankly, I
don't know what license Disney changes are really under. Unlike the GPL,
the Squeak license names a company. I don't think just including the
Apple license with a distribution really says anything about the
licensing of your changes. I raised this issue a year or two ago on this
list and don't recall getting a decent answer. That uncertainty is
probably acceptable for playing around but makes business use harder to
accept or promote.

[Optional: Of course if one goes back that far (to the orginal release),
perhaps one might ask Apple to change the license to one more like
Python's so Squeak could be more easily used in embedded systems with
specialized VMs. I had a problem with this in terms of legal approaval
-- an awkward workaround is to use pipes to communicate from the VM to
services, but ultimately the real workaround was to use Python with a
less restricitive license. Python shows you don't need a draconian
license to get people who want to contribute to contribute. The value to
Apple is simply in making a system that helps keep the Mac on a level
playing field with all other systems. Also, then Squeak would finally be
compatible with GPL'd code.]

Such a system would have as its first priority modularizing the image.
Such an effort might include tools to assist this process, such as the
wonderful effort by the 4th Estate.

The effort to manage complexity would take precedence over bug fixes,
GUIs, event handling, or anything else. It would also include building
the image from scratch -- where every last byte was known and accounted
for.

Once this old Squeak was modularized, then fixes would be made purely
from the standpoint of stability. These would focus primarily on
stability of utility related code, and secondarily on stability of
development tools. Code would need to be added to handle common text
manipulations, including XML input and output. GUI changes would be a
minimum needed to control file manipulation.

Later, after this stable base existed, one could add all sorts of bells
and whistles -- in a modular fashion.

I'm sure people will say this would be a lot of work -- perhaps too much
for one person. You might be right. Frankly, I still may personally
decide that working in another platform instead might be easier, or
might say being cross-platform has too high a cost for the rewards. In
that case, putting a Squeak-like cross-platform GUI underpinning to
Python might be another choice, because I can control the code I write
-- I can't control what others do with their license. So it may make
sense in the end to just start instead from a system with a clear legal
standing and go from there adding Squeak like features. I love Smalltalk
-- I'd rather make Squeak work. It is just that the effort does seem
substantial.

It's easy to say "just do it and it's done" when your salary and your
employees' salaries are paid for with other people's money, where those
deep pocketed people actually expect you to do unexpected things and
trust you to accomplish them whatever it costs. It's also easy to say
"just do it and it's done" when there are no legal complexities to worry
about -- e.g. you're not in the risk situation where you do it and it's
not done because you legally can't ship it.

Also, reprising Squeak's evolution Squeak from the start would entail
bothering a lot of people on the list to submit patches they already
submitted, and even trying to get people making major contributions to
sign some sort of actual paper document (exact form to be decided). This
certainly isn't fun work for an introvert.  I just don't see another way
to proceed that handles issues related to the code and legal
complexities of producing a minimal Squeak useable for things like XML
processing or rewriting text files. There most likely needs to be a
legal audit trail of the legitimacy of submissions, and that trail must
be guarded by someone who would not let stuff like Microsoft fonts in no
matter what the EULA says.

The Squeak development process so far has been great in terms of
generating code, but not so great in terms of managing complexity of
that code or the surrounding legal issues. So maybe now has come the
time to harvest the results of all that productive effort? And as any
Object Tech Center person would say, Object harvesting is itself a
time-consuming process.

In summary: If we can't even get together a simple and reliable version
of Squeak without a substantial GUI for text file handling which does
not have substantial legal issues, then there is no hope for a version
of Squeak for shipping cross-platform apps with GUIs. If a utility
version of Squeak that is legally sound can be produced, it might serve
to bootstrap a more substantial system which could be used to deploy
applications. And, hopefully, every time complexity increased in that
release, a little bell would ring and we'd know what was coming.

More comments appreciated. Thanks again for those who responded to the
last post.

-Paul Fernhout
Kurtz-Fernhout Software
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com




----------------------------------------------------------------
The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential and/or privileged material.  Any
review, retransmission, dissemination or other use of, or taking of any action
in reliance upon, this information by persons or entities other than the
intended recipient is prohibited.   If you received this in error, please
contact the sender and delete the material from any computer.






More information about the Squeak-dev mailing list