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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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!
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.
Goldstein, Neil, and Alger, Jeff, Developing Object-Oriented Software for the Macintosh, Addison-Wesley, Reading, Mass., 1992.
