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@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
squeak-dev@lists.squeakfoundation.org