Glyph Lefkowitz wrote: 
> As a newcomer to squeak myself, I've had a lot of these problems too.> > [Snip: comments at]
>         http://twistedmatrix.com/users/glyph/rant/sqcr.html
> 
> Feedback will be appreciated!

I enjoyed your write up. It takes a certain set of skills to be able to
produce such a detailed and well written set of issues from a first-hand
perspective, and thanks for doing it.

You get pretty much complete agreement from me. I came to Squeak from a
lot of recent experience in Delphi and VisualWorks, and I found both
easier to construct at least simple applications in (well, VisualWorks
took some more work on the GUI side but shined in other areas).

I especially likes these points from your detailed web page:
> I downloaded approximately 50 changesets, 
> and every single one either gave me a walkback upon
> filein or conflicted with another seemingly innocuous changeset 
> in such a way that a basic task (opening a
> Browser window, or better yet, entering the debugger) 
> would give me a walkback. 
> [snip]
> Despite the pleasantness of the debugger, the sea of broken links,
> broken instructions, and broken code only gave me three conclusions 
> to jump to:
> [snip]
> 3. It is nigh impossible to actually write and maintain a significant
> amount of code which stays current with
> the SqC image, despite many heroic efforts to the contrary; 
> so you have to have 6 or 7 different images
> lying around that you can actually run squeak code. 

On my system right now I have (at least) 1.13, 2.2, 2.7. 2.8, and 3.0
each for a different reason. I'd agree #3 is the big issue. As is lack
of time for many people (including those at Disney who have to deliver
applications instead of Squeak improvements) which may lead to a bit of
#1.

And your conclusions:
> Why It's Worth it Anyway
> While these problems are certainly significant, and even if the
> community were already 100% dedicated to fixing them, 
> it would take a while to get to the point where they were all 
> solved, they are at least theoretically solvable. 

Agreed. 

And that is the issue delaying several people's use of Squeak for big
things, myself included. I figured a while back it would take four
months of an experienced and "in-the-groove" Squeak developer to make
the base of Squeak useable for many (not all) commercial quality things
on one platform. This has improved since then, but it still is a big
chunk of time; why dealing with fonts alone chewed up a lot of people's
time with licensing issues, discussion, etc. 

I almost did that push anyway for a 2.0 version of one of our products,
but ultimately the risk seemed too high (given SqueakC's relentless
advances in a Morphic direction) and we stuck with Delphi for our 2.0.
Yet we have endless requests for a Mac version, and Squeak would
otherwise help us do that. Yes, VisualWorks is an alternative obviously,
but I wanted an open-source platform. DrScheme also comes close, being
open source and cross-platform (and modular), but lacks some of Squeak's
other transcendent features.

> I don't believe that, for example, giving Python real automatic
> orthogonal persistence, or speeding up the interpreter by a 
>factor of 10 to 25, is solvable in any practical timeframe. 
> Or making C or C++ a reflective language. Squeak solves some 
> very basic problems pretty well, and addresses issues that 
> most other environments and languages just ignore. 

Agreed, with a reservation. Modularity is a basic thing. Squeak gets
almost every other basic thing right because it is based on Smalltalk
which got them right, but modularity isn't something that is easy to
"patch in". In fact, if you are modular, almost everything else is
easier to patch in. Python and C/C++ still tempt me over Squeak because
they are modular. For example, I can use any of several snappy GUIs with
Python (TK, wxWindows, SDL, etc.). And solutions to these problems have
been handled in different ways because of that modularity (Python
extensions in C, sections of C code written in an OO style or bundling
in Python as an extension language).

I think there is a fundamental paradigm issue here. The original
Smalltalkers now at SqueakC pioneered the notion of an interactive
personal development environment. They gave the world something really
incredible that in many ways still has not been surpassed by anything.
Given this and the small systems of the day, and that all the
Smalltalkers at Parc  worked together, and incredibly brilliant people
like Dan or Adelle were there to smooth over rough edges with
hand-holding, modularity wasn't a big deal in the early days. Also, some
people are rightfully proud that the image has been "alive" since then,
like some sort of a pet. It seems to me some people are happy with the
notion of a million different images, each laboriously maintained by a
reasonably skilled (or quickly learning) user, because for them it is
part of the success of the initial vision and the initial paradigm.

The UNIX world which grew out of Bell Labs (whose traditions spawned
C/C++ and to an extend Python/Amoeba) for example has a different
paradigm. That is a hierarchy of protected resources, reflected in the
UNIX file system. It even is reflected to an extent in how the Linux
effort works -- Linus at the top in charge of the kernel with CVS
checking privileges for that code, with others in various groups in
charge of tools that run on Linux with permissions to commit changes to
those (like as on SourceForge). However, even in the Linux world there
are organizations like RedHat with their own local privileges to decide
what set of versions of specific components together comprise a release.

Manual De Landa in his book "A Thousand Years of Non-Linear History"
talks about "hierarchy" and "mesh-works" as two organizational forces
that are always intertwining on a practical basis. The problem we have
here is a basic difference in slant from SqueakC and developers coming
from a Unix (or commercial) background. The original Smalltalkers must
believe in mesh-works, but we are saying Squeak needs a bit more
hierarchy. The reality is probably that something in the middle is a
better thing than being at either extreme.

> However, making the virtual machine modular, adding namespaces, 
> fixing the UI [etc] is a difficult, but eminently possible task.

Agreed. Having pluggable primitives is already there to an extent
(yahoo!) as a nod to modularity, but the deeper issues of modularity
(vm-to-vm remote debugging), namespaces, and alternative "classic" GUI
are big things. Still, these can be helped along with fairly minor
concessions -- again, GNU Smalltalk has some good rough-and-ready ideas
here.
 
> The problems I've enumerated here are some of the things I hope 
> to work on as I work with Squeak. 

You and many other people! Some of whom come to this list periodically
and then drift away... However that urge will only persist if we think
the base is stable enough so our efforts don't get swept away. Since
many of these issues are core ones, the likelihood of obsolescence
happening is high. Open source may draw a lot of effort, but what good
programmer wants to see their effort lost? There needs to be a group
that has a mainline distribution with an emphasis of addressing these
issues. (SqueakFoundation?) 

I wish that the stable branch was at the root of SqueakCs work, but it
doesn't seem to be the case, possibly in large part for ideological
reasons mentioned above (mesh-work vs. hierarchy). Hopefully the
community is strong enough finally that it can withstand a fork, which
seems imminent (with Stable Squeak). My prediction is that within a year
if a fork happened and took off, no one will want the SqueakC
distribution, except to load specific add-ons from Disney to a stable
release. But there is a high cost for everyone to pay -- both people
making the quantum jump to support a new release, the intermediary
confusion and ambiguity (is stable Squeak really going to take off?) and
the final issues of SqueakC reintegrating their own work with the stable
base as a module.

Personally I would love to see Apple and/or IBM (both large
organizations who benefit from supporting cross-platform standards) play
a hand in underwriting or coordinating this effort, possibly through a
chaordically organized Squeak Foundation, perhaps under a more
conventional open source license like BSD or LGPL if Apple was involved,
with an effort made to clearly get every contribution starting from 1.13
on under an explicit license and statement of origininality (yet another
issue!). I find it hard to believe for example there is no one left at
Apple who sees Squeak's strategic value to Apple's prospering. Still, I
think even without them there are more than sufficient resources and
skills on this list to make this happen as a cooperative effort, and it
is already happening, although in fits and starts. It's just too bad it
required a fork.
 
However, the essential thing to remember is the most important aspect of
Squeak is the community and this mailing list. If we all "burned the
disk packs" I'm sure this crowd could have a better Squeak up and
running in six months! (Probably with protoypes like Self.) Whatever is
done, I think an essential aspect of any effort has to be to keep the
Squeak community strong and growing.

-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