Most programmers who have had any experience with visual programming would agree that it is a fine idea. A fine idea for somebody else, some would say, but a fine idea. It's not a new idea; visual programming dates back at least to 1946, when Herman Goldstine and John von Neumann put it forth as a model of programming. It's arguably as old as that other visual technique, flowcharting. It's been around a long time. The idea, that is. Implementations of that idea are something else again. Some programmers, no doubt the same wits who would say it's a fine idea for somebody else, would claim that visual programming today is nothing but an idea. But that's demonstrably wrong; there are plenty of visual-programming languages (VPLs) around, or at least they claim to be visual. Some are even named Visual Something-or-Other. But most VPLs get faulted for losing their visual nature when you get to the guts of the program. They are visual only when functioning as interface builders. That's not really the idea.
The basic idea probably occurs to every programmer at some point. You write your thirty-fifth flowchart and it occurs to you that it would be peachy if you could stop there. Compile the flowchart and run it. That was pretty much Goldstine and von Neumann's idea. Or, you sketch the structure of your program on the back of a Denny's place mat, and as you fold it up with the mustard blot on the inside so it doesn't stain your shirt pocket, you realize that essentially the whole program is there in that sketch, that all that remains to be done is to implement it; and you think, not for the first time, that somebody ought to write a place-mat compiler.
Place-mat compilers. Executable flowcharts. That was Goldstine and von Neumann's idea. Today, the visual programming idea is more likely to be framed in object-oriented terms, flowcharts being sort of dated. That's nice, because an object-oriented visual programming language seems more natural, more realizable, than a procedural visual programming language. The structure of a program written in C++ is inherently more visualizable than the structure of a program written in 1960s-vintage spaghetti-code Basic.
The object-oriented paradigm ought to make visual programming languages easier to design. That seems obvious.
But as obvious as the idea is, nobody seems to be writing that place-mat compiler for you. The visual-programming languages that exist all seem to have a hole in the middle.
It's like that classic S. Harris cartoon. A professor is standing at the blackboard, which is covered with equations. A bunch of equations on the left, a bunch of equations on the right. Linking them is the chalked comment in the center of the board: "...and then a miracle happens."
Visual-programming languages can look awfully good on the outside, but when you get to the inside, the visualness evaporates and they shrug and say, "...and then a miracle happens."
What's needed, apparently, is a VPL in which the V runs deep, in which the object-oriented structure of a program can be fully visualized and the visual aspects map fully onto the desired functionality. Then, too, it would be nice if the resulting visually designed programs were competitive with good C programs in speed and memory and disk-space demands, and so forth.
Is it possible that Prograph CPX from Prograph International (Halifax, NS) is that happy marriage of object orientation and visual programming?
Prograph has become hot stuff in the past year. Fans of the language, among whom you have to number Apple's Kurt Schmucker, are raving about it.
Speed comparable to C++ code, rather than to Smalltalk or compiled 4D. Truly clean and object oriented, yet viable as a production environment. Remarkably easy program development and maintenance. Lets you do things you simply couldn't have done before. Order-of-magnitude increase in programmer productivity. The C of the next decade. Those are the claims, not of the company, but of its most satisfied customers.
I've mentioned Prograph in this space twice before, but then I was talking about an earlier version of the language. The latest is reputed to be a radical revision.
The product was formerly just Prograph. Now it's Prograph CPX, the "CPX" meaning cross platform, they say. It's currently available for UNIX, Windows, and Macintosh, including native PowerMac machines, and has players for moving applications across platforms. In addition to cross-platform support, Prograph CPX now includes a complete application framework, object editors, and a project structure that lets multiple programmers work together simultaneously on a project.
The new features add a lot to the ease of use and power of the development environment. And it doesn't hurt that they cut the price last year from $1495 to $695.
But the basic appeal of Prograph CPX is the appeal of OOP inside a VPL. That's Prograph's message, and it seems to be getting across.
One sign of Prograph's growing influence is the fact that a healthy cottage industry has grown up to supply third-party development tools for Prograph CPX developers. For example:
The development environment of Prograph contains several distinctive visual features.
First, icons represent the components of a project. Each Prograph project consists of one or more Sections, each of which corresponds to a file on disk. The icon for a section looks like a cube viewed corner-on, and each visible face of the cube represents a different aspect of the section. There is a Classes face, a Methods face, and a Persistents face. Each face of the icon is separately clickable, to display the classes, methods, or persistents of the section. (There is also a text-view version of these multiple-part icons.)
Inheritance is represented by lines connecting icons for classes.
The multiple-part icon approach crops up elsewhere: Icons for classes have two sides, the Methods side and the Attributes side. Clicking on the Attributes side brings up a window in which the class's attributes and their values are listed. Clicking on the Methods side brings up a visual representation of the methods of the class. As with the Section icons, there is also a text-view version of these multiple-part icons.
The difficult thing is representing the methods, of course. It's easy to see how you can visualize objects using labeled icons, and how you can picture the inheritance structure using lines linking the icons. But making a picture of a method is the tough part.
Prograph uses data-flow diagrams.
The data-flow diagram for a given (universal or class) method consists of one or more cases. A case is, visually, a window containing an input bar at the top, an output bar at the bottom, and icons representing operations between. The operation icons have inputs and outputs connected either to other icons or to the input or output bars via datalinks, which are lines.
Operations can be primitives supplied with the language or external code, or they can be user defined. Allowed operations include: constant, accessing a persistent, producing a new instance of a class, getting and setting attributes, evaluating string and math functions and expressions, and controls and matches. User-defined operations are built visually by hooking up primitives.
Another visual feature of the environment is the ability to attach comments to icons, a feature common to many VPLs.
A nice feature of the editor is that third-party universal methods can be added to the editor's Tools menu by simply choosing the Install Tool item in that menu.
Finally, there is an interpreter as well as a compiler, so you can get immediate feedback on your designs as you implement them, but without the penalties that a strictly interpreted language imposes.
A few other points about the language: It's probably impossible for any language to be fully visual if it has to interface with other languages. Prograph lets you tie C or Pascal code into your Prograph applications, and naturally that C or Pascal code isn't presented visually.
The latest version includes a manual on developing externals. Externals can be either XPrims, external primitives written in C such that they can be called from Prograph, or XDefs, external references written in either C or Pascal and integrated into the Prograph environment via the Prograph C Interface or the Prograph Pascal Interface. Mac Toolbox calls are regarded as XDefs.
Having two types of externals means that you can bring in prewritten routines or use C for particular routines if you think it will give you an advantage.
At least the Mac version (the only one I've seen) has exceptional tools for interface building. There is a collection of over 100 Application Building Classes (ABCs) that let the developer build interfaces by drag-and-drop programming. The ABCs are supported by individual editors (ABEs) written in Prograph that include full source code, so you can customize them.
So is Prograph CPX the real thing? The real OOP VPL?
It's interesting that the programming model is not simply OOP, but OOP augmented by the dataflow model. One consequence: Operations are expected to operate when data arrives at their inputs. This leaves the flow of execution ambiguous in those cases where data arrives at the inputs of several operations simultaneously. In such cases, the Prograph interpreter chooses an operation at random from those ready to execute. It's possible to override this action, but it's the default behavior.
Whatever the ultimate judgment on Prograph, it will also be something of a judgment on VPL as a paradigm. Because Prograph pushes the paradigm hard. The visual nature of the language runs deep. The power of the language is significant; this is not a niche tool, but a contender for your primary programming language. The stakes are high, and if Prograph doesn't validate the visual-programming paradigm, its failure to do so could make the paradigm a harder sell in the future.
And if Prograph does validate the visual-programming paradigm, it could be a signal of where programming languages are going in the next decade.
Next topic: AppleScript, which I think has finally arrived.
I really ought to supply you with a smooth transition here, but I think I'd better owe you one. Because AppleScript is almost the opposite of what we've been talking about, nearly the antithesis of a visual-programming language. Apple not only didn't provide a visual-programming environment for AppleScript when it introduced the system-level scripting language, it barely provided a programming environment. The AppleScript script editor was it.
And there was another barrier to visibility with AppleScript: Its vocabulary included a core lexicon, extended by suites of application-category-specific words defined by vendor committees. There was no single place to look to learn the vocabulary.
With invisible languages, the more documentation the better. Enter Danny Goodman.
Danny Goodman wrote one of the most successful books on any programming tool, certainly one of the all-time best-sellers in the Macintosh area, in his HyperCard book.
In 1993, Danny turned his explanatory skills to AppleScript, producing an excellent general book on Apple's system-level scripting language. Recently, the second edition of Danny Goodman's AppleScript Handbook (Random House, 1993) came out, and this edition could be the real starting point for a lot of AppleScript scripters.
AppleScript has been around for several years, but it's been handicapped by lack of support from third-party applications and the absence of development tools. Advanced developers needed sophisticated editing and debugging tools, and more casual scripters needed a front end, something like HyperCard. AppleScript also lacked an adequate front end for users.
Without support from third-party applications, the power of AppleScript to let the user control applications from the outside and the power for applications to work together via AppleScript weren't realizable. Without the third-party support, there could be no market for AppleScript-based add-ons to existing applications. Without third-party support, AppleScript was just a tool for scripting the Finder.
And the Finder wasn't scriptable.
A lot has changed lately. Many applications now boast some form of AppleScript support, including most of the major applications. There are decent AppleScript editor/debuggers. HyperCard now supports AppleScript so fully that, thanks to the open scripting architecture, stack developers can program their stacks using AppleScript in place of HyperTalk. Since HyperCard can now produce standalones, this means that the stack developer who learns AppleScript can produce stand-alone applications embodying AppleScript functionality with a HyperCard interface. FaceSpan, distributed by Apple to AppleScript developers, is a tool that lets developers put a Mac-like interface on their scripts with less effort than programming in HyperTalk, and with less overhead than HyperCard. With System 7.5, Apple installs a collection of scripts under the Apple menu, making AppleScript look like something Apple actually expects people to use.
And the Finder is now scriptable.
Just as Danny's HyperCard book was, in effect, the documentation for HyperCard, Danny's AppleScript book is the documentation for AppleScript, and the second edition is a timely update. It doesn't require, but does assume, System 7.5. It has new chapters on scripting third-party applications: a chapter each on FileMaker Pro, Excel, Word, WordPerfect, MacWrite Pro, Touchbase Pro, HyperCard, and QuarkXPress, each chapter including useful scripts; plus a general chapter on what to think about in scripting third-party applications and a brief chapter on where to get help in working with third-party apps. There are new chapters on building user interfaces for your scripts, third-party scripting tools, and third-party scripting additions.
Scripting additions, or "OSAXen," are script components. Danny includes many of the best available OSAXen on the companion disk. In all, with the scripts from all the chapters of the book and the OSAXen, there are 235 files on the disk.
Danny's book also has a new chapter on scripting the scriptable Finder. It's solid information, but there's another book you're less likely to find on the bookstore shelves that may be more useful in scripting the Finder. Heizer Software (Pleasant Hill, CA) has begun publishing programming books, and the first out is Scripting the Scriptable Finder (Heizer Software, 1995), by Steve Michel. Steve is one of the most savvy and committed AppleScript scripters around. Happily, he's also a good writer. You may have seen his columns in MacWeek in years past, when MacWeek covered scripting better than it does now. Scripting the Scriptable Finder is the key to creating scripts that tame the Mac's operating system.
And that beast, having grown huge and out of control over the past ten years, can stand some taming.
Copyright © 1995, Dr. Dobb's JournalThe Visual Vision
A Visible Influence
There are also many independent consultants and code shops doing custom development using Prograph.What Vision Looks Like
Inner Vision
The Invisible Programming Language