A very shallow argument. The author doesn't take into account realities of most companies out in the marketplace. I'm exaggerating of course, but not every company is like Google which can afford to hire Ph.Ds to write high performance code for distributed systems. In a typical mid-market business (500-5k employees), if the company can afford it, the IT dept. is staffed with "Bob"s from accounting who started programming using scripts in Excel and then moved on to basic Java. These aren't the people who know about lambda calculus, Petri nets or even nuances of ORM. So for them, a workflow product that works well in a distributed environment, e.g. supports a range of databases, web service integration, long running processes, asynchronous invocation is a huge time saver and productivity boost.
You're assuming your conclusion. Obviously, a product that dramatically simplified programming to the point where anyone (or "Bob") could do most of what they need, would be valuable. The question is whether these products really do that, or merely appear to.
>Obviously, a product that dramatically simplified programming to the point where anyone (or "Bob") could do most of what they need, would be valuable.
You are attacking a strawman :) My claim pointed out specific types of problems that are solved by workflow software, and solved in substance, not in form.
>supports a range of databases, web service integration, long running processes, asynchronous invocation
those are specific examples of problems that a workflow product would address and consequently a programmer wouldn't need to spend time on building from scratch.
>>The class of programs encompassing those things is enormous.
Heh. Welcome to the real world.
If you'd like to call them buzzwords, I don't care, it is your prerogative. They are what they are. People who have done workflow software know what they mean. If you were to spend some time on Google you'd get a sense of the meaning too.
