<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Andreas Wacknitz wrote:<br>
<blockquote cite="mid:044A6024-374D-431F-AF3E-D5B91DF88D70@gmx.de"
type="cite">And many of the newcomers get alienated by many aspects of
Squeak:
<br>
- it is hard to find documentation
<br>
- it is hard to get used to Morphic (its power isn't obvious but
its clutter is)
<br>
- it is hard to find a Squeak version with not so many obvious bugs
and problems
<br>
</blockquote>
Long time lurker here,<br>
<br>
Short answer: (For those who don't want to read the post)<br>
<br>
Newcomers are turned off by seemingly irreducible complexity of the
system; Squeak need continual refactoring.<br>
<br>
Long answer:<br>
<br>
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.<br>
<br>
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:<br>
<br>
1.) Image stability issues (or why does my image keep curling up into
fetal position and crying)<br>
<ul>
<li>upgrading an individual package can break your image bad and in
unpredictable ways <br>
</li>
<li>package dependencies are difficult to identify resolve before you
install</li>
<li>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"</li>
<li>staying current is too dangerous, but without an obvious release
schedule / road map it is difficult to know when to upgrade<br>
</li>
</ul>
2.) Documentation vs Reality (or what smalltalkers forgot to tell their
children)<br>
<ul>
<li>documentation within core classes often missing and occasionally
out of date</li>
<li>while source is easily readable and understandable, much of the
WHY is missing <br>
</li>
<li>getting non-smalltalkers into the smalltalk culture is hard
without a historical perspective</li>
<li>breaking bad habits of gang of 4 "design patterns" programmers is
nearly impossible</li>
</ul>
3.) Process & Threading & UI issues (or how squeak is slow
& ugly)<br>
<ul>
<li>it is way too easy to lockup the current scheduler & green
threads implementation</li>
<li>UI responsiveness on a "fast" machine often leads to buggy
clicking, typing issues<br>
</li>
<li>Fonts are incredibly fickle and obstinate :)</li>
</ul>
4.) Extending & Embedding (or how squeak doesn't play nice with
others)<br>
<ul>
<li>there are tons of 3rd party libraries squeak can't interface to
(that _____ already does)</li>
<li>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)<br>
</li>
<li>many platform features on Linux / BSD / Mac OS X are difficult to
take advantage of without custom extensions</li>
<li>hard to talk to actual hardware within Squeak<br>
</li>
</ul>
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.<br>
<br>
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). <br>
<br>
My biggest problem is that it is too complex, and too difficult to
reduce that complexity without breaking things. <br>
<br>
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.<br>
<br>
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.<br>
<br>
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. <br>
<br>
<br>
Those are my 2 cents, lurking mode on.<br>
<br>
Dave<br>
<br>
<br>
<div class="moz-signature">-- <br>
<meta http-equiv="Content-Type" content="text/html; ">
<meta http-equiv="Content-Style-Type" content="text/css">
<title></title>
<meta name="Generator" content="Cocoa HTML Writer">
<meta name="CocoaVersion" content="949.27">
<style type="text/css">
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica}
p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px}
</style>
<p class="p1">David J. Goehrig</p>
<p class="p2"><br>
</p>
<p class="p1">Phone: (716)-348-2984</p>
<p class="p1">Email: <a class="moz-txt-link-abbreviated" href="mailto:dave@nexttolast.com">dave@nexttolast.com</a></p>
</div>
</body>
</html>