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