The Weekly Juan #4: "Smalltalk, Direct Manipulation and End User Programming"

Aaron Reichow revaaron at bitquabit.com
Wed Nov 15 03:09:37 UTC 2006


On Nov 13, 2006, at 9:02 PM, Juan Vuletich wrote:

> Hi Andreas,
>
> Andreas Raab escribió:
>> Juan Vuletich wrote:
>>> It seems I wasn't clear (again). It is not that I don't want to  
>>> discuss these items with you. What happens is that Andreas says  
>>> strong and polemic opnions. I actually started to write all the  
>>> things I don't agree with in that interview. But I don't think  
>>> that would be polite. Perhaps if Andreas asked for other's  
>>> opinions on his words...
>>
>> Sure, go for it ;-)
> For example, I don't agree at all with "Morphic is a wonderful  
> architecture as far as direct manipulation is involved but it's a  
> terrible architecture to build reusable systems. Morphic simply  
> doesn't have any abstractions and that makes it very hard to build  
> re-usable and flexible components."

First- does anyone else here agree with this view? If so, could they  
elaborate it?

Once I figured out how to use Morphic (maybe in an improper way! but  
it works for me!)- that is, how to code Morphic applications in a  
completely programmatic way, without using any direct manipulation  
and live instances hanging around, writing code I could file-out on  
the dev image, file in somewhere else and have it work- I can't say I  
ever felt this way about Morphic. Morphic doesn't have some kinds of  
abstractions, though I'm not sure which ones that matter it doesn't  
have.  I guess for certains kinds of morphs (text, buttons, lists) it  
would be good to have more standardization on them, more of a defined  
interface, but from my experience, things seem consistent enough that  
I've not been too confused.

All of my experience coding Morphic tells me just the opposite- not  
only is Morphic flexible, it's a lot more flexible than anything  
else. For instance, for my TaskbarMorph (on SqueakMap), I implemented  
a Morph called TaskbarClockMorph.  I just now, years after writing  
that code, was working on a new taskbar/dock morph for a landscape- 
oriented PDA (the Nokia 770). I reused that TaskbarClockMorph without  
any change in code.  I changed the font it used, but that was done  
through a line of code in my app, not by touching the  
TaskbarClockMorph's code.

I didn't do that by calling a #font: method on the TaskbarClockMorph,  
but I didn't see any need to implement such a thing.  Maybe that is  
the kind of abstraction missing in Morphic according to some folks.    
Rather, I just went to the TaskbarClockMorph instance, asked for the  
text submorph and set its font.  Unlike other widget sets, the new  
morphs I build are composed of other morphs, and it's easy to access  
those submorphs and do what I want to them. My experience on some  
other platforms is just the opposite- I am stuck with what the  
developer thought important enough to put it in the new widget's  
API.  If she thought that I woujldn't need to change the font, I was  
stuck.

What am I missing? To me, Morphic is about nothing if not flexible  
and reusable. A morph is a morph is a morph.  That said, I do think  
it can be hard to wrap one's head around the first time- but the  
payoff is worth the time invested.

Along these lines, I shall be sharing some screencasts soon of  
building simple Morphic apps. I did a simple tutorial over VNC with  
bmp on #squeak the other evening and it went really well.

Regards,
Aaron




More information about the Squeak-dev mailing list