On Wednesday 12 February 2003 05:24 pm, Richard A. O'Keefe wrote:

> I don't think it's a pink-plane vs blue-plane thing at all.
> To pervert the metaphor, it doesn't matter what colour the
> plane is IF YOU CAN'T BOARD IT.

I agree.

> If I've understood Andreas Raab correctly, he is firmly of the
> opinion that EToys is not a rival to a solid framework for building
> business applications but, amongst other things, a first draft of
> just such a framework, that if you want to build a standard
> business application, EToys should be a much faster way to do it.

I'd disagree with this. I don't think that (currently) eToys has a 
rich enough vocabulary or model to make the kinds of apps that most 
people want to make. Some of its limitations:

* no parameters to scripts
* events are not extensible
* collections are limited to Morphic containers of other Morphs, and 
the cursor is shared (I think)
* extending vocabularies requires adding more methods in Player
* no way to get the name of a newly-instantiated object to send it 
messages
* "standard" widgets don't have enough eToy support (try making a list 
of anything in a ListMorph)
etc...

> The way I see it, it's an insider vs outsider thing.
>
> If you are a Morphic/EToys insider, then you *can* do amazing
> things and you *can* build business applications that might not be
> "standard" (unless you really want them to), but *would* be usable
> and a pleasure to use, and you think it's all plain sailing and fun
> doing so.

I haven't yet seen anything I'd consider a "business application" 
built with eToys. Active Essays are a fine idea, but don't begin to 
reach the scope of what people want to do.

I've had to spend more time reading code, instrumenting code and 
tracing with a debugger than I would have liked to get things done 
with Morphic.

> I am still puzzled about what GeeMail thingies are all about; they
> seem to have nothing to do with mail, g forces, or the gee-gees. 

[snip]

> While the GeeMailMorph class comment is only _just_ helpful, it is
> also the only class in the Morphic-GeeMail category with _any_
> useful class comment (the one other class that has a class comment
> basically says not to use it).

They have the feel of something that was done to support a particular 
project or style of working, and was never later cleaned up or 
documented.

If you look at SqueakNews, you'll see that Tansel modified the 
GeeMailMorph to generate triggers at different scrolling points. A 
great idea, and one that should have made it back into the image.

Along with more documentation.

> *THIS* is the single biggest problem with Morphic and EToys: the
> steep learning curve brought about by the truly dreadful state of
> documentation.

 [snip]

> But here I am, an enthusiastic
> Smalltalker, a technophile, keen to play with things and to learn
> new ways to do things, and very admiring of Morphic results that I
> have seen.  And I am just so FRUSTRATED.

I understand your frustration.

> If only there was something like Brent Welch's Tcl/Tk book for
> Squeak, *assuming* a basic knowledge of Smalltalk syntax and
> Collection classes, explaining Morphic, EToys, Tiles...  A good
> How-To book with *all* the information you need, right there in one
> place.  Something you can actually get up to speed with, without
> having a veteran insider as your teacher.

I think some have been afraid to write such a book because of the rate 
of change in Squeak. When Squeak was being banged on heavily by 
Squeak Central, we would see changes added to the update stream that 
would appear "out of the blue". The rate of change in the distributed 
image has been pretty high in the past.

I think part of the problem now is one of ownership. As we transition 
to the new model -- a model in which more and more of the image we 
know now gets separated into loadable packages -- I think it's going 
to be extremely important to get people responsible for each package. 
Once there's someone to point to, and an identifiable artifact, I 
think it's easier to get documentation done.

In this case, the whole Active Book part of the image should probably 
become a separate package. If it's important to people, perhaps we 
can get volunteers to maintain and document it. If it's not 
important, it will suffer code rot as the rest of Squeak changes 
around it. Which happens now in the monolithic image, of course; it's 
just that it'll be more visible when we can see the bounds of the 
packages.

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE