The work items distributed by the server can be anything you like besides filenames. The processing inside the client is the same bit you'd have to write yourself for you hadoop application. Hardly onerous, but very flexible.

Except that now the hardware can (realistically) support the volumes of data being processed.

The scale of things is relative. We didn't have as much data to process back then as now, but disks were smaller and machines slower and more expensive. But the trade-offs of monocultural versus flexible remain the same.

Transaction engines like CICS--the hadoop's of that time--could process prodigious volumes of data through a very specific small band of processing requirements, but couldn't handle the variety of general purpose programming requirements and applications that arose.

The same problem arises today with map/reduce. If you're requirements fit its way of working--datasets that are infinitely partitionable into fixed-sized chunks that each take the same amount of time to process and don't require feedback loops, you're laughing.

But, if your images can vary widely in size and so do not fit into the fix-sized chunks of HDFS; and processing times vary greatly with size--many image processing algorithms increase exponentially with the size of the image--then map/reduce scheduling algorithms get tied in knots.

You should check it out.

My needs, resources and pockets do not lend themselves to such.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Only once you have turned over your cluster to single purpose, Java-based HDFS monoculture. And if all your processing needs can be force fitted into that monoculture's way of working."

That is simply not true. Look into Hadoop streaming.

"My needs, resources and pockets do not lend themselves to such."

That's too bad. I am currently working for a company and we are in the process of replacing our traditional means of processing the extremely massive volumes of data we consume with Hadoop. It is beyond awesome. Again, you should check it out instead of making assumptions. Cheers! :)

Surely we both are, but you seem to act like even though you have not studied or tried Hadoop, you know everything about it. You assumed that just because Hadoop is Java-based, you cannot use other languages within it. You also seem to assume that you know better than Hadoop, and, if true, that is just being vain. Cheers! :)

Update: I guess my mistake was assuming you actually cared about new technology that Perl can be a part of.

Ada Lovelace for the palindrome
Albert Einstein for having smelly feet
Alfred Nobel for his contribution to battlefield science
Burkhard Heim for providing the missing link between science and mysticism
Claude Shannnon for riding a unicycle at night at MIT
Donald Knuth for being such a great organist
Edward Teller for being the template for Dr. Strangelove
Edwin Hubble for pretending to be a pipe-smoking English gentleman
Erwin Schrödinger for cruelty to cats
Hedy Lamarr for weaponizing pianos
Hugh Everett for immortality, especially for cats
Isaac Newton for his occult studies
Kikunae Ikeda for discovering the secrets of soy sauce
Larry Wall for his website
Louis Camille Maillard for discovering why steaks taste good
Marie Curie for the shiny stuff
Nikola Tesla for the cool cars
Paul Dirac for speaking one word per hour when socializing
Richard Feynman for his bongo skills
Robert Oppenheimer for his in-depth knowledge of the Bhagavad Gita
Rusi P Taleyarkhan for Cold Fusion
Sigmund Freud for his Ménage ā trois
Theodor W Adorno for his contribution to the reception of jazz
Wilhelm Röntgen for the foundations of body scanners
Yulii Borisovich Khariton for the Tsar Bomba
Other (please explain why)