At 3:56 AM 1/25/99, Hrefna "GumundsdÛttir" wrote:
On Saturday, January 23, 1999 6:56 PM, Andrew C. Greenberg
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?
You have it backward. People have been saying for decades that visual representations for programs are essential. The proponents of VPLs and CASE tools make similar arguments. UML is the latest example. However, there is NOT ONE EXAMPLE of a system that delivers on its promises. Very specialized systems like Stella or GUI builders are certainly useful, and general purpose systems like LabView are good for non programmers. AVL is a nice system, but it has problems, and I bet I could make a better system in Smalltalk that was text-based. Andy's point was that, as a programmer, he had yet to find a system that was as fast and powerful for him as textual programming.
I've used VisualAge, for example. It is cute, and great for little demos. It probably helps people get started with Smalltalk. But we found that for big projects, it just gets in the way, and the one large VisualAge project that I am working with has pretty much abandoned the visual builder.
This does NOT mean that it is impossible to make a great visual representation of programs. It just means that it is hard, and people have a right to be skeptical. The arguments in favor of graphics are very logical, but experience indicates that there is something wrong with the conclusion. The burden of proof is on the proponents.
-Ralph
Andy's point was that, as a programmer, he had yet to find a system that was as fast and powerful for him as textual programming.
In my limited experience of using "bubble and line" kinds of tools, it seems to me the problem is not so much in the presentation but in the interaction. It's faster for me to grep through text to find the structure that I want than it is to search or otherwise manipulate either "structured text" or "structured graphics". Grep is a simple, fast tool for plowing through reams of information. My brain is a simple tool (and mine is *especially* simple!) for discerning patterns from the simple filtering that grp provides for me.
The problem with "bubble and line" tools is that they rarely *interact* the way I want them too. If I can figure out how to get them to present what I want, the presentation is typically acceptable.
The other problem is that bubbles and lines take up a lot more space than text (in English, anyway). I have in the past participated in some pretty weird and wacky sessions imagining an infinite 3D space that provides instant access to any and all information. Why do I want to hide information behind buffers in Emacs or the RFB, e.g.? You should see my desk. My information is arranged in 3D with more important information closer at hand.
I have an example of such a system, but only 4 people understand it :-)
When I develop applications, I am fortunate enough to have a choice to use a visual component representation of things or to write code. I am easily 10 times as productive when I do this. We have a visual report generator that is like a lambda calculus, but there are parts of the system where it is not supported.
Like GeODE, it is GemStone-based, but it is much higher-level. I never really used GeODE, but my impression was that it was a way to do GemStone programming without using a third-party Smalltalk client. I do recall that there was a frame system built into it, but it did not seem to be fundamental to the system.
I agree that it is not easier to use a tool like this. But once it is wired into your brain, you can just think about what you want the system to do, and skip the translation into code. It may just be that such a calculus is a higher order way of doing things than jamming code into browsers, and a textual version of it would probably be faster yet than dragging objects around. I am not sure if it is computationally complete, because you can always tweak it if you need to.
It may not fit a "pure" definition of what a visual programming tool needs to be. After all, Smalltalk is pretty visual, even in its code browsers. I agree that icons without text are pretty useless, but to expect everyone in the world to program using a keyboard makes about as much sense as expecting everybody to switch their calls using a 1930's-era telephone switchboard. Could you make a better text-based system in Smalltalk that used a DOS prompt for a user interface?
Steve
-----Original Message----- From: Ralph E. Johnson [mailto:johnson@cs.uiuc.edu] Sent: January 25, 1999 12:20 PM
You have it backward. People have been saying for decades that visual representations for programs are essential. The proponents of VPLs and CASE tools make similar arguments. UML is the latest example. However, there is NOT ONE EXAMPLE of a system that delivers on its promises. Very specialized systems like Stella or GUI builders are certainly useful, and general purpose systems like LabView are good for non programmers. AVL is a nice system, but it has problems, and I bet I could make a better system in Smalltalk that was text-based. Andy's point was that, as a programmer, he had yet to find a system that was as fast and powerful for him as textual programming. bandoned the visual builder.
This does NOT mean that it is impossible to make a great visual representation of programs. It just means that it is hard, and people have a right to be skeptical. The arguments in favor of graphics are very logical, but experience indicates that there is something wrong with the conclusion. The burden of proof is on the proponents.
-Ralph
squeak-dev@lists.squeakfoundation.org
-
johnson＠cs.uiuc.edu -
Mark Guzdial -
Patrick Logan -
Steve Wart