Picture programs; programming a computer may eventually be as simple as sketching a diagram or drawing a flowchart.

A peak into a typical computer program generally reveals little more than a seemingly random array of words and symbols. A closer look shows patterns and perhaps some meaningful order in the way these words are listed. But one of the best ways to get a sense of a program's function is to look at a flowchart that diagrams the way in which the program does its job.

A visual trip along a flowchart's lines takes a user from step to step, from choice to choice, until a particular task is completed. Translated into a conventional computer is literally worth a thousand words or more. But if creating a flowchart were to become the only step in writing a computer program, it would eliminate the tedium of translating a complex concept into myriad lines of code.

A few computer scientists are starting to take this possibility seriously. Not only would a "visual language" make computer programs simpler to write, but it would also make then easier to understand. A quick glance would be enough to show a user what's going on. In essence, with a visual programming language, what you want is what you see is what you get.

A panel discussion at the recent National Computer Conference in Chicago highlighted some of the ways in which researchers are beginning to develop visual languages. It also focused on the problems that must be overcome before such languages can become widely used.

The growing availability of computer terminals or personal work stations that handle graphic symbols is one of the forces driving interest in visual programming. Already, users can design "objects," such as business forms or mechanical devices, by assembling simple graphic "building blocks" supplied by the computer. The finished picture, made up of these pieces, as a whole represents one type of visual program.

This kind of scheme works very well when the object being designed has an obvious, direct representation. Laying out an invoice, for instance, simply means putting the appropriate components in the right places on a picture of an invoice. The problem is much more difficult when visual programming is used to represent something abstract--a time sequence, related bits of knowledge, conditional statements. It becomes necessary to devise visual metaphors for picturing these ideas.

"Inventing suitable visual representations is the key problem," says Robert J.K. Jacob of the Naval Research Laboratory in Washington, D.C. "It's hard to think of good pictures to use." And, he adds, the choice of representation makes a big difference in how well the language suits a given application.

Jacob is now experimenting with "state transition diagrams," a pencil-and-paper tool widely used by computer scientists to describe algorithms or computational procedures. He sees an extention of these diagrams as a potential visual programming language.

One of the main virtues of state diagram notation, says Jacob, is that it shows precisely what the user can do at each point in a dialogue between the user and a computer and what its effect will be. Moreover, a computer, using state diagrams as part of a system for providing help to users, can even answer user questions such as: "What can I do next?" "Where am I?" and "How can I do...?"

In general, state diagrams, usually drawn as branching chains of circles linked by arrows, tell users what happens for all possible inputs. The diagrams also clearly indicate what a user can do to switch from one "state" to another in which the results for a certain input may be different.

When this notation is used, writing a computer program turns into drawing the appropriate state diagrams, which the computer understands and implements. Editing a diagram automatically alters the program.

Jacob has used a primitive version of this idea to design and specify how a user interacts with a computer in several prototype systems. It forms the basis for a military message system, for example, in which the user can manipulate information displayed in several "windows" on a video screen. Details of his scheme appear in the August IEEE COMPUTER, a special issue devoted to visual programming.

"Visual languages are difficult to build, implement and write," says Jacob. His own system maybe as much as five years away from general use.

Moshe M. Zioof of M.M. Zloof, inc., ub Dobbs Ferry, N.Y., emphasizes the usefulness of being able to see a computer program as a whole. "A computer programmer builds a mental image of a program as he or she reads it," he says. People who don't know how to program a computer have much more trouble building such an image. However, a program in the form of pictures lets them grasp much bigger chunks at a time.

This is the principle behind Zloof's "Office-by-example" software developed for IBM. It can be used, for instance, to put together invoices from information on orders and prices. All the necessary procedures are represented on a video display and can be easily modified and manipulated to construct the required form. Zloof is now developing a "Database-by-example" that uses a similar visual form to retrieve information from computer files.

This visual approach gets complicated, however, when a single picture can't tell the whole story. "You can easily lose tract of what you're doing," says Zloof. There may be limits to how cluttered a single picture can get and to how many different pictures a person can handle.

Margaret A. Khorthage of Trammel Crow Co. in Dallas argues that stylized pictures take time to read and grasp. People have to be taught to understand the symbols, she says. Although good "icons" can sometimes be created for nouns, other parts of speech, like verbs, tend to lose out.

Khorfhage wonders how much of the current surge of interest in visual languages is just a fad. "Can we communicate effectively without a visual language?" she asks.

"It's not a fad," says Adarsh K. Arora of the Gould Research Center in Rolling Meadows, Ill. He points to the increasing use of computer-aided design, spreadsheet programs, windows and other visual aids to help users get what they need out of a computer. All of these may be considered primitive visual programming languages, he says.

Arora suggests that animation may eventually be used to show how objects, as designed on a computer, would work. Visually following flows through a "data structure" or program to see how it behaves could make it easier to track down errors.

"Visual languages are here," says Jacob, "but they have a long way to go. In the long run, a theoretical understanding of visual perception is needed." This would let designers devise more effective graphic symbols for their particular picture programs.