> >> 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?
> 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.