Prographing

Laughing Water

What would happen if Apple's Human Interface Guidelines were applied to programming environments? I want to explore that fantasy world and in so doing consider Prograph 2.5 from TGS Systems as a plausible answer to my question, since it is the most Mac-like full-blown programming system I have encountered. To confine myself to the space of an article, I will target my fantasies toward Pro-graph's most progressive features, and I will not attempt to duplicate the fine review articles written by John Baxter in the March and May 1992 issues of Frameworks.

The Belly of the Beast

I'm sure some of you think there are good reasons why the Macintosh revolution should never reach the rest of us, the programmers. We preserve the myth that either we or our users must suffer, and that we are the martyred heroes. In fact, the original Human Interface Guidelines (p. 4) themselves state: "Most programmers have no trouble working with a command-line interface that requires memorization and Boolean logic. The average user is not a programmer."

But let's face it, programmers are users. We are also human. (Are you still with me?) If the principles of good interface de-sign give users the power to be their best, shouldn't they em-power programmers as well? Or is the Macintosh interface only for wimps after all? I, for one, do have trouble with a command-line interface that requires memorization. And that's not the only thing wrong with today's programming systems.

Let's wallow in self-pity for a while. Most of our coding time is wasted on tasks the computer could do better or eliminate entirely. These include managing header files (or any files), correcting spelling and punctuation, guessing screen coordinates, memorizing resource ID numbers, writing debugging routines and tracking down memory leaks, not to mention waiting minutes at a time for compilers and linkers to catch up with us. To make our work "easier" we use a half-dozen or more programs or tools that sometimes have no discernible consistency to them. What we see-esoteric commands-may be nothing like what we get-a friendly and powerful Mac program. For the most part, we don't directly manipulate familiar objects and get immediate feedback, to say nothing of aesthetics and-imagine this one-forgiveness.

The belly of the beast does not always have to have indigestion. Prograph, whatever its weaknesses may be, eliminates most of the problems I've listed. To me, Prographing represents a truly Macintosh programming paradigm. Not an incremental, evolutionary refinement or a kinder, gentler facade to the old way, but a revolutionary "new" way-the Macintosh way.

A Visual Language

Prograph is a visual language. The Mac has a visual interface (and why don't we call it a "viewy" instead of a "gooey"?). Prographing consists of creating operations represented by distinctive shapes and joining them with data links. In other words, Prograph programs consist of dataflow diagrams, or graphs whose nodes are operations and whose arcs are data links. The Prograph environment makes heavy use of icons (see Figure 1-The Prograph Environment). Clicking will get you everywhere–Prograph classes, attributes for an Employee class, and a value window setting the type and default value for an attribute. How does that make it "better?"

In terms of the Human Interface Guidelines (I'll call them the Guidelines for short), visual languages would have several benefits. One is that they have a more concrete quality to them than textual languages, giving you the sense of manipulating objects on-screen. In Prograph's case, it is not hard to employ real-world metaphors of messages pulsing along wires and causing operations to "fire" or products traveling along highways to processing plants. If you're going to visualize your programs in your mind anyway, making programs visual gives you a head start.

It is also easier to visually locate operations, such as instantiation for example, when they have not only the correct name, but a distinctive shape. Textual languages, on the other hand, fail to exploit the richness of visual cues that the Macintosh can provide. Among textual languages, Think Pascal stands out in its automatic highlighting of keywords and rou-tine names, along with automatic indentation. But it pales next to Prograph's visual representation of a program's structure.

Since the mental representation of a program must include more than data flow, an ideal visual environment should show more than Prograph does. For example, it would be great to be able to see the collaborations that happen among classes of objects, some visual representation of "who does what to whom." Even better would be to integrate analysis and design into the process. Don't hold your breath.

Dynamic Development

One of the most exciting features of Prograph and its kindred OODLs (object-oriented dynamic languages) in general is the high degree of interactivity provided by a dynamic development environment. When you make changes to a Prograph program (or something considerably less than a program), you can test the results immediately. You can even make changes to your program, including the class attributes or methods of objects currently in use, while the program is running. A simple menu command allows you to redesign the front window of your application while it's running.

You can inspect and change values at will as your program runs. When errors occur, Prograph's interpreter puts the pro-blem right in your face. After you fix the problem, the interpreter rolls back to a point before the error occurred and allows you to resume execution from there. That's a level of forgiveness I have not encountered in any other programming system.

If your program calls a method or refers to an attribute that doesn't exist yet, Prograph's interpreter gives you the option of creating it on the spot. Relying on this feature too carelessly could get you into trouble, but consider the benefits. The computer actually tells you (or at least gives clues) where the missing item belongs and, for methods, the arity.

For those of you who spend much of your waking hours watching a spinning beachball cursor, I don't have to explain how addictive this approach is. Note that an interpreter with dynamic linking provides a fundamentally different alternative to faster hardware, faster compilers or faster linkers, which diminish the problem without removing it. You can't get to the moon in a souped-up hot rod; by the same token, you can't provide true interactivity with a compiler (except perhaps with an incremental one, such as MCL's).

The Guidelines stress the importance of putting the user in control, facilitating the process of experimentation and forgiving the user's mistakes. By those standards Prograph is a playground compared to MPW, which is more like reform school. Where the Guidelines require giving immediate feedback to the user, MPW provides a spinning beachball, Symantec C++ gives a series of dialog boxes, and Prograph simply gives results.

WYSIWYG Interface Design

Any Mac-like programming environment would have to include the ability to design visual interface elements in a graphical fashion. Prograph provides this capability as part of its integrated Application Builder. Other programming systems rely on separate tools and third-party applications such as Classy, ViewEdit, AdLib, IcePick, AppMaker, Marskman, Action! and of course ResEdit.

The value of visual interface editing is beyond argument. I would only underscore the fact that it is an integral part of Prograph, which one would expect of a visual language, while it is most often provided as a third-party product for MPW and Symantec languages. Thus, as one would expect, there is a higher degree of consistency and an easier learning curve.

(Among visual interface design tools, I would have to say that Prograph could stand improvement. For example, selection of multiple window items in order to move them as a group is such a common feature of graphic programs that it should be considered a minimal feature.)

Smart Editing

In my perfect programming world, I would never have to repeat myself. Assigning ID numbers to resources through ResEdit and then declaring them as constants in my source code is a case in point. Prograph eliminates this need through its Application Builder in relation to windows and window items, menus and menu items, events, and Balloon Help resources.

In order to make programming as interactive and efficient as possible, it would be great to have readily accessible on-line documentation. Anyone who has used Think Reference knows how indispensable it becomes, providing relatively immediate explanations of toolbox calls, data structures, system globals and so forth, along with function templates enabling you to paste code into your program.

Prograph provides similar capability through its Info win-dow, although much of its content is complementary to Think Reference. One thing that really stands out, though, is that you don't even have to use the Info window in many cases. You can create an operation and type its name. If it's an operation Pro-graph "knows" about, then the operation's icon will take on its distinctive appearance (depending on whether it's a Prograph primitive, toolbox call, Mac constant, and so on) and draw itself with the correct number of roots and terminals (arity).

This is another area where interactivity and immediate feedback are evident. Contrast this approach, where the computer is continually "attentive," to the more common situation, where the computer sits there dumbly wasting its massive power and ignoring even your most flagrant errors until you compile, link and run your code.

Seamless Source

Files are beginning to outlive their usefulness. They serve as a way of grouping related information and giving it a meaningful name, making it more accessible than if all we had to pick from was a bunch of disk sector numbers. However, file names and the arbitrary boundaries created by files are often as irrelevant to us as sector numbers.

For a programmer's purposes, it might make much more sense to look for source code by clicking on a class hierarchy diagram, and (surprise!) that's how Prograph works. The lack of a separate file for each class presents no apparent problems, and in fact Prograph's ability to selectively load individual classes, persistents or methods from a second program file provides more flexibility than the ability to copy conventional source files.

In human interface terms, we are interested in objects (classes) or methods rather than the files in which they reside. It would be more appropriate for us to directly manipulate those items rather than manage files.

We should at least find ways to do away with C header files and Pascal interface declarations. The more erudite among you can explain to me what purpose they serve, other than putting you at the service of your compiler and linker. These may have been necessary when computing resources were more limited, and even now, they are important if you're going to compile and link every time you want to see the results of program changes. But their price in terms of turning the programmer into a housekeeper seems too high to me. Needless to say, Prograph does not have such a thing.

Garbage Collection

Any tool, including a programming system, succeeds to the extent that it is invisible, so that the task, not the tool, is the center of awareness. Managing memory is not the raison d'etre of most programming projects. Tracking down memory leaks due to undisposed objects can take an exorbitant toll on a programmer's time. Moreover, the explicit disposal of objects, distributed as it often is throughout a program, does violence to the principle of encapsulation. Therefore garbage collection is a function that should be provided by a programming language. Prograph provides it.

Object Orientation

I don't have to explain the value of object programming to FrameWorks readers. Prograph is object-oriented from the ground up, although it lets you program in as procedural a fashion as you like, with full access to the Mac toolbox. Prograph is not only an object-oriented program language; it provides an object-like environment. That is, it makes use of icons to represent classes, attributes, methods, and so on. This is consistent with Prograph's visual nature in general and provides the same benefits as described earlier.

From a human interface point of view, object-oriented programming mirrors the real world to some extent. Goldstein and Alger have argued convincingly as to its limits in this regard. But regardless of whether programmer's classes coincide with cognitive categories, encapsulation enables programming objects to enjoy a degree of real-world discreteness, and inheritance and polymorphism enable the programmer to deal in abstractions and generalizations closer to familiar, everyday thinking.

Data Storage

Storing objects and data to disk is so basic to the vast majority of programs that it deserves to be part of a fully-featured software development package. As with memory management (which is short-term instead of long-term), data storage may be essential to your project, but it should ordinarily be incidental to your program, not the main point of it.

Prograph includes both object persistence and a multi-user database engine. Object persistence is about as gracefully implemented as I can imagine, short of making every object persistent automatically. The database capability is provided through a collection of Prograph primitives, which is to say, seamlessly.

Class Library

Describing an ideal class library or application framework must remain outside the scope of this article, except to say that it is a key feature of a Macintosh programming system. It should be organized in a way that makes it easy to learn (don't ask me), but it should be complete enough to provide a substantial basis for common applications.

Prograph provides a set of system classes, as they're called (see Figure 2-The Prograph System Classes). These include Application, Menu, Window and the most common Window Items. Other classes are available as extras from TGS Systems on their Essentials and Goodies disks.

Prograph's class library succeeds in being learnable, but its sparseness is perhaps Prograph's weakest feature. There are no grids, no sorted lists, no adorners, no behaviors, no formal mechanism for specifying dependencies, no system for making user actions undoable, not even classes for files or documents. The Prograph tutorial criticizes the MVC (model-view-controller) object paradigm as being too complicated, arguing instead for consolidation of handling input and output into single objects. Perhaps it is because of this philosophy that Document is a subclass of Window in TGS's sample Document Shell program. To me this attitude seems too austere.

Consistency and Aesthetic Integrity

Prograph's completeness and high level of integration are an advantage in delivering the consistency and aesthetic integrity that characterize a good Macintosh program. Prograph uses simple geometric shapes consistently throughout its environment to indicate instantiation, "get" methods, "set" methods, attributes, controls, and so forth. The use of icons, value windows, and commands for cutting, pasting and duplicating objects recur in different parts of the Prograph environment.

In contrast, MPW is a hodgepodge of obscure UNIX-like commands and more Mac-like Commando dialogs. Typically you would use it with a collection of other programs, such as ResEdit and MacsBug, which have no consistency among them to speak of. The leverage obtained from learning one of these programs in order to master another is practically nil.

Suffice to say that the time required to get up to speed with Prograph is minimized by its consistency.

Versatility

A fundamental theme in programming is hiding implementation details through high-level data and procedural abstraction. A real-world analogy is driving a car, where the driver need not know the principles of fuel chemistry or the workings of engine valves, but can attend to starting, turning, and stopping. On the other hand, sometimes a driver can use her vehicle more effec-tively if she understands its underlying mechanisms.

Likewise a mature programming system should enable a programmer to do as much work as possible with higher-level abstractions, while permitting access to low-level operations where performance may be critical.

Prograph succeeds admirably in this regard. It contains a collection of useful primitives, which, along with its class library, make it possible to write complete Mac applications without using a single toolbox call or explicit memory allocation. On the other hand, all Mac toolbox calls are available for the Prographer's use. Lastly, Prograph can use external primitives or external code written in C, Pascal or FORTRAN.

I am far from having explored all of Prograph's capabilities, but I'll cite one example that I've had fun with.

A common programming task is editing complex data using a modal dialog. This normally requires accessing or creating an instance of that data, setting the window items in the dialog to reflect the data's initial values, editing the items as displayed in the window and finally retrieving the values from the window items for storage. In most languages this process requires setting and getting window-item data one item at a time. For example, if your dialog has ten text fields, 3 checkboxes, 2 sets of radio buttons, a date field and two money fields, you've got 18 assignment statements coming and going. On top of that, you'll need to convert between checkbox states and boolean values, text contents and seconds since 1/1/04, and so forth.

In Prograph I've created an Editing Window class that automates this process. An editing window owns an object whose attribute names match the names of appropriate window items. Prograph's existing window item classes are subclassed to convert their data between display and storage types during setting and getting. Through Prograph's "method injection" feature (see Figure 3-Method Injection in Action). An attribute name is used to locate a window item and to get a value from an object whose attributes are being edited (the Get operation at right is specified by method injection), it is then possible to initialize and retrieve the window item values by using a simple list operation (see Figure 4 on page 57). A list operation is used here to set a window's items. The content operation is a Get operation that gets an object that is owned by the window and whose attribute values are to be edited. The attributes primitive gets the object's list of attribute names.). I'd love to hear how (or whether) this can be done in MacApp!

A Macintosh Programming Paradigm

I have described features defining a way of programming that befits the Macintosh. These features include exploiting the graphical interface of the Macintosh, providing a sense of directly manipulating programming entities as well as the visual elements of the program's user interface; providing a high degree of interactivity and forgiveness, facilitating an exploratory, creative process; integrating as many facets of software creation as possible.

Look at the latest version of any Mac programming system, along with its third-party tools, and I'm sure you'll recognize the trends toward interactivity, control, immediate feedback, real-world metaphors, consistency and recognition (rather than recall), all of which are directed not only at making the learning process easier for beginners, but maximizing the effectiveness of experienced programmers.

I would argue, though, that Prograph is revolutionary in the sense that it was designed from the ground up (much like the Macintosh compared to the IBM PC) to embody the Guidelines. It is not a haphazard collection of tools and third-party code generators, nor is it a mere extension to a language inherited from an earlier era. It therefore avoids fundamental constraints necessitated by languages designed for the hardware of the past.

Just as in 1981, when "most of us" went IBM because we thought everyone else would, today most of us programmers are choosing a less imaginative and progressive technology (yes, C++) because it represents the mainstream. I hope the portrait I have painted raises your expectations of what programming can be, and to an extent, already has become in the form of Prograph.

References

Apple Computer, Human Interface Guidelines: The Apple Desktop Interface, Addison-Wesley, Reading, Mass., 1987.

Goldstein, Neil, and Alger, Jeff, Developing Object-Oriented Software for the Macintosh, Addison-Wesley, Reading, Mass., 1992.