On Sun, 11 Sep 2016 12:21:41 +1200, Peter Reutemann wrote:
But remember what a computer is good for: it is good for doing tedious, repetitive tasks that humans are lousy at. But the only way to automate such tasks is via commands and scripts.
I do disagree a bit. Workflow systems are (often) graphical user interfaces that allow you to define complex (and repetitive) operations. These systems follow the unix philosophy of command-line utilities, by having lots of reusable components (aka operators) that do more or less one thing (but do it well). These operators you can then slot together into complex programs by only having to parametrize them. Once designed, they don't have to run through the user interface, you can have them running as background processes.
Sure. This is the old “graphical programming” idea that seems to be rediscovered every few years. The earliest example I can remember is Prograph on the Macintosh in the early 1990s--but then I think National Instruments’ LabVIEW (for laboratory instrument control) might have been earlier. Currently on various pieces of 3D software (including Blender) you have “nodes” for graphically defining intricate compositing processes and material characteristics. And there’s MIT’s Scratch and Google’s Blockly. But they have severe limits, as you discover when you try to use them for anything complex. How do you debug the thing? How do you do a diff? You made a change last week, and this week you discover that something has broken; can you figure out what you did to introduce the regression? How do you collaborate among multiple contributors? In other words, they work best in application areas where they don’t have to be full programming languages. Which brings us back to the automation issue: you still need text-based commands and scripts to be able to automate repetitive tasks.