"Andreas Raab" <andreas.raab at gmx.de> wrote:
	Mind you - my frustration comes from the fact that so many people out there
	don't realize the HUGE potential that is behind these techniques. And your
	proposed way of doing things focuses at exactly the wrong issue - namely to
	throw out that part with the biggest potential for long term success. To
	repeat:
	
As a Squeak user, *my* frustration is that so many people don't realise
the HUGE difficulty of learning to use this stuff without anything
resembling adequate documentation.  (And no, stuff scattered all across
a Swiki really is not good enough.)

Heck, it was a couple of years before I discovered that the things
called "Viewers" were part of EToys.  Practically everything I know
how to do with a Viewer I learned from this mailing list, which says
good things about the mailing list but really bad things about documentation.

How about the fact that in Squeak 3.2 there was no class comment for Viewer?
In the Moprhic-Scripting category,
    YES BasicButton
    YES CategoryViewer
    NO  ClassRepresentativeMorph
    NO  ListViewLine
    NO  MethodMorph
    YES MethodWithInterface
    NO  ObjectRepresentativeMoprh
    YES PhraseWrapperMorph
    YES Player
    YES Presenter
    NO  ScriptActivationButton
    YES ScriptEditorMorph
    NO  ScriptEvaluatorMorph
    YES ScriptInstantiation
    NO  ScriptStatusControl
    NO  ScriptStatusLine
    YES ScriptableButton
    NO  ScriptingDomain
    YES SlotInformation
    YES StandardScriptingSystem
    NO  StandardViewer
    YES UniclassScript
    NO  UnscriptedCardPlayer
    YES UnscriptedPlayer
    YES UserScript
    NO  Viewer
That's 14*YES and 12*NO.  It's even worse when you realise how many
of the YES entries are only one sentence, and how few tell you when
or whether you want one and what you can do with it.  As for pointers
to user oriented documentation, forget it.

We can embed hypertext links in comments.  THAT could be a way for
people to actually find relevant Swiki pages.  Not done.

Maybe the first thing is a name change.  Instead of calling this stuff
EToys, how about calling it Morphic Scripting or Scripting By Manipulation
or something?  (Let's face it, if you go looking in a Browser, what you
need to look for is Morphic-Scripting, not EToys.)

In my view, if people who really understand this stuff put together
some serious documentation how it is supposed to be used (both via
the mouse and from code) and how it is put together, that would be
an excellent start on refactoring.  And even if the refactoring never
happened, we'd still have the documentation.

I am totally unimpressed by stories about wonderful things that children
have done in EToys.  The reason is that they had direct access to walking
breathing documentation.  They had someone who could SHOW THEM how to get
started.  I found the same thing in the Prolog world.  I learned Prolog
at Edinburgh from the people who built DEC-10 Prolog, and by reading and
debugging a lot of interesting code they had written.  Surprise, surprise:
I found Prolog dead simple.  People _outside_ the Prolog community kept on
and still keep on finding even the simplest things hard.  I've been on
this mailing list for a couple of years now, but I have never ever seen
Squeak driven by someone who really knows what he is doing.  So to me
it is perfectly true that

	> Hard things are DAMN NEAR IMPOSSIBLE in eToys.

In fact, practically _everything_ is hard for me in EToys, without the
kind of conceptual model _and_ details that a few days in the same lab
with Andreas Raab _or_ some good documentation could give me.