Hm.  I've been watching the discussion about a new Morphic for some days 
now, and being that I am a lurker here I feel a bit uncomfortable stepping 
in too loudly, but I do have an opinion, so here goes.  For what it's 
worth, if enough people agree with my idea for how things "should be" I'd 
be willing to try to scratch together a NewMorphic framework for y'all to 
pick apart.

Being a vetran of Character mode UI, Curses, Windows, Gem, X, DHTML, VRML, 
Java, VB, Delphi, MVC and probably others that I don't even remember, I 
feel at least a little qualified to spout on about how the world "should 
be" once I am voted in as King.  Until then, ...

On Mon, 10 Feb 2003 13:16:04 +0100, Andreas Raab <andreas.raab at gmx.de> 
wrote:

>> > I'm wondering why andreas does not tell us his point of > view on 
>> that.
>>
>> yes, please.  :)
>
> Simple. I think that all'y'all (thanks Jeff!) are barking up the wrong 
> tree.
> Look at eToys. Kids in fifth grade are able to master them even though
> players have 500 methods IN ADDITION TO those in Morph and Object and the
> kids are essentially dealing with all of them. Given this, isn't it time 
> for
> y'all to admit that you're more like these kids in fifth grade then one
> might think?! ;-)

hrm.  I've only played with eToys for a few minutes, by myself, with no 
clear idea of what I was looking at, and I very clearly didn't master them. 
 On the other hand, the first time I played with Visual Basic or Delphi for 
a few minutes it was clear to me what I was doing and how I should go about 
making it do what I wanted.  Now, VB and Delphi had (and to some extent 
still have) other limitations, which have always stopped or annoyed me, but 
the concepts have been easier for me.  Can anyone suggest why this is?

>
> Or, put differently: The problem is not "cruft in Morphic", it isn't
> "uglyness". That's an overly simplified point of view on the problem 
> since
> it didn't start out that way. It ended up there because of the way it was
> exposed to all'y'all kiddies (including myself) not being able to protect
> its own critical notions in any way.

Well, as I see it it is because the Morphic classes are not as reusable as 
one might like.  Instead of reuse-through-creating-another-instance, one 
must always reuse-through-creating-a-single-instance-of-a-subclass, which 
is probably okay, but it ends up exposing more of the internals of Morphic 
or whatever I'm subclassing than I need to see, or should even want to see. 
 (Does anyone else agree with this statement?)

>
> To me, this is the logical result of many of the shortcomings of 
> Smalltalk.
> For example, subclassing for using the framework. When we subclass a
> framework class like Morph in Smalltalk we do not *use* that class but
> rather we *modifiy* it. We are able to access unprotected instance state
> (look at the ridiculous comment in Morph>>bounds) we are able to override
> system critical methods in incompatible ways. Even the tutorials (like 
> the
> one up at Squeak.org) teach you that it's okay to break the framework in
> order to use it (in this concrete example, it lacks calls to any of the
> "super" methods even though this is required by the framework).

Well, how often does anyone need to subclass something in Collection in 
order to build a simple application?  One of Larry Wall's PERL mottos is to 
make the simple things simple and the hard things possible.  It always 
seems like Morphic is making the simple things complicated and the hard 
things about the same.  (Does anyone else agree with this statement?)

>
> Given this, any attempt to "clean up" Morphic is doomed to fail if it 
> does
> not address the "usability issues" for the programmer. The best you can 
> hope
> for is a temporary effect but any newbie can (and therefore will!) write
> code that breaks the framework. Some of this code will either be cool or
> needed enough so that someone else is going to use it and you'll end up
> exactly where we are right now.

Well, sure, if the framework encourages everyone to twiddle with the 
insides of it in order to get anything done, then everyone will twiddle 
with it before they really understand the larger picture.  I would suggest 
that the model that Delphi has is a bit closer to what we need in order to 
avoid this future.

For those of you who have not used Delphi, there is a large (and constantly 
getting larger) collection of pre-designed widgets (they call them 
components) that can be just added to a project.  Most simple UIs can be 
built just using a variety of the existing components.  For special needs, 
say I want a widget to animate in a way that no existing one supports, it 
is easy to subclass an existing widget and extend it.  But for the most 
part that is an advanced behaviour.  Normal component behavior is modified 
by callbacks, which in Delphi are done as pointers to members of Object 
Pascal types.

It seems to me that closures are the perfect way to do this in Smalltalk, 
but the little bit of playing that I've done with them suggests that they 
don't work quite right by default.  Also, there have been a bunch of 
messages (that I didn't quite follow) about closures on this list.  Is this 
a subject that is going to get more or less straghtened out any time soon?  
(That is probably a side issue to Morphic, but one that I am curious about 
nonetheless.)

>
> Documentation, tests, etc. will (while being useful) not solve this 
> problem.
> After all, we *want* people to play with this stuff, don't we? And if we
> want people to play with it then it should be easy to use in "the right
> way".

If the framework is designed to be too malleable, then the work required 
for documenting its current state will be considerable.  Instead, if the 
framework itself is rigid, then the documentation at least can catch up to 
the core parts.  The issue, as I see it, is to balance those two needs, 
while providing something that is fun to play with.  Fun is important, too. 
 IMHO, instantiating a component and setting its callbacks with impunity is 
more fun than subclassing a component and then fighting with it for a 
couple of hours to realize that I forgot to initialize the base class 
completely.

>
> eToys do exactly this. They provide an environment which is extremely
> convenient for the kids to use and boy, many a time I have wished that
> Squeak would be more like eToys. Bridging this gap, making the "system
> level" part of Squeak more like eToys is the thing that needs to be done. 
> In
> particular in the UI area since that's what most people will look at and
> play with first, so it's the place where strong fences are most needed
> (present in eToys). Pretty much everything else will come naturally. Of
> course, such an environment would no longer be "Smalltalk" - but in order 
> to
> protect the critical system notions we simply HAVE to get rid of it or at
> least some of its intrinsically dangerous notions when it comes to an 
> open,
> easily usable, and still robust environment.

Hrm.  It sounds like you want something like the "private:" operator in 
C++.  Or maybe you want a commercial Smalltalk where the sources are 
available to someone other than you.  Me, I like the idea that I control 
the vertical and I control the horizontal.  I can dig down into the sources 
to the point that I have forgotten the question that I started out asking.  
On the other hand, I also like the idea that with ten clicks in Delphi I 
can build a UI for my little program, and I can't figure out where that 
functionality lives in Morph, or where it would even belong.  In this 
regard, Morph is a wonderful place for making new Morphs, but a terrible 
place for making UIs.  (Has anyone else noticed that nearly all the morphs 
that you interact with on a regular basis are PluggableListMorphs?  Does 
that not seem a bit unfair to all the other lonely little Morphs that 
nobody pays any attention to?)

>
> Bottom line of this: Morphic is cool. Neither the designers nor the users
> are to blame for where it ended up in Squeak. Squeak (Smalltalk) itself 
> is -
> by not providing any means to build the right "fences" into the 
> framework.
> So my essential feeling here is: If you want to fix Morphic, then fix
> Smalltalk. Morphic is simply a place where it shows many of its intrinsic
> shortcomings for all'y'all kiddies.

Boy, I don't know about that.  I seem to think that whatever language you 
are using, it is possible to end up with a big ball of mud, once enough 
different people touch the same bits.  Too many people with different 
agendas are each being afforded too much control over the details.  Sort of 
like the tax code here in the U.S., as I think about it.  The fact that it 
is somewhat possible to build a reasonably clean class library in C++ (I'm 
thinking of QT here, your opinion may vary) means that we should hesitate 
to point fingers at the language.

>
> Cheers,
> - Andreas
>
>

Well, I've said a lot, asked some questions, and probably made a fool of 
myself out loud.  Does anyone else share my grand vision of a UI framework 
that while being easy to extend, does not require that I do that in order 
to just make a simple UI (or even not so simple UI) for my application?  
MVC was too 'invasive' of the logic portion of the app, IMHO, while Morphic 
requires that too much knowledge of the logic get intertwingled with the 
display portion.

-- 
andrew_c_berg at yahoo.com