Morphic, dataflow and encapsulation

Frank Speckmann f.speckmann at teamworks.de
Thu Jan 28 07:13:45 UTC 1999


hi!

i recently stumbled over something that might be of interest in this
context, though it is not directly adressing smalltalk or even squeak (yet).
here it is: http://www.vtt.fi/tte/papers/j-uml/
it is about a sort of middle tier between uml and java.
sounds like a nice idea...

cheerio!

Frank Speckmann

f.speckmann at teamworks.de




>No kidding!
>
>To look at graphical application development in a slightly different
>context, I long ago worked with the Helix database program for Mac. It was
>really easy to hook together a few tiles in the flowline-ish graphical
>working environment to do something really simple. The demos were great for
>that! The moment you needed a database of any complexity, however, you
>might as well forget about even a useful overall view. All you had was
>continuous screens packed with tiles that could tell you nothing about
>themselves unless you opened up their little windows.
>
>In Authorware, as well, the graphical flowline metaphor becomes a royal
>pain in the icon for the same reason. When all the details of your
>graphical objects can never be viewed, dumped, exported or previewed in any
>convenient way, the apparent convenience of the graphics can quickly become
>a millstone around your neck. There's nothing worse than having a
>substantial portion of the functioning of an application be buried in a
>million dialog box options instead of simultaneously accessible as readable
>text.
>
>I have somewhat less trouble with xcard systems simply because there is
>more tendency for them to be able to provide script lists conveniently when
>needed, especially if the bulk of the functioning of an application is in
>the scripts, not dialog box options.
>
>The most desirable system for really sophisticated program tasks *might*
>include a graphical optional view pictorially analogous to an outline mode
>or collapsible tree structure. But it seems to me it's always going to
>become essential at some point to print out the entire code, post it on a
>big wall, and be able to see everything from the topmost to bottommost
>aspect at the same time.
>
>David
>
>>My problem with graphical programming systems (and here I'm thinking about
>>a few
>>very different entities: Prograph is the extreme case, HyperCard and
Interface
>>Builder for Apple's Yellow Box are more typical ones) is their failure to
>>produce documentation for what's there or they hide what's going on by
>>requiring
>>many different windows to be open.
>>
>>There's no documentation feature which allows someone to tell the
>>application or
>>its UI (whatever you're working on) to document itself -- so you end up
>>hopping
>>>from place to place, reference to reference, striving to maintain
context.  I
>>HATE this.  With a passion.  Even Smalltalk can be a pain with three or
four
>>browsers open at a time while I try to figure out just WHAT object is
going to
>>respond to a message that has been sent.  I must be too old or something.
>>
>>One of the things that I liked best about the GUI Builder in
>>SmalltalkAgents was
>>that when it built a window it wrote the code for that window which I
>>could then
>>see and, if needed, edit.
>>
>>In InterfaceBuilder (in Apple's Yellow Box) you build an interface and
hook up
>>the feature -- but then result is all concealed in a NIB file which is a
black
>>box -- there's no way to tell IB to write out in human-readable form what
the
>>contents of that NIB file are.
>>
>>This inability to concisely document is, to me, the greatest weakness of
>>graphical tools.
>>
>>Thanks for listening -- pant pant pant....
>>
>>
>>Adam Bridge
>
>
>David Cramer, Process Innovation Evangelist          87-1313 Border Street
>PBSC Computer Training Centres                       Winnipeg MB R3H 0X4
>Corporate Office Research & Development              Canada
>
>





More information about the Squeak-dev mailing list