Apple's concurrency tools won't change the world
Disclaimer: I'm not a Premier or Select member of Apple Developer Connection, so I don't have direct access to developer documentation on Grand Central. Even if I did, I would be bound by a nondisclosure agreement not to talk about unreleased Apple technologies. Everything I know about Grand Central comes from leaked reports and other online sources.
From what I understand, however, Grand Central defines a number of APIs that allow programmers to define tasks, "dispatch" them to the OS, and monitor interprocess communication via event queues. Furthermore, to facilitate Grand Central, Apple has extended its Objective-C language to include support for closures, which makes it easier to implement control structures that support concurrency. It's a one-two approach that builds concurrency into the OS internals and the accompanying language and developer tools alike.
That's all well and good, but it still implies a sea change away from programming practices that have served the developer community well for the last 20 years or more. Grand Central will make it easier to write parallelizable software, but it's not any kind of fairy dust that will allow existing software to take advantage of multiple cores when it couldn't before. Developers will still need to change the way they think to write good concurrent software, including picking up practices from the world of functional programming (such as closures). As the saying goes, you can lead an old dog to water, but you can't make it ride a horse.
Apple isn't the only company working on developer tools to support concurrency. Also this week, Microsoft officially debuted Axum, a language for developing parallel applications on the .Net platform. And Sun Microsystems is developing Fortress, a language built from the ground up to support concurrency. But the problem with such solutions is that they're built specifically with concurrency in mind, and not as general-purpose programming languages. Merely using them implies that the developer is making concurrency a top priority -- and sometimes that just isn't the case.
Concurrent code: Is the tail wagging the dog?
In the ivory tower of enterprise-grade server applications, scalability and concurrency are accepted best practices. Not so on the desktop, however, where powerful, high-end software must share the limelight with a motley assortment of utilities, gadgets, and amusements. It makes sense for a database server to be highly concurrent, but what about a Facebook client?