Yet another lurker here.
While I'm not at all qualified to speak for the seasoned Squeaker
communities, I am qualified to comment on the issues I've found attempting
to implement some sample applications for contract bids on top of Squeak.
 I've also tracked the progress of Pharo with great anticipation, and have
spent a lot of time pondering what needs to change to make it useful for my
production work.

Here's a few thoughts, inspired by Dan Ingalls's famous 1981 Byte article on
the principles of Smalltalk.

Principle 9:

*Modularity:** No component in a complex system should depend on the
internal details of any other component.*


Well if you look in the latest Pharo image, you'll find there's around 38
methods of the Object class that amount to:

isFoo

^ false

Each of these methods violate this principle, not only in spirit but also in
practice.  While this has been common practice for ages, it means that
building downloadable modules that can be easily merged with any given image
is practically impossible.  As soon as you have two packages that define
their own class that wants to use
the same name, and register its own methods in a "base object", you both
violate the principle of modularity AND break other packages.

Principle 12:

*Factoring:* *Each independent component in a system would appear in only
one place.*


This is probably the single greatest reason for moving towards Traits across
the board.  But look at this concept in the context of two seemingly
entirely different methods:

Object acceptDroppingMorph: transferMorph event: evt inMorph: dstListMorph

Object hasLiteralSuchThat: testBlock

If you look at both of these methods, you'll quickly realize that they are
in fact the exact same method!  This is because they have the exact same
bytecode representation.  These two methods are also exactly the same as the
38 isFoo methods I mentioned above.  The only different is the semantics as
viewed by the programmer, but the reality is none of these methods should be
necessary, and should be factored out.  These methods only exist due to a
flaw in the design of the API and its semantics.  This brings up the issue
of

Principle 2:

*Good Design:* *A system should be built with a minimum set of unchangeable
parts; those parts should be as general as possible; and all parts of the
system should be held in a uniform framework.*


If you look at the problems of creating packages (see principle 9 above) or
the excessive verbosity which leads to inordinate redundancy (see principle
12), these ultimately stem from lapses in principle 2.  Over the years,
cruft has accumulated, people's code has become fragile and dependent on
that cruft (remember message passing's and modularity's purpose is to reduce
fragility), and result in an inertia against fixing the fundamental design
flaws.  We end up with arguments over Squeak vs. Pharo vs. Etoys because the
design of the core system has lapsed into disrepair, much like the US's
infrastructure.  A serious effort to address this short coming,
and re-examine old design decisions to improve the core infrastructure
would dramatically impact the future of all of these projects (as they
all inherit the same problems).

Principle 17:

*Natural Selection:** Languages and systems that are of sound design will
persist, to be supplanted only by better ones.*


The concept of forking the language, fixing core issues, and addressing
design flaws is a core principle of Smalltalk.  Maybe it is time for a
better one.

Just my two cents,

Dave

-- 
-=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090629/cc2fad27/attachment.htm