On Saturday, January 23, 1999 6:56 PM, Andrew C. Greenberg 
[SMTP:werdna at gate.net] 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.
>
> Is this really true for "really large" systems?  My experience with
> so-called graphic or visual programs is almost exactly the opposite -- 
they
> make short work (with some costs) for putting programs "in-the-small"
> together, but as you grow the world, direct manipulation becomes a 
painful
> burden and What-You-See-Is-All-You-Get seems to take over.

I take it that you are referring to Visual Programming Languages (VPL). 
That's not what I had in mind. VPLs do have scaling problems in some 
current implementations, but I was thinking about visual data manipulation, 
i.e. visually manipulating the flow of data between components. It could be 
argued that this approach has the same scaling problems as the VPLs but I 
firmly believe that it is possible to represent the information in a useful 
and productive manner, both for small and large systems. Some of the 
problems VPLs have had is the lack of screen real estate, clear 
representation of logic and how to document the code. I feel that VPLs are 
taking the visual representation to a too low a level. Textual programming 
is fine for low level components but when it comes to assembling them 
together (perhaps into larger components), I would think that a visual 
approach would be of great help.

>
> I am reminded of early implementations of the game, Empire.  This is a
> wonderful, visual world with lovely tactical displays early on.  As the
> "empire" becomes more complex, however, playing the game at a tactical
> level becomes onerous and coneptually unmanageable.  Of course, shifting 
to
> strategical views is a valid game-design solution to keep games fun, but
> what when the TACTICS are important to the overall product, as in a
> computer program.
>
> On the other hand, I have always had confidence that I can easily 
automate
> programming processes as systems grow, when the programs are text-based.

Could you do this 'easily'?

>
> I'd be pleased to be educated to the contrary, but it seems to me that
> Jen's suggestion that graphics are always better for "really large"
> programs, indeed, even "always good" for large programs need not always 
be
> the case.

It may a bit 'strong' to say that graphics are 'always good', but can you 
point out an area where this does not hold?

>
> What is beautiful about text is that it can embody an amazing amount of
> semantic information in a concise fashion.  I hated losing that as we 
moved
> toward early GUI OS systems, and have been gratified as scripting GUIs
> became recognized as critically important to their utility.  The hybrid
> approach (scripting atop graphic-representations atop 
meat-and-potato-code)
> seems to me in many ways more flexible than the "graphics" v. "text"
> ideological debate.

I partly agree. Much of the semantic information would be in the components 
(which could be programmed textually). You just need to know what a 
component needs for input to produce your desired output. You really don't 
need to know how it does it. What I feel is missing in the current hybrid 
approach is a clear way of showing _how_ the information flows. It's not 
easy to get this knowledge by looking at a (long, perhaps complex) script. 
If you had a visual representation of this you would just have to glance at 
it and you would know what kind of information is flowing where.