Morphic, dataflow and encapsulation

Bruce Cohen cohenb at gemstone.com
Mon Jan 25 20:08:16 UTC 1999


Hrefna "Gu•mundsdÛttir" <hrefnag at mmedia.is> wrote:
>> But a visual representation gives you the needed overview if the system 
>> large. You would make relatively low-level components by programming 
>> textually, but the wiring them together visually. To make this possible you 
>> have to have a good dataflow model. That's what I'm hoping to find in 
>> Fabric. I would say that all our programming efforts boil down to data 
>> manipulation so we need a direct way to visualize this, else we lose track 
>> of what we have accomplished or are trying to do when the system gets 
>> really large.

I don't entirely agree that "all our programming efforts boil down to data 
manipulation", since this ignores programming for embedded and other
systems whose job is to react to input stimuli with some action.  Yes,
you could couch this as data manipulation by saying the task is to
transform input data into output data, but I suspect that view is not a
very effective way to reason about reactive systems.

In general, I agree that a dataflow model of programming is very useful,
and a tool that presents it visually can be both useful and fun to use.
But I'd caution against thinking of it as a panacea for the problems of
developing complex or large-scale systems.  We have some experience with
visual programming tools here at GemStone; we shipped a commercial tool
called GeODE running in our Smalltalk VM for a number of years.  My own
experience with GeODE was very positive; it allowed me to build up some
useful tools, and to debug applications in fairly complex client-server
architectures. And I've no question that it was a godsend for many of
our customers (you should have heard the howls from them when the
product was discontinued), but by the end it had used up the efforts of
four engineers over 2-3 years, and it was still not a complete tool, but
more of an advanced prototype.  And in the process, we found we had to
provide nearly equal support for three different programming models: visual
dataflow graph wiring, textual event-script programming, and traditional
class-based Smalltalk programming, and these three models had to be
rather tightly integrated so you could build a complete application out
of pieces developed in any of the models.

>From what I've seen so far of Morphic (disclaimer: I've only spent a few
hours playing with it so far), it has potential to surpass GeODE in the
long term, but doing so will take considerable effort, because this is a
large problem domain.  Some of the things I think are very promisinmg
are:

    Explicit support of a generic scripting model

    Relatively easy ways to extend the Morphic tools

    Easy access to standard Smalltalk programming from the Morphic tools

    A good start at an integrated debugging environment
-----------------------------------------------------------------------------
Engineering is never having to say you're finished.
-----------------------------------------------------------------------------
Bruce Cohen,                               |  email: cohenb at gemstone.com
GemStone Systems, Inc.                     |  phone: (503)533-3602
20575 NW Von Neumann Drive                 |  fax:   (503)629-8556
Beaverton, OR USA 97006                    |  web:   http://www.gemstone.com





More information about the Squeak-dev mailing list