/header.html HyperNews Home
Using HyperNews (Instructions)

Visual Languages

[This was originally created from the comp.lang.visual FAQ by David McIntyre (mcintyre@is.morgan.com). It is gradually drifting away from the FAQ format.]

A visual language manipulates visual information or supports visual interaction, or allows programming with visual expressions. The latter is taken to be the definition of a visual programming language. [Golin90b]

General
Miscellaneous
- VP paper classification project.
- Call-for-papers, special issue of IEEE Computer.
- The Deutsch Limit
- Toolkits - Commercially available toolkits to help in VL design.
Acknowledgements

What is a Visual Programming Language?

A few representative answers:

Visual Programming (VP) refers to any system that allows the user to specify a program in two-(or more)-dimensionsional fashion. [...] conventional textual languages are not considered two dimensional since the compilers or interpreters process them as long, one-dimensional streams. [Myers90a]
A visual Language manipulates visual information or supports visual interaction, or allows programming with visual expressions. The latter is taken to be the definition of a visual programming language. Visual programming languages may be further classified according to the type and extent of visual expression used, into icon-based languages, form-based languages and diagram languages. Visual programming environments provide graphical or iconic elements which can be manipulated by the user in an interactive way according to some specific spatial grammar for program construction. [Golin90b]
Visually transformed languages are inherently non-visual languages but have superimposed visual representations. Naturally visual languages have an inherent visual expression for which there is no obvious textual equivalent. [Burnett89]
Visual programming is commonly defined as the use of visual expressions (such as graphics, drawings, animation or icons) in the process of programming. These visual expressions may be used in programming environments as graphical interfaces for textual programming languages; they may be used to form the syntax of new visual programming languages leading to new paradigms such as programming by demonstration; or they may be used in graphical presentations of the behavior or structure of a program. [McIntyre&Burnett]
A visual language is a set of spatial arrangements of text-graphic symbols with a semantic interpretation that is used in carrying out communication actions in the world.

Do we need the word "programming" in that phrase?

Perhaps not. People like to point out languages such as Miro and GIL which are visual specification languages as reasons for saying visual language instead of visual programming language. I think of Miro as a language for programming specifications, so I like the word.

We'll try to avoid using the word "programming" when we don't mean to exclude non-programming visual languages.

Any comments?

[Fred Lakin says: ] Sure. The short answer is, it reminds us of all the other visual languages there are, which should be looked at and learned from. Keeping the word "programming" in the phrase keeps the computer folk from becoming visually provincial, which I see as a real danger.

The longer answer is, people have invented and used many visual languages in the course of history. A fraction of those have anything to do with computers, and an even smaller number represent programs, and an even smaller number of those represent programs and can be executed on a computer. Let's say people have been using visual languages for 10,000 years; and using them for communication *about* computers for 50, and using them for communication *with* computers for 30. So you can see how small a percentage of the total numbers of visual languages we are talking about.

Is there a better phrase (than VPL) that we could use?

[Respond with your ideas!!!!]

[Fred Lakin's idea:]

I prefer the term "executable graphics" instead of visual programming languages.

Visual programming language is a misnomer. It either means a programming language which we can see, which is trivial, or a language used for programming the behavior of visual things, which is limiting.

Executable Graphics expresses a different orientation toward the problem domain: graphics which can be executed. [Lakin86]

[Paul Lyons sez:]

I've coined the term "Hyperprogramming" which I think better summarises the capabilities and support provided by visual Programming Languages. We argue for VPLs on practical as well as theoretical basis. The theoretical arguments relate to the greater expressivity and intuitiveness of diagrammatic representations of complex relationships. The practical arguments relate to the availability of sufficient computing power to support the capture and processing of visually expressed diagrams. Specifically, we utilise:

processor speed, to let us do it in real time
high-res graphics, to represent complex diagrammatic notations
mouse input, to create complex diagrammatic notations and
window-based displays, to partition the resulting diagrams into a manageable size.

It's this last point that's the important one. Partitioning big programs to make them more manageable is great, but creates navigational difficulties. These sort of navigational problems have been addressed, for "ordinary" documents, by hypertext systems. Now, "ordinary" hypertext documents are tedious to create because adding all the hyperlinks takes a long time, but there's no such problem with programs, because it's easy for the entry support system to generate the hyperlinks automatically, on-the-fly. As well as providing programmers with simple and consistent navigation techniques, the hyperlinks can be used to automatically update shared information between views.

So I think that VPLs, if they aren't already, will achieve partitioing based on multiple windows, with hyperlinks between the windows connecting shared items of information. Calling them Hyperprogramming languages will reflect this situation, and might reduce the subtle suggestion (inherent in the name VISUAL programming languages) that these languages should eschew text entirely.

Doesn't everyone agree that VL is great?

Heck, no! In fact, some pretty well-respected people have nothing but contempt for the visual representation of software. In a very famous article [Brooks87] Fred Brooks says this:

A favorite subject for PhD dissertations in software engineering is graphical, or visual, programming - the application of computer graphics to software design.... Nothing even convincing, much less exciting, has yet emerged from such efforts. I am persuaded that nothing will.

Of course, Brooks' arguments contain several weaknesses:

He focuses on flowchart-based control-flow diagrams.
He is worried about screen size in pixels. Phil Cox has presented a strong argument why this may not be meaningful.
I think he misunderstands the power of multiple views - not superimposed views.

Another anti-vl quote:

...beware the claims of visual programming. Drawing lines between objects becomes bafflingly web-like. Purely visual programming is not yet and may never be viable. [OBrien93]

What is comp.lang.visual?

comp.lang.visual is a forum for discussing Visual Programming Languages: their problems, their advantages, and ideas for making them better.

Visual language discussion can also include aspects of many other topics, eg, visualization of programs and/or data, human-computer interaction and interfaces, formal languages.

What about Visual Basic and Visual C++?

Visual Basic and the entire Microsoft Visual (tm) family are not, despite their names, visual programming languages. They are textual languages which use a graphical gui builder to make programming decent interfaces easier on the programmer.

Because many Visual BASIC users have many questions, and frequently post them to the comp.lang.visual newsgroup, we list some alternate resources:

comp.lang.basic.visual
VB Online is a bulletin board dedicated to Visual Basic users. It can be accessed via. 1-216-694-5734 at 9600 baud. [haston@utkvx.utk.edu (Haston, Donald Wayne)]
comp.os.ms-windows.programmer.tools, comp.os.ms-windows.programmer.misc, comp.os.ms-windows.apps, comp.os.ms-windows.misc

How do you talk about Visual Programming Languages in an ASCII medium (i.e., USENET)?

Good question. Debate over this one continues. Some people on comp.lang.visual suggest that it can be done, citing film criticism as a textual medium talking about a decidedly non-textual medium. Others say that, sure, you can criticize a released film, but how can you talk about a film no one has seen (and by extension, a VPL no one has made programs with)?

Brook Conner (dbc@cs.brown.edu) tends to go with the first team (that meaningful discussion can take place). Textual criticism will not replace actual experience. However, it can still be valuable. After all, text is fundamentally a form of communication, just like movies, animation, hypermedia, and that old standby, speech. The fact that there are some things text does not do well is probably why many of us are interested in VPLs in the first place, but I don't think anyone on this group would say "Text is useless."

VP paper classification project.

We have developed a classification scheme for classifying visual programming language research papers. As part of this work, we compiled a bibliography of papers classified by their _original authors_ according to this scheme.

If there are research papers you've written that you'd like to have added to the bibliography, pick up a copy of the report and send us a list of your papers classified according to the classification scheme described in the report. We'll update the bibliography from time to time. Please include the phrase VPLclassification in your email header.

Margaret Burnett
Oregon State University
burnett@cs.orst.edu

Call for papers, special issue of IEEE Computer.

IEEE Computer Special Issue on Visual Programming Visual Programming has been selected as the theme of the March, 1995 issue of Computer. Visual programming is commonly defined as the use of visual expressions (such as graphics, drawings, animation or icons) as the means by which programs are created and modified. These visual expressions may be used to form the syntax of new visual programming languages, sometimes leading to new paradigms such as programming by demonstration, or they may be used in visual programming environments for textual programming languages.

The objectives of this issue will be to present the current state-of-the-art as well as directions for the future of visual programming languages and environments. Topics of interest include, but are not limited to, visual programming language design issues, visual environments for programming and design, innovative and emerging approaches to visual programming, and tutorials or insightful surveys of current research. Manuscripts in these and other related areas are sought immediately.

The deadlines for paper submission are long gone. However, for any information you need feel free to contact the guest editors:

Margaret Burnett                 David W. McIntyre
Dept. of Computer Science        Morgan Stanley
Oregon State University          1633 Broadway, 35th Floor
Corvallis, OR 97331--3203        New York, NY 10019
503--737--2539                   212-703-2753
fax: 503--737--3014              fax: 212-703-2054
email: burnett@cs.orst.edu       email: mcintyre@is.morgan.com

In addition to manuscripts, entries about commercial visual programming products for the Products Reviews and New Products departments are encouraged. Send review submissions to the Product Reviews Editor, J. M. Jagadeesh, College of Pharmacy, 500 W. 12th Ave., Ohio State University, Columbus, OH 43210, email jag@ohstphrm.pharmacy.ohio-state.edu; send new product announcements to Christine Miller, Computer, 10662 Los Vaqueros Circle, P.O. Box 3014, Los Alamitos, CA 90720-1264, email s.c.miller@compmail.com.

If you are willing to review papers for this special issue, please send a note including your technical interests to either guest editor.

What is the Deutsch Limit?

A term made up by Fred Lakin describing a comment Peter Deutsch made at a VL talk by Scott Kim and Warren Robinett about a visual machine language they had invented.

Deutsch said something like:

"Well, this is all fine and well, but the problem with visual programming languages is that you can't have more than 50 visual primitives on the screen at the same time. How are you going to write an operating system?"

This points out the obvious density advantage of text. This barrier has become known as the "Deutsch Limit," stated as:

The problem with visual programming is that you can't have more than 50 visual primitives on the screen at the same time.

[ Above by Fred Lakin, below by Dave McIntyre ]

This is clearly a problem with visual representations. However, it is not immediately clear to me that a similar limit does not also exist in textual languages.

When textually programming I frequently use an Emacs window with about 50 lines of text on my 19" monitor. Anyone older than about 35 complains that they cannot read the text because the font is too small. I use a lot of whitespace in my programs, so we might assume that the 50 lines in the editor contain 40 meaningful line. Most common programming styles dictate limiting the number of "primitives" or statements to one or two per line, giving my textual screen at most 80 primitives.

Any comments?

What commercially available toolkits could help in VL programming?

[Note: these sections contain blurbs from ads...I'm not writing this]

Tom Sawyer's Graph Layout Toolkit.
Tom Sawyer's Graph Layout Toolkit is a family of portable libraries that deliver an immediate face-lift to graphics applications with its sophisticated layout algorithms.
[Seems to include several different layout algorithms for different style networks.]
info from: info@tomsawyer.com / 510-848-0853 / Berkeley, CA

Acknowledgements

This work has been significantly enhanced through input from:

Brook Conner				dbc@cs.brown.edu
Margaret Burnett			burnett@cs.orst.edu
Nick Wilde				wilde@sigi.cs.colorado.edu
Brendan Madden				bmadden@tomsawyer.com
Ron Dolin				rad@sbhep.physics.ucsb.edu
Fred Lakin				lakin@pgc.com
Michael Bell				mbell@compsci.liverpool.ac.uk
John Morris				morris@probitas.cs.utas.edu.au
Wayne Citrin				citrin@soglio.colorado.edu
Kent Wittenburg				kentw@bellcore.com
Marc Brown				mhb@src.dec.com
Marc Najork 	    	    	    	najork@src.dec.com
Brigham Bell				bbell@
Peter Newton				newton@cs.utk.com
Makoto Murata				murata@wrc.xerox.com
Brian Powell                            brian@natinst.com
John Grundy                             jgrundy@waikato.ac.nz
N F Drakos				nikos@cbl.leeds.ac.uk