Contrary to a few dozen e-mails we've received, we are not against Apple's Grand Central Dispatch. We are not against black box parallelism and we're not against single-source-single-vendor end-to-end parallelization solutions. It's just that in some cases we have unresolved questions (e.g. Grand Central Dispatch's approach to modularity), in other cases we want to believe but it's just not working for us yet.We haven't given a thumbs down on any of these technologies. As a matter of fact we're firm believers in using the right tool for the right job. But herein lies the rub. Our jobs (the software projects we're involved in) tend (at least recently) to be large scale (or complex small scale), multi-paradigm, multi-language, multi-operating system projects. We've looked but haven't been lucky enough to find the one right tool or silver bullet. We find ourselves gluing together multiple GUI frameworks, communications libraries, database call interfaces, multiple math and numeric libraries, multiple container hierarchies, and all kinds of proprietary class libraries. Each one having its own weird approach to multi-threading, process spawning, pool management, memory locking, and inter-component communication. Can't we all just get along?

If you're lucky enough to have an application where you can deploy a single model of concurrency from the ground up using a single vendor, one threading library, a single language, and a single operating system then yahoo and by all means pick the easiest route and go. But some of us are not so fortunate. We have to deal with integrating class libraries and function libraries that have conflicting models of parallelism, memory management, process management, and thread management. We won't mention how they all apply same terminology differently. Should the producer of a class library or application framework hide the parallelism from the consumer? Does information hiding even work when it comes to parallelism? Should we have to even worry about the semaphores or mutexes used within the walls of some class or class library? If my GUI class library approaches threading in one way, my communications class library approaches threading in some other way, and my database class library approaches concurrency with some totally different approach should I have to worry about how they all behave in the same subsystem or application? Maybe it's just me and Tracey. But in all instances the answer has turned out to be yep. We have been bitten with countless namespace and compiling conflicts, memory management conflicts, resource management snafus, degraded performance problems, mysterious untraceable locking problems, scaling and load balancing issues from our worst nightmares. It gets worse once these subsystems and applications have been around for awhile and have undergone a few architectural changes. Yep we're always interested in hearing about the new "right tool" that is going to solve multi-threading and parallel programming complexity. Starring at the debugger, looking at 38 locked threads and having no clue why they should be locked, we really really want to believe in short cuts or some single vendor one-size-fit-all black box parallelism. But in the final analysis we know better.

To some our readers that have sent us e-mails about our multi-threading atheism, you have to understand we're down in the weeds with this stuff. We're stuck with integrating (supposedly) multi-threaded reentrant libraries that were developed a decade ago to newfangled multi-core schemes that were developed yesterday both with different underlying assumptions about the operating system. It's a dirty business with the capacity to produce skeptics very quickly. It's convenient from a vendor and installed-base-point-of-view to try to solve the parallel programming problem through a slow measured evolutionary approach (keep the old code in place but add black box parallelism) . And yes, this is going to work for a really big chunk of cookie cutter applications out there. But some of us are faced with multi-paradigm multi-modal multi-environment systems. We are facing some of the fundamental problems of complex systems theory. We need a paradigm shift from the design phase to implementation to the maintenance phase. Which brings me back to the ghosts of ICOT and the dreams of the fifth generation.

We're hoping for the best (Go Apple Grand Central Dispatch) but preparing for ... Well, we have been in contact with the ghosts of ICOT, there are some stones unturned.