On Tuesday, February 11, 2003, at 08:45  PM, Andreas Raab wrote:

> Daniel,
>
>> we could use this kind of
>> refactoring to separate the "Morphic" programmers use to build boring
>> old applications, from the "Morphic" that's perfect for eToys.
>
> Nothing personal, but as of now, this is the most frustating message I 
> have
> seen in this thread. Don't you realize that the Morphic that is 
> perfect for
> eToys *is* the one that is perfect for programmers?

I'm willing to be convinced - but I'm not sold.  It seems very buggy 
and fragile when working with it.  I can usually get something *sort 
of* like what I want - but its never quite solid.

> I'll give you just one example: If I want to make a button in eToys, 
> here is
> what I do. I go to the supplies flap, grab a rectangle...

[snip].

Uh huh.  Why don't you grab a button object instead?  Is it because 
there isn't one ready to go?  As I work through morphic more and more 
I'm impressed with the wide range of base capabilities - and yet I 
can't help get the feeling that *any* morph could be a floor polish and 
a dessert topping at the same time.

> If I want to make the same button using your "programmer's morphic" 
> here is
> what I needed to do: Go to the tools flap, open a browser, make a 
> category....

You shouldn't have to do that either.  Something along the lines of

Button new label: 'OK'; color: aColor; pressedColor: 'anotherColor'; 
onMouseUpDo: [:sender | receiver okClicked ].

> So which way would you rather use yourself?!

Personally I prefer typing to direct manipulation - I also prefer to 
move files using bash rather than the Mac Finder and I prefer books to 
television so I'm probably not normal, but you asked. :-)

Anyhow, your examples up above just point out that the lack of a decent 
set of ready to go morphs is the real reason why bugs get introduced so 
rapidly. If you want to keep people from writing bad code, write it for 
them and make it so they can use it.

Todd Blanchard