I hate oversimplifications such as ‘left brain – right brain‘ functionality, but sometimes there might be a grain of truth in them. Even though desktop computers moved away from being constrained to text over thirty years ago, the great majority of programmers still work in languages which are intensely textual, and often bind them further by choosing command-line development environments and antiquated anti-graphic editors such as Emacs and vi.
Visual programming, in which code is developed by manipulating graphical objects in a visual environment, remains an extreme minority sport, and is usually considered to be suitable only for teaching kids.
There are, though, several major implementations of visual programming languages, including National Instruments’ LabVIEW and the Marten version of Prograph. LabVIEW is capable of more general-purpose programming, but is primarily intended for lab test and measurement; it is also closed, proprietary, and costs an arm and a leg, well over £2000 a copy.
Marten is the current version of what started off as a research project in 1982 at Acadia University, Nova Scotia, blossomed into an award-winning Mac development environment in 1989, was ported to Windows in the late 1990s, and then faded into near-oblivion. More recently it has been revived as Marten, from Scott Anderson’s Andescotia. This runs well under OS X up to and including Yosemite, but is starting to have a struggle against Apple’s increasingly stringent security measures.
Marten/Prograph is thoroughly object-oriented, with classes, methods, and inheritance, and uses dataflow programming, whereby value data flow through its visual methods. An object is an instance of a class, which has class and instance variables, and a collection of methods.
In a method, data flows from the top to the bottom. Normally terminals on the top ‘shelf’ of the method diagram represent the inputs to that method. Data then flows from the top shelf through the intermediate processes, until it reaches the bottom. If there are outputs from the method, they are gathered by connections made to terminals on the bottom ‘shelf’ in the method. Order of execution is not prescribed, and can take place whenever data is available; this allows for inherent concurrency, and the potential to exploit multiprocessor systems without the need for language primitives.
Fuller details, and the current implementation, are available from Andescotia.
In its heyday, Prograph was not only novel and exciting, but highly productive. If you could break away from being code-bound and develop visually, it was an amazing tool. When debugging, for instance, you could see progress through the flow-chart within each method, and inspect data whilst it was being processed.
Inevitably some claimed it became ungainly when used to develop life-sized projects, leading to a maze of different methods. However the Prograph environment was written in Prograph, and current Marten apps often read more cleanly and far more orderly than equivalent projects in non-visual languages.
When Microsoft Visual Studio and related tools came along, some of us thought that others had finally recognised the potential of visual programming. Of course it turned out that the word ‘visual’ meant something very different from Prograph, and wasn’t visual programming at all.
Maybe one day someone will put sufficient resources into Marten or Prograph to make it a serious, big-time development environment, as it deserves to be. Until then, we’ll just have to sit tapping our keyboards at cryptic and error-prone code, just like it was back in 1983.