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.
My comments below apply to ADAMS, the workflow system that I developed and which we use for data processing and predictive modeling in production environments.
But they have severe limits, as you discover when you try to use them for anything complex. How do you debug the thing?
ADAMS allows you to debug a flow. Either by setting breakpoints and/or stepping through, operator by operator. Allows you to inspect variables and other things.
How do you do a diff?
Simply diff the text file that describes the workflow.
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?
Source code and workflows are under version control. Unit tests for operators/workflows. Updates to the operating system can break your scripts, with options deprecated, output changed etc. Not safe from getting broken.
How do you collaborate among multiple contributors?
Version control.
In other words, they work best in application areas where they don’t have to be full programming languages.
They can be. ADAMS allows you to add scripted operators using jython or groovy. Useful for initial prototyping or one-offs.
Which brings us back to the automation issue: you still need text-based commands and scripts to be able to automate repetitive tasks.
They all have their place, something I never discounted. Cheers, Peter