Andreas Wacknitz wrote:
> And many of the newcomers get alienated by many aspects of Squeak:
>     - it is hard to find documentation
>     - it is hard to get used to Morphic (its power isn't obvious but 
> its clutter is)
>     - it is hard to find a Squeak version with not so many obvious 
> bugs and problems
Long time lurker here,

Short answer: (For those who don't want to read the post)

Newcomers are turned off by seemingly irreducible complexity of the 
system; Squeak need continual refactoring.

Long answer:

My two cents as a "newcomer" to Squeak would be that all of these are 
real problems.  Every year or so I evaluate Squeak, as well as 
commercial smalltalks as part of my consulting business.  To give you an 
idea of where I'm coming from, our business helps startups identify new 
technologies and design platform architectures for "emerging markets".   
Our customers range from 2 guys in a garage to large multinational 
entertainment conglomerates.  My typical project last about 4 months, 
and in the past 4 years, I've built systems using Javascript, Common 
Lisp, Perl, Python, PHP, Objective-C, C, C++, Java, Forth, Postscript, 
Ruby, Smalltalk, Ocaml, SML NJ, Lua, and Haskell.  These applications 
have been running on everything from 100 node clusters to cellphones.

I've wanted to use Squeak on several occasions but ran into trouble 
quickly enough to have to switch gears.  This year's evaluation ran into 
some issues:

1.) Image stability issues (or why does my image keep curling up into 
fetal position and crying)

    * upgrading an individual package can break your image bad and in
      unpredictable ways
    * package dependencies are difficult to identify resolve before you
      install
    * base Squeak image is too big, and while the community provided
      images are great, it can be hard to determine what one "needs" vs.
      "nice to have"
    * staying current is too dangerous, but without an obvious release
      schedule / road map  it is difficult to know when to upgrade

2.) Documentation vs Reality (or what smalltalkers forgot to tell their 
children)

    * documentation within core classes often missing and occasionally
      out of date
    * while source is easily readable and understandable, much of the
      WHY is missing
    * getting non-smalltalkers into the smalltalk culture is hard
      without a historical perspective
    * breaking bad habits of gang of 4 "design patterns" programmers is
      nearly impossible

3.) Process & Threading & UI issues (or how squeak is slow & ugly)

    * it is way too easy to lockup the current scheduler & green threads
      implementation
    * UI responsiveness on a "fast" machine often leads to buggy
      clicking, typing issues
    * Fonts are incredibly fickle and obstinate :)

4.) Extending & Embedding (or how squeak doesn't play nice with others)

    * there are tons of 3rd party libraries squeak can't interface to
      (that _____ already does)
    * it is more difficult to maintain and build a custom VM, plugin,
      compared to other interpreted languages (as I've done with Perl,
      Python, Ruby, Lua, Javascript, and Java)
    * many platform features on Linux / BSD / Mac OS X are difficult to
      take advantage of without custom extensions
    * hard to talk to actual hardware within Squeak

But none of these things are really the issue that kept it out of the 
running as the choice of tool.  In fact these are all different problems 
from the prior years evaluations.

Assume for a second that I can convince a client that they don't need to 
worry about supporting the product, because that's the service I'm 
selling them.  My biggest hurdle to using Squeak in a production 
environment isn't image management (it is easily scriptable), and it 
isn't version control (MC is wonderful), and it isn't the development 
tools (hey they're the selling point).  My biggest problem isn't finding 
other programmers to train, or training them (I take it as a given that 
even experienced programmers need constant training). 

My biggest problem is that it is too complex, and too difficult to 
reduce that complexity without breaking things. 

When you build a project on top of Squeak, it is common practice to 
assume that Squeak is a layer of irreducible complexity, on top of which 
you are adding more complexity.  Design decisions within that body of 
code, determine the applicability of every design decision you make 
about your actual application.  And as soon as you are attempting to do 
something that is non-trivial for Squeak, you find yourself in a strange 
sea where dragons lurk behind every wave.

Part of this problem is a historical accident, the smalltalk community 
in general relies heavily upon a shared cultural memory, as images beget 
images and layers of cruft get lost among the cobwebs.  But a large part 
of this problem is a forgetfullness, where design decisions were made in 
a context, and as the context changed so too should have the design, but 
with the WHY lost, the change doesn't happen.  Squeak needs a continuous 
refactoring.  Odds are Alan Kay's goal of a 20k LOC system could be 
beaten easily by 10k if this were done.

A newcomer to Squeak looks at the incomprehensible class listings and 
asks herself "Do I really need this particular piece of junk", looks for 
an answer to "Why is this here", and is frustrated because often the 
answer to those questions has been forgotten (or is only held in someone 
else's head).  Upgrading feel like Russian roulette  because it is 
difficult to know how the changes will effect the system.  And  
experimentation  with making fundamental changes  is equally frustrating 
as  doing an engine change on car running down 101 during rush hour.  
 From this perspective and experience Craig Latta's Spoon is an easier 
sell than a full Squeak release.  The reason is simple, its a 
programmer's mantra: Less Code, Fewer Bugs, Lower cost.


Those are my 2 cents, lurking mode on.

Dave


-- 

David J. Goehrig


Phone: (716)-348-2984

Email: dave at nexttolast.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080407/1f078f3c/attachment.htm