At the time of my posting, your post had one upvote. Mine. I always upvote rational argument.

It's just a shame that your rationality broke down when you wrote:

Are you claiming that most Perl programmers are incompetent or lazy? Woo-woo! Well, laziness is a virtue, but this smells like the dreaded false laziness.

My assertion has nothing to do with incompetence nor laziness.

For those projects that need the kind of massive parallelism and/or distribution that your description alludes to:

For example, if we're talking about a highly-scalable data processing application, I might suggest using a database server rather than a disk file. This puts the data somewhere central, and a CPU farm can access it in parallel. If the database becomes your bottleneck, you can replicate it across multiple machines to divide the load.

And for which Perl's inherent strengths make it the tool of choice, *I* will be the first to recommend POE--assuming you don't beat me to it. I have my doubts as to the number of projects for which Perl and massive parallelism/distribution is applicable, but there are certainly examples--eg. Genomic Research. For this type of project, POE is the only game in town and I am in awe of you and your fellow contributors for it's development.

However, where I have a problem is when POE is advocated for solving the types of parallelism and asynchronous processing needed by the vast majority of projects that do not fall into the above category. A programmer needs to be able to sort an array of data whilst maintaining a responsive C/GUI. The data is already in memory--it was probably generated in memory--and it will never need to exist beyond the life of the program. Spawning a thread to do this is trivial, and an intuative extension of existing programming practices.

The idea that I have to create a database table, ship all my data into it, just so that I can read it back again sorted is a nonsense.

And that's the big point here. Like threads & processes, threads & POE are not competitors. Each has it's set of problems for which is a natural fit. And for each, there is a set of problems for which it can be bent and twisted to solve, but for which it is entirely the wrong tool. The problems, and my ire, arise when the wrong tool for the particular problem is advocated on the basis of 'religious zeal' and the NIH syndrome.

I maintain that for the large majority of small scale, in-process asynchronous processing tasks (in Perl), threads are a natural fit and the simple solution.