PataPata

Francois-

I noticed this discussion from a couple of weeks back related to PataPata,
and my wife, who speaks some French, gave me a rough translation:
   http://www.nabble.com/PataPata-t1915500.html
> by stéphane ducasse-2 2006-07-10 02:33
> C'est marrant de voir que cette personne qui s'est plaint de Squeak a
> prefere recommencer ailleurs au lieu
> de proposer une nouvelle mouture de Morphic comme est en train de le
> faire un argentain (juan vuletich).
> C'est marrant je n'ai jamais vu cette personne ne serait qu'envoyer
> un simple fix dans Squeak.
> Il a surement des tas de raisons.

You have been a little quiet on your side of the Atlantic, and if this was
the only reason, I should mention I have done some previous things done
for Squeak, of varying degrees of success, and mostly from about six to
eight years ago, so perhaps so long ago Stéphane has forgotten?

I have both contributed to the Squeak community and have specific reasons
for not just improving Morphic.

I was one of the first users of Squeak (Sun, Oct 6 1996):
http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/798b7a065f08bd7f/13361a9ffa40a6f8?lnk=st&q=&rnum=50&hl=en#13361a9ffa40a6f8

I developed Embedded Squeak (a small headless Squeak):
   http://www.kurtz-fernhout.com/squeak/readme.txt

I worked on a Newton version of Squeak (a fizzled project, admittedly, no
source on the web).

I released a Data Repository System for Squeak:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-July/003656.html

Some old comments I made on improving Morphic include:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-February/012486.html
which lead to my proof-of-concept of LinksWorld posted to the Squeak list
03/11/2000:
   "Here is one working example of some of what I am talking about for an
alternate design philosophy to Morphic:
   http://www.kurtz-fernhout.com/squeak/LinksWorld20000311.zip
This code example is similar to the concept expressed in another post I
made related to using networks of links as the basis for GUI building. It
runs under MVC much as Morphic does -- by not actually using the MVC
paradigm, but just presenting a "world" window. This code was developed
under Squeak 2.7, and I tested filing it into 2.4. It has not been
tested with 2.8."

A summary I wrote to the Squeak list of the deeper issues:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-September/009324.html
"There are really just a few core things that need to be rewoven
throughout the release -- modularity, exceptions, fonts (please not ones
reliant on Morphic) and then Squeak can really take off as the rest of
the parts can be added by individuals as modules. All are already making
progress (slowly).
But I think it unrealistic to expect an individual or even a group to do
these specific core things outside of SqueakC (given the current state
of affairs). Just about everything else, yes. For example, I have in the
past offered things like LinksWorld (with undo) or the Pointrel data
repository system as Squeak add-ons.
These few core things I mentioned would be best done by the core group.
Unfortunately, at this point what we have now (to greatly exaggerate,
admittedly) is in effect the core SqueakC team working on extensions and
applications (Morphic, eToy, 3DGraphics, Scripting) and everyone else
working on core issues (exceptions, fonts, modularity, block variables).
If Squeak was more modular, this inverted approach might work better.
But it's not yet. And making Squeak more modular requires making massive
core changes -- a Catch 22 (even I think for the Squeak Stable World
Tour, but perhaps that will have oompph enough to get past it.)"

You can Google for lots of other comments I've made to the Squeak lists on
lots of issues relating to making Squeak a better system. Essentially, the
core issues relate to trying to manage complexity in Squeak.
For example:
"Belling the cat of complexity (was: Ship it with Squeak)"
http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-June/001371.html
(including proposing a "harvesting" process). From there:
"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."

One big issue I wrote extensively on the Squeak list was simply the
license and related issues -- the Squeak license was not true "open
source" or "free software" (especially regarding indemnification and
export provisions), and there was never a clear statement from Disney as
to the licensing of the work done while Alan Kay's group was there. I
begged Alan Kay to get one as his group left Disney, but essentially got a
reply that software copyright and patents were so messed up that licensing
was always problematical and if you read the Squeak license a certain way
their stuff was covered somehow. He said similar things publicly
later, a related example being:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-March/054984.html
(which also proposes going beyond Squeak, which I am trying to do).
I'm willing to tolerate some ambiguity in licensing issues,
but that seemed pretty much beyond what I was comfortable with. :-)
So legally IMHO Squeak itself was (and still is) a shaky
foundation to build on (the Disney issue being the most problematical in
my opinion). Technologically interesting, yes, but legally problematical.
I also had the Squeak situation reviewed by the legal team at one of the
biggest computer companies in the world and could use it only with a lot
of big restrictions even with Disney as a partner (no distribution of the
results being the biggest one -- and that big company even had one of the
authors of the Squeak license working for it by then and helping
me with the approval process). By contrast, Python got the go-ahead for
doing all sorts of stuff with around 1999 (embarrassingly to me, they even
asked Guido directly if Python was original) when I wanted permission to
use that for an R&D project. Personally, it would not surprise me if that
licensing was also one issue driving some of Alan Kay's groups interest in
Python (although I think visibility is still probably the bigger draw. :-)

I think history has proven me right on these things. As much as people
protested or ignored these points, these issues of managing complexity
(e.g. "bit rot") in Squeak and of dealing with licensing issues continue
to limit Squeak's growth and development. For example, recent posts by
others on Jan 30 2005 :
"Squeak is an unsuccessful open source project (was RE: Let us face reality)"
http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-January/087609.html
(I agree Craig Latta's work is a great direction).
or:
"The state of licensing... and a Dream! (was Re: Proposal for a Squeak
migration meeting)"
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-June/105229.html
Or even:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-March/055566.html

I *could* solve the technical issues with Squeak (and would have enjoyed
doing so); I could *not* solve the legal ones by myself, or the complexity
management ones of seeing any improvements I made be left to rot as the
core team focused on just adding more complexity (which I had already seen
happen to other submitters for patches related to fixing core issues.)

People are now trying to address these core complexity management
issues in Squeak and doing a good job of it, but for me the licensing
issues remain as unresolvable ones. Others (including presumably
Stéphane) naturally have their own opinions on the licensing situation,
and many agree with Alan Kay's opinion, and so focus on improving Squeak
directly, and I wish them the best of success with that.
And here is a good idea by Stéphane on how to slowly fix even the
licensing issue:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-June/105257.html
The copyright "contamination" problem would still there to varying
degrees, although it would also haunt contributions by anyone, including
myself, who has used any commercial Smalltalk which generally come with
much source, and most Squeakers fall in that category.

Still, even Alan Kay himself repeatedly suggests just thinking of Squeak
as a stepping stone to the next great thing.

These were the sorts of things I wanted to address such as with this proposal:
http://lists.squeakfoundation.org/pipermail/squeakfoundation/2002-January/000357.html
"The intent of the Bellesqueak list is to support a community process
which creates, discusses, uses, and maintains a cross-platform computing
environment and knowledge management system inspired by Squeak Smalltalk
called Bellesqueak. The focus of Bellesqueak will be on transparency,
robustness, and complexity management -- to support the doing of good
deeds such as education, sustainable development, and ensuring humanity
survives Vernor Vinge's Singularity in some form."
But, that effort did not progress (although PataPata is a form of progress
on it).

I just took a week vacation to visit relatives, and now I am
reevaluating what I want to do with PataPata -- like whether to continue
with Python or reconsider the idea taking the lessons from those versions
and move towards putting prototypes with a Smalltalk/Self syntax on top of
OCaml (and perhaps other syntaxes as well, indentational Scheme,
Python-ish, etc.). I remain intrigued by the notion of building prototypes
on Ocaml (using it as a "better C") to create a system that has late
binding for most things in the system I build but have early binding for a
few performance issues like the delegation code itself (which is currently
in Python and so, in this case, not as fast as it could be).
Alternatively, modifying the Jython compiler for the JVM to use prototype
delegation routines written in Java  is another route to gain performance
but in this case stay close to the Python language model
(and probably advantageous from a copyright "contamination" point of
view). Both approaches have pluses and minuses, as does just sticking with
plain Python.

--Paul Fernhout