Morphic, dataflow and encapsulation

Joseph Whitesell whitesell at physsoft.com
Mon Jan 25 21:15:34 UTC 1999


You might also peruse the "Is building software with highly visual
development tools any easier or just confusing?"  thread on
comp.lang.smalltalk.  A good spot to look at is Mike Silverstein's 12/04/98
post. I hope he doesn't mind if I quote him here:

"...I agree completely. We have found that visual programming with
connections works
well as long as you limit their use to defining simple notification and
dependency
relationships. As a general rule of thumb, you have gone too far with VA
connections if their usage starts to smell like logic, firing order starts
to
really matter, or you intend to use inheritance for adding or altering
relationships."

Joe Whitesell

----
I'd be interested in hearing the evidence supporting the case for visual
programming representations. I agree with Ralph that the burden of proof is
on the proponents, but of the evidence that I've read, it seems to me that a
stronger statement can be made: That visual programming is as hard or harder
than textual programming.

------
<references annotation=true>
First, there's the work by Marion Petre (replicated by Tom Moher) that shows
that even "experts" at visual programming environments are actually much
better at textual programming languages:

Petre, M., & Green, T. R. G. (1990, ). Where to draw the line with text:
Some claims by logic designers about graphics in notation. Paper presented
at the INTERACT'90, Cambridge, England, 27-31 August.
Moher, T. G., Mak, D. C., Blumenthal, B., & Leventhal, L. M. (1993).
Comparing the comprehensibility of textual and graphical programs: The case
for Petri Nets. In C. R. Cook, J. C. Scholtz, & J. C. Spohrer (Eds.),
Empirical Studies of Programmers: Fifth Workshop . Norwood, NJ: Ablex.

She has gone on to do a nice analysis suggesting that visual forms are just
as hard to deal with as textual forms.

Petre, M., & Green, T. R. G. (1993). Learning to read graphics: Some
evidence that 'seeing' an information display is an acquired skill. Journal
of Visual Languages and Computing, 4, 55-70.

There's the more recent work on KidSim/Cocoa which showed that students have
all the same problems programming in textual forms as they do in visual
rules. (Clayton Lewis at CHI96 or CHI7 -- I don't have the reference here.)

Finally, there's all the work on algorithm animations which, thus far, has
not shown any learning benefits.

Stasko, J. T., Badre, A., & Lewis, C. (1993). Do algorithm animations assist
learning? An empirical study and analysis, Proceedings of INTERCHI'93 (pp.
61-66). Amsterdam, The Netherlands: ACM.
</references)
------------

Does anyone know of any evidence that supports the benefit of visual
representations for programs? I'm not saying that there are no benefits of
visual representations. The challenge is figuring out what those benefits
are.

Mark

At 2:20 PM -0600 1/25/99, Ralph E. Johnson wrote:
>At 3:56 AM 1/25/99, Hrefna "Gu•mundsdÛ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.





More information about the Squeak-dev mailing list