Prograph CPX -- A First Look
There have been several excellent articles in FrameWorks about the Prograph language and development environment from TGS Systems -- most recently the delightful description by Laughing Water in the September/October '93 issue in which he characterized the process of 'prographing' -- using this unusual language with its tightly integrated and dynamic environment in the task of developing a new Macintosh application. His descriptions of what it feels like to sculpt a program with Prograph while that program is running are excellent, and are as true today as they were when he wrote them. However, many of the details about using Prograph have changed with the release of a major new version in late September. This new release, called `Prograph CPX' -- for `Corporate Programmer, Cross-Development' -- addresses all of the weaknesses that Laughing Water and other Prograph users have observed with the previous customer release, Prograph 2.5. In this article, I will present an overview of what is different about Prograph CPX, and talk about my experience of re-implementing the MacApp samples in CPX. I will assume that you know the Prograph basics, either by reading Laughing Water's article, or by having used Prograph 2.5 a little, and thus I will only talk about the changes that CPX represents.
Any object-oriented development environment is composed of at least the following three parts: the language(s) in which you express your application, the class library that you extend to provide the functionality of your application, and the programming environment (with associated tools) in which you do the work to actually implement, debug, fine-tune, and otherwise develop your application. For the MacApp 3.0 user, these are C++, the MacApp 3.0.1 class library, and MPW, respectively. For the Prograph CPX user, these are the Prograph language, the new ABC classes, and the Prograph editor/interpreter and Prograph compiler. The quick report is that the language hasn't changed at all, the class library is greatly expanded both in functionality and in depth, and the environment is faster, easier to use, and more powerful. However, let's examine in some detail what's different about each of these in the new release, one at a time. (Note that it is a bit artificial to draw these boundaries in Prograph since everything in the Prograph development environment is so tightly integrated. However, I have to organize this description somehow.) Coincident with this major new release of their flagship product, TGS has changed its name to `Prograph International' and is expanding its San Francisco-based sales office.
First, the easy one: the Prograph language itself. The CPX release makes no changes to the Prograph language, other than to better position it for cross-platform use. Icons that were called `Mac Method' or `Mac Constant', for example, are now called `External Method' and `External Constant'. A translator provided with CPX handles these easy languages changes and moves much of the code developed with earlier versions of Prograph to CPX. (I say `much of' because differences between the class libraries of earlier versions and CPX make automatic conversion of all of your old source code impossible. We'll discuss these differences in just a moment.)
Prograph International has promised a means of getting Prograph applications over to Microsoft Windows before the end of the year, and these small language changes are meant to signal this coming development. (Rumor has it that this will mean a port of the Prograph Compiler and associated libraries to Windows first, followed by the rest of the development environment at a later time.) The goal is to enable to Prograph user to port an application from Mac to Windows with no changes to their source code. This means, however, that your code cannot call the Mac Toolbox directly, but must call only the Prograph primitives. This is now possible because the class library is greatly expanded. This leads us to the ...
In the last issue of FrameWorks, Laughing Water wrote that "Prograph's class library succeeds in being learnable, but its sparseness is perhaps Prograph's weakest feature." It was certainly true that the Prograph 2.5 class library was sparse -- the additional classes in the so-called Essentials and Goodies disks not withstanding. However the new Prograph CPX class library is greatly expanded -- so much so that it is now comparable with that of MacApp or TCL, and has some really great features that they don't. Compared to the old Prograph 2.5 class library, the Prograph CPX class library has been re-architected and re-implemented from the ground up, and it integrates the features of the old System Classes, the old Essentials and Goodies, and several new features influenced by MacApp and TCL. Appropriately so, this class library has a new name: the Application Builder Classes, or the ABCs for short.
Let's handle the easy statistics first: The ABCs contains about 360 classes and about 2600 methods. (A portion of the ABC class library hierarchy is shown in Figure 1.) (See Figure 1. Caption text: A portion of the class library hierarchy of the new ABC class library in Prograph CPX. Note that this library is a forest, and not a tree, i.e., there is no single root class (like TObject) that is the ancestor of all the classes in the library.) From a bulk perspective alone, that makes it about the same size as current release of either MacApp or TCL. However, the merit of a class library is not measure by its bulk, but rather by the features it supports. A partial list of the ABC features include files and documents, a wide selection of window widgets and controls, lots of window types - including floating windows, undo, grids, threads, AppleEvents, styled text, menus, text styles, behaviors, printing, the Clipboard, offscreen bitmaps, basic QuickDraw constructs, scrolling, commands, and balloon help.
One really nice feature of the CPX class library is that almost all of the classes are packaged with class-specific editors which provide a WYSIWYG editing environment for instances of those classes, and for the interconnections between those instances and other objects in the run-time framework which makes up the running application. Figures 2 and 3 show some of the editors, and figure 4 shows how the document editor supports the interconnections between document instances and associated window, file, and print layout objects. (See Figure 2. Caption text: The Grid object's editor. This editor can be used when the application is not running to set default values for a particular grid object that will be allocated later, or it can be used while the application is being interpreted to change the values for an existing grid object. ) (See Figure 3. Caption text: Some of the editors associated with the button object. These editors set the border, the button's response to window re-size events, and the click behavior. Note that the click behavior editor specifies the method that will be called when the button is clicked, and the actual arguments to this method. The Prograph interpreter will create this method at run-time if it does not exist. ) (See Figure 4. Caption text: The document editor. With this editor, the developer specifies the auxiliary objects that, together with the document object, provide to the end-user features like printing, viewing, and disk I/O. ) There is an easy-to-follow naming convention for a class and its editor: a class named "Foo" is edited by a class named "*Foo Editor".
Having editors that can set up the run-time interconnections between objects means that you have to write less code, and the code that you don't have to write is some of the most boring and error-prone stuff you have to do with MacApp now. For example, expressed in MacApp terms, allocating a print handler and associating this print handler with a particular view can be done in the environment in a WYSIWYG manner using pop-up menus to select choices -- you don't have to write any code at all. (Figure 4) Pulling all the text elements out of a set of EditText objects in a complex dialog, as well as associating the settings of check boxes and radio buttons with internal variables in your application can be done in a WYSIWYG manner. (Figure 3) This feature of having an individual editor for each type of object is a delight to use, and after only a few uses you wonder why you ever had to do all that work in other environments.
A simple sounding change in CPX, but one that has rather wide ranging consequences is that all of the ABC classes are written in Prograph. The old System Classes in Prograph 2.5 weren't entirely written in Prograph, and this resulted in some limitation in their use. For example, you could only add instance variables to leaf classes, and some classes appeared to have no methods. The basic cause of state of affairs was that the speed of the Prograph interpreter was such that if the old System Classes were entirely written in Prograph, the resulting performance would not have been acceptable. This restriction is gone because the interpreter is now much, much faster. (It is actually now an incremental compiler, about 10 times as fast as the old 2.5 Interpreter. However, partially for historical reasons, it will probably always be called the `Prograph Interpreter'.) It is fast enough that not only are the ABC themselves written in Prograph, but so are all of the editors. What I believe this will lead to is an increased ability for the Prograph programmer to incorporate classes written by others. Now, in addition to the class itself, the source code (perhaps), and documentation (yeah, right!), the class can come pre-packaged with an WYSIWYG editor for its instances. To help you build the editor you can -- yup, you guessed it -- use the ABCs themselves. That's how the engineers at Prograph International did CPX and now you can do the same thing. This is because the environment allows for multiple threads of execution. Which leads us to the ...
Prograph Programming Environment
When asked to name the three most important features of a development environment, the usual response is "One: speed; two: speed; and three: speed." And with good reason. We all know how unproductive and mind-numbing it can be when the edit-compile-link-debug cycle is many minutes long. The CPX engineering team was sensitive to this most basic need of their customers and even though the previous release of Prograph was very fast, the CPX development environment is much faster in almost all of its functions. The interpreter is much faster (about a factor of ten), the compiled code is faster, and saving to disk is much faster. (Of course, some of this speed increase is `eaten up' by the increased functionality of the ABCs and their editors.) The two functions that are slower are opening a project, and compiling. However, these slower operations are not done as often as the faster ones, so the overall experience is that of a noticeable speed improvement.
While speed is important, there are a number of other improvements to the Prograph development environment. The most pervasive of these is that the source code for an application being developed in CPX does not have to be stored in a single file. An application's source code and resources can be spread over any number of files called sections, and references to all the sections needed to build an application are stored in a project. A section can contain any of the elements that make up the source of an application: classes, methods, global functions (still called universal methods), persistents, resources, etc. The iconic depiction of a section -- an important thing in a visual programming environment like Prograph -- shows the collection nature of the section as it contains the icons for Prograph classes, methods, and persistents. (See Figure 5. Caption text: The icons (both full sized and list view formats) for the new Prograph section.) As one would expect in Prograph, where you click on the section icon determines which portion of the section is shown to you: click on the classes sub-icon, and a window showing the classes of that section opens.
There are just three rules to the use of a section:
- A class must be totally contained in a single section.
- A method must be totally contained in a single section.
- Class names, as well as the names of universals and persistents, must be unique in a project.
The same section may be used in any number of applications, and class inheritance chains can span any number of sections. The implementation of this last feature, inheritance spanning sections, is particularly elegant. Recall that the basic idea of Prograph is to bring the features and strength of the Mac UI to the programmer. One of the most used and most elegant features of System 7 is the alias, and it is with the alias to a class that inheritance across sections is made available to the Prograph user. Figure 6 shows one section, and in that figure you can see aliases to several classes defined in other sections. (See Figure 6. Caption text: The classes of one section. Notice the use of aliases to classes defined in other sections.) Class aliases are distinguished by a superimposed bold, down arrow and, like System 7 aliases, italic names. Creating an alias to an existing class is easy, and once done, the alias acts almost exactly like a real class: double clicking on its left side brings up a window of its attributes; on its right side a window of its methods. You can do anything with an alias except change its inheritance by making it the successor of some other class.
Figure 6 is not just a randomly chosen section. It is the section of my re-implementation of the Nothing MacApp sample, and it contains all the classes that I added to implement this sample. (Those classes are highlighted.) I can save just this one section to save all my work. Saving is fast, its easy to differentiate my work from the ABCs provided by Prograph International, and its easy to organize and comprehend. This is a welcome change from the earlier versions of Prograph. For a larger application, of course, I could use several sections to contain my classes and universals.
Figure 7 shows two other really nice additions to the environment: visible breakpoints and value popups. (See Figure 7. Caption text: Visible break points and value popups in a paused application.) This figure shows two windows depicting an application paused at a break point -- you can tell this because of the patterned background of the windows. The window on the right shows the execution stack and the window on the left represents the code that contains the break point -- the little flag at the top of the code. I have single-stepped about halfway through this code, and now I want to know the values of the data elements that are flowing between the elements. To do this, all I have to do is to mouse-down on the terminals (the little hollow circles), and a pop-up shows the value of the data element flowing on that line.
Re-implementing the MacApp samples
As part of an evaluation of Prograph, I decided to re-implement some of the MacApp samples. Since Prograph provides full access to the Toolbox, it is possible to re-implement all of the MacApp samples. In the next several issues of FrameWorks I will be doing so, and using this approach to explore the ABCs and compare them to MacApp and in this way examine various issues in framework structure and application design. The samples I choose for this introductory article on CPX were the easy ones: Nothing and DemoText. I assume that the reader is familiar with the basic functionality of these applications, and has at least looked at their MacApp implementations.
The basic functionality of Nothing was easily re-implementable in CPX. In fact, as you can see from the Nothing source code (on the FrameWorks source code disk as PICTs), there isn't much more to the implementation than just a little bit of code to construct and display a clipboard view and an About box. Everything else was done in the ABC editors and thus involved no coding.
All aspects of Nothing were re-implementable in CPX.
Almost every feature of DemoText (basic multi-style text editing, saving and loading text files, hierarchical menus, font and style menus, etc.) was easily re-implementable in Serius, and almost all of it without coding. (The DemoText source code is on the FrameWorks source code disk as PICTs.)
The one tricky part of the DemoText re-implementation were the view manipulations on the Text menu ("View as wide as SuperView"). Several of these exercise particular features of MacApp that have no exact corresponding feature in the ABCs.
All aspects of DemoText were re-implementable in CPX.
Performance and size measurements
It is not easy to objectively measure the performance of applications as simple as these two MacApp samples. Subjectively, however, the performance of the MacApp implementations and the Prograph CPX re-implementations are about the same, with the MacApp versions slightly better. The bottom line is that the performance of applications generated with these two tools appears to be comparable.
Measuring size is much easier. The graphs in Figures 8 and 9 compares the disk and RAM footprints of the MacApp and Prograph implementations of Nothing and DemoText. (See Figure 8. Caption text: The disk footprint for the MacApp samples.) (See Figure 9. Caption text: The RAM footprint for the MacApp samples.) As you can see, both the disk and the RAM footprints for the Prograph applications are about twice the size of their MacApp counterparts. I will look forward to how these graphs develop as we add more points in the coming months.
As you have seen, this first-level look at the capabilities of MacApp and the Prograph CPX ABCs show them to be roughly comparable. The languages and development environments couldn't be more different. I am looking forward to presenting more detailed and more focused analyses in future issues, because Prograph CPX is an extremely enjoyable tool to use, even when compiling at 30,000 feet on a PowerBook Duo 230, where much of my development work takes place (no phones, no meetings, and people bring you food and drink).
Another question that I asked in my evaluation of Serius (July/August `93 FrameWorks) was `With this environment, can you write a program that is guaranteed to fall into MacsBug?'. The answer for MacApp -- as you may recall and know all too well -- is a resounding YES. For Prograph, the answer is the same. Prograph provides full access to the Toolbox and this power comes with a cost.