Prograph

From Wikipedia, the free encyclopedia

Prograph is a visual, object-oriented, dataflow, multiparadigm programming language that uses iconic symbols to represent actions to be taken on data. Commercial Prograph software development environments such as Prograph Classic and Prograph CPX were available for the Apple Macintosh and Windows platforms for many years but were eventually withdrawn from the market in the late 1990s. Support for the Prograph language on Mac OS X has recently reappeared with the release of the Marten software development environment.

Contents

[edit] History

Research on Prograph started at Acadia University in 1982 as a general investigation into dataflow languages, stimulated by a seminar on Functional Languages conducted by Michael Levin. Diagrams were used to clarify the discussion, leading to the insight: "since the diagrams are clearer than the code, why not make the diagrams themselves executable!" Thus Prograph - Programming in Graphics - was born as a visual dataflow language. This work was led by Dr. Tomasz Pietrzykowski, with Stan Matwin and Thomas Muldner co-authoring early papers. From 1983 to 1985, research prototypes were built on a Three Rivers PERQ graphics workstation (in Pascal, with the data visualized as fireballs moving down datalinks), and a VAX with a Tektronix terminal, and an experimental compiler was programmed in an IBM PC. This work was continued at Technical University of Nova Scotia by Pietrzykowski and Dr. Philip Cox, including a version done in Prolog.

In 1985, work began on a commercialisable prototype on the Macintosh, the only widely available, low-priced computer with high-level graphics support available at the time. In early 1986, this prototype was taken over by The Gunkara Sun Systems (later renamed to TGS Systems) for commercialisation, TGS formerly being a consulting firm formed by Pietrzykowski at Acadia University. Working with Pietrzykowski and Cox, Terry Kilshaw hired and managed the original development team, with Jim Laskey as the lead developer. In 1987 Mark Szpakowski suggested the merger of object-orientation with visual dataflow, creating an "objectflow" system. After almost four years of development, the first commercial release, v1.2, was introduced at the OOPSLA conference in New Orleans in October 1989. This product won the 1989 MacUser Editor's Choice Award for Best Development Tool. Version 2.0, released in July 1990, added a compiler to the system.

TGS changed its name to Prograph International (PI) in 1990. Although sales were slow, development of a new version, Prograph CPX (Cross-Platform eXtensions) was undertaken in 1992, that was intended to build fully cross-platform applications. This version was released in 1993, and was immediately followed by development of a client-server application framework. Despite increasing sales, the company was unable to sustain operating costs, and following a failed financing attempt in late 1994, went into receivership in early 1995.

As the receivership proceeded, the management and employees of PI formed a new company, Pictorius, which acquired the assets of PI. Shortly afterwards, development of a Windows version of Prograph CPX was begun. Although it was never formally released, versions of Windows Prograph were regularly made available to Prograph CPX customers, some of whom ported existing applications written in Macintosh Prograph, with varying degrees of success.

After management changes at the new company, emphasis shifted from tools development to custom programming and web application development. In April 2002 the web development part of the company was acquired by the Paragon Technology Group of Bermuda and renamed Paragon Canada. The Pictorius name and rights to the Prograph source code were retained by McLean Watson Capital, a Toronto-based investments firm which had heavily funded Pictorius. A reference to Pictorius appeared for a time on the former's Portfolio page, but has since disappeared. The Windows version of CPX was later released for free use, and was available for some time for download from the remnants of the Pictorius website (link below).

A group of Prograph users calling themselves The Open Prograph Initiative has existed since the late 1990s; formed initially with the goal of keeping Prograph viable in the face of OS advances by Apple and Microsoft, the group now also seeks to create a new open-source visual programming language to serve as Prograph's successor.

[edit] Description

Prograph objects. All images courtesy MacTech
Prograph objects. All images courtesy MacTech

During the 1970s program complexity was growing considerably, but the tools used to write programs were generally similar to those used in the 1960s. This led to problems when working on larger projects, which would become so complex that even simple changes were difficult to fully understand. Considerable research into the problem led many to feel that the problem was that existing programming systems focused on the logic of the program, while in reality the function of a program was to manipulate data. If the data are to be manipulated, why is it not the "first class citizen" of the programming language? Working on that basis, a number of new programming systems evolved, including object-oriented programming and dataflow languages.

Prograph took the concept further, introducing a combination of 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.

Prograph database operation. Method implementation
Prograph database operation. Method implementation

In Prograph a method is represented by a series of icons, each icon containing an instructions (or group of them). Within each method the flow of data is represented by lines in a directed graph. Data flows in the top of the diagram, passes through various instructions, and eventually flows back out the bottom (if there is any output).

Several features of the Prograph 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 (indexA etc.) from the object using the getter operation (the unconnected getter output passes on the "whole" object), and then passes the extracted index to a sort operation. The output of these sort operations are then passed, along with a reference to the original database, to the final operation, update database.

Prograph operators and controls
Prograph operators and controls

The bar at the bottom of the picture represents the outputs of this method, and in this case there are no connections to it and 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. In the database example, all of the sorts could take place at the same time if the computer were capable of supplying the data. Dataflow languages tend to be inherently 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.

Loops and branches are constructed by modifying operations with annotations. For instance, a loop that calls the 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.

[edit] Execution

The integrated Prograph development and execution environment also allowed for visual debugging. The usual breakpoint and single-step mechanisms were supported. Each operation in a data-flow diagram was visually highlighted as it executed. A tooltip-like mechanism displayed data values when the mouse was held over a data-link when stopped in debug mode. Visual display of the execution stack allowed for both roll-back and roll-forward execution. For many users the visual execution aspects of the language were as important as its edit-time graphical facilities.

The most important run-time debugging feature was the ability to change the code on the fly while debugging. This allowed for a truly unique development approach allowing bugs to be fixed while debugging without the need to recompile.

[edit] Critique

Several problems with the Prograph system are also evident in this method implementation, although perhaps they are not obvious to someone unfamiliar with the system.

The vast majority of Prograph's own code was left unlabeled. Even if one did take the trouble of opening the method in question, it typically had no labels and was generally useless for trying to understand how to hook it up. This made trips to the paper documentation far too frequent. However, if you believe that the data flow diagrams are self documenting, then the lack of typical documentation makes sense.

Prograph is based on the concept of using icons to represent operations. Yet many icons simply do not translate well into familiar programming terms, and in other cases some particularly obvious possibilities are not used. Consider the getter operators in the database method above; how does a rectangle with a notch in it imply 'get'? Since the images were often not obvious, they simply became one more type of jargon to learn, neither simpler nor more difficult than a text-based language. Of course this is no more difficult than the "." operator in C when accessing fields in a structure or "->" operater when acessing the fields in a pointer to a structure in C or C++.

Much more annoying was that the wiring could not be routed to clean up diagrams. In this instance one, two of the paths cross because one of the wires from the input bar must flow to a certain (unlabeled, of course) input on the update operation. Typical program methods often turned into spaghetti code that would make traditional text-based programmers wince.

Another problem was a profusion of windows. When moving around the Prograph workspace, the IDE generally required a new window to be opened to see the contents of methods. A simple upgrade would be to offer some sort of "open in this window" functionality, a more browser-like operation.

[edit] See also

[edit] External links

In other languages