Prograph
 |
Research on what would eventually evolve into Prograph started at the Technical University of Nova Scotia in 1982 as a general investigation into dataflow languages. The system developed through the decade, and after five years it had evolved into a fairly complete environment on the only computer able to host it, the Mac.
Seeing commercial potential, Prograph International formed in 1987 to sell the system. The first release was finally ready after another year and a half of development, and shipped in October 1988. Several upgrades followed; 1.1 shipped in March 1989 with a number of additions, 1.2 in September added almost complete coverage of the Mac Toolbox API, and in July 1990 they released Prograph 2.0, which added a compiler to the system.
Sales were slow, and Prograph International eventually went bankrupt. However the principle founders re-formed the company as TGS Systems and continued development. Prograph generated some interest, but did not find a wide following and development could not be fully funded. Eventually a new version, Prograph CPX (Cross-Platform eXtensions) was announced that was intended to build fully cross-platform applications, and released in 1994. However the Microsoft Windows version took much longer to ship than was expected, and the company eventually went bankrupt in the process.
Re-forming once again in the mid-1990s as Pictorius, the Windows version of CPX did little better than the Mac version, and the product was eventually withdrawn from the marketplace in 1999. Pictorious turned to custom programming, but seems to have largely disappeared since. The Windows version of CPX was later released for free use, and is available for download on their website.History
 |
| Prograph objects |
| All images courtesy MacTech |
Prograph took the concept further, introducing both object-oriented methodologies, and a completely visual environment for programming. Objects are represented by hexagons with two sides, one containing the data fields, the other the methods that operate on them. Double-clicking on either side would open a window showing the details for that object, for instance, opening the variables side would show class variables at the top and instance variables below. Double-clicking the method side shows the methods implemented in this class, as well as those inherited from the superclass. When a method itself is double-clicked, it opens into another window displaying the logic.
 |
| Method implementation |
Several features of the Program system are evident in this picture of a database sorting operation. The upper bar shows that this method, concurrent sort, is being passed in a single parameter, a database object. This object is then fed, via the lines, into several operations. Three of these extract a named index and then pass it in turn to a sort operation, while the third is not operated on until the end. All four are then combined into the inputs for the final operation, update database, which has no outputs. The bar at the bottom of the picture has no connections, so this method does not return a value.
In a dataflow language the operations can take place as soon as they have valid inputs for all of their connections. That means, in traditional terms, that each operation in this method could be carried out at the same time. Dataflow languages tend to be inherantly concurrent, meaning they are capable of running on multiprocessor systems "naturally", one of the reasons that it garnered so much interest in the 1980s. Also note that although this is a method of some class, there is no self; if self is needed, it can be provided as an input or looked up. In this case the operators extracting the indexes from the database are "getters", and pass back self in their first output (left unconnected here) and the instance variable in the second output.
 |
| Operators and controls |
doit method on a list of input data is constructed by first dragging in the doit operator, then attaching the loop modifier and providing the list as the input to the loop. Another annotation, "injection", allows the method itself to be provided as an input, making Prograph a dynamic language to some degree.Several problems with the Prograph system are also evident in this image, although perhaps not as obvious. For one, the inputs and outputs are not labeled. Labels are up to the programmer to provide via on-screen "comments", but this places the comment in the wrong place; if you already know the answer there's no point seeing it in your own code, in order to see the comments on the code you're using, you need to open the window for those methods. Worse, the vast majority of Prograph's own code was left unlabeled, making trips to the documentation far too frequent. Tooltips would have helped tremendously here, as would a hotkey to turn them all on at once. Another problem is that many icons simply don't "translate" well into familiar programming terms, and in other cases some particularly obvious possibilities are not used. Consider the getter operators in this picture, does a rectangle with a notch in it imply "get"?
Just as annoying was the fact that the "wiring" could not be routed in order to clean up the diagrams. In this instance one two of the paths cross because one of the wires from the input bar has to flow to a particular (unlabeled, of course) input on the update operation. Typical program methods often turned into spaghetti code that would make traditional text-based programmers wince.
Finally, Program included no simple way to gather up several operations into a single "black box", without turning it into a method of its own. The side effect of this is that complex operations needed to be broken down in order to maintain readability. However Prograph forced each method to open into its own window, and so typical programming sessions involved moving from window to window. Sadly Prograph offered almost no functionality for dealing with this mess of windows, with the exception of the "back" and "forward" buttons visible in the picture above.
While in theory Prograph was an interesting attempt to break out of the traditional paradigm of text-processing for program construction, it failed as a practical system due to what amounted to solvable GUI problems.
External links