One of the things I like about programming is that it is a little too hard for human beings to do.

I’m serious. And I don’t think programming is the only task beyond our abilities. Playing chess is too hard too – no one plays with perfect skill. We can only approximate perfection in ballet. We don’t know the rules that will allow us to create compelling, well-conceived novels on a routine basis. I venture to say that every human activity worth doing is just a little bit beyond our capacity. That’s what makes the activities interesting to do and, often, to observe. That’s why they drive us to learn and practice, to challenge ourselves on a daily basis.

This may explain why there are no tic-tac-toe tournaments on television. The game is well within our abilities, and therefore boring.

That said, I think parallel programming is a level beyond ordinary coding. It’s way beyond our abilities.

In recent months I’ve read dozens of articles on writing code for parallel systems, especially multicore processors. I’ve looked at libraries and language extensions intended to support parallelizing everything from C to SQL. I’ve seen clever code rewrites that deliver impressive performance benefits.

From all this, I’ve concluded that writing parallel code is unjustifiably difficult. The first 20% of the job, the code that delivers 80% of the benefits, is simple enough. (Typically, it’s a matter of performing the same transformations that you would apply if you were optimizing the code for single-thread performance.) But the remaining optimization steps are too complex. They require us to think like CPUs, to work at a very low level while writing high-level code. There’s no way to do it without knowing just what the compiler is going to do to each line of code you write.

We’re missing deadlines already, as we focus on manifesting user requirements in working code. If we can add a “think like a compiler” stage to development projects the whole enterprise will grind to a halt.

And yet…the multicore processors are there. Extra performance is a tweak away.

The industry seems to think that the only way to wring optimal multithreaded performance out of advanced hardware is to change the way developers write code. But I’m convinced that’s a dead end. We can’t ask a generation of programmers to start second-guessing the way their compilers work.

No, the answer is to concentrate parallel-programming wisdom in a cadre of programmers who specialize in the task, who eat complexity for breakfast. These programmers should go to work for compiler vendors, and build their knowledge into the tools we use. That’s where insights about parallelization belong: not in our code, but in our compilers.

Compilers are already doing impressive optimizations for parallel programming. That’s the right way to proceed as we milk modern hardware for ever-increasing performance.

Web recommendation: Don’t view this page at lunch unless you’ve got a strong stomach. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He doesn’t get much sleep these days.

If you’re not doing parallel programming yet, just wait. Multicore processors and on-chip GPUs are already on the desktop. It would be criminal to let all those MIPs go to waste.

You may have started your parallel programming career with multiprocessor systems. Clusters and symmetric multiprocessing systems are commonly used as servers, and high-level task partitioning has wrung a lot of performance out of them.

The next wave of parallelism arrived with multicore processors. All the major CPU vendors are now delivering multiple cores on single chips. Your app won’t perform any better unless you use special libraries and algorithmic techniques to rewrite your code to take advantage of multiple cores. Tools to ease this process are now routinely included in vendors’ development systems.

A variant of multicore processing is now being implemented on GPGPU systems. GPGPU stands for “general-purpose computing on graphics processing units.” Now that hardware vendors are building chips that contain both general-purpose CPUs and GPUs on the same silicon, you can farm out certain kinds of tasks to the GPU. Researchers are finding that a wide variety of programming problems are vulnerable to the GPGPU approach, but you may not recognize your code once you’ve adapted it to the new architecture. Say goodbye to loops, and hello to arrays and vectors.

Parallel-processing features are creeping into even high-level languages (in which, thankfully, the compiler does most of the heavy lifting). So when it comes to parallel programming, the question isn’t if, but when.

Web recommendation: A blogger known as Numbergrinder has written a succinct critique of a common hiring practice. If you’re involved in enlisting developers to join your team, I’m an Engineer, not a Compiler is worth a look. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He’s coming down with a cold.

What does the future of software development look like? For the first time in decades, it appears that no one knows.

It used to be fairly easy to peek a few years into programming's future. Languages evolved according to a predictable path from lower to higher levels of abstraction. We incorporated objects, then visual development environments, then Web architectures, then managed-code platforms. Development methodologies and project-management philosophies approached with plenty of warning – it took no special insight to see them coming.

My subjective feeling – backed up by a few hours of earnest Googling – is that all of that has changed.

The future? Well, let's see. We have some broad agreement that development methods will become more agile, though we are not entirely sure what agility means. It seems clear that the future will be cloud-oriented, though every definition of “cloud” is different. Our code will need to adapt to the availability of parallel architectures, though we can't say whether the parallelism should or will reside primarily in the code we write, the libraries we incorporate, the tools we use, or the architectures we employ. Security, mobile platforms, portability, interoperability, declarative programming, functional programming...all are likely to be important. One way or another.

As for languages – oh my! At the moment it appears that every nontrivial app will incorporate modules, libraries, frameworks, and custom code written in multiple programming languages. Or maybe we'll resolve that complexity by adopting a new language with the flexibility to address all the challenges we face.

For once, the pundits are quiet. Search the net for predictions about the future of software development and you'll retrieve a list of Web pages that are years out of date and devoted to particular narrow problem or language domains.

We are in need of the same sort of paradigm-buster that object-oriented programming and visual development environments were, back in the Windows era.

Search long enough through all the partisan arguments and language-specific rants, and one name keeps coming up: Anders Hejlsberg.

Hejlsberg has been around the programming world since before the IBM PC. He is the original author of Borland's Turbo Pascal and Delphi, and since he joined Microsoft he has created C# and become director of Microsoft's programming-language strategy.

You can learn more about Hejlsberg and his views in these videos:

• Where are programming languages going?

• Trends and future directions in programming languages

• Tour through computing industry history at the Microsoft Museum

(Disclaimer: Hejlsberg's views are pretty much guaranteed to be the official views of Microsoft. I'm the last person to sign up mindlessly to Microsoft's view of the world. While I don't see the company as a customer-exploiting evil empire, neither do I think it has always acted in the development community's best interests. Although I owned and edited Windows Tech Journal, my relationship with Microsoft was always an arm's-length one – much, as it turns out, to my personal cost. But that's a long story for another day. What I'm trying to say is that you have a responsibility to take Hejlsberg's point of view with a grain of salt.)

I think the Hejlsberg videos have great value. They identify both the challenges facing our community and some of the technologies and approaches that will help us address them. Hejlsberg has proved himself to be a visionary throughout his career, and he is uniquely positioned to see the problems and possible solutions that we will encounter in the next few years.

What's your view of the future? Drop a keyword or two into the comment section below and I'll use your feedback to shape a future post. Because ultimately, the future isn't something that just happens. It's something we create. Together.

Web recommendation: Research for this post brought me for the first time to Microsoft's MSDN Channel 9. This Web site contains hundreds of videos about (Microsoft) technology and how to get the most out of it. There's a predictable amount of corporate flag-waving, of course. But there's also tons of useful content. I have some reservations about video as the medium for dispersing such information – text is more readily searched and recalled, in my view. But there's no denying that there's real value here, for free. And the site has a mission statement you can dance to. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He recently relocated to a small town outside Belgrade – stop by if your travels take you through Serbia.

Last month, Forrester Research released a wave report about companies that provide elastic caching solutions. After speaking with Forrester in some detail, I'm convinced that the technology will become an integral component of application platforms -  both on premises and in the cloud. Now is the time to take notice.

Elastic caching solutions add scale to applications without requiring developers to re-architect applications, or add additional servers or virtual machines. That capability is especially critical in cloud computing, where data can become a bottleneck, and developers have to pay for what computing they use. "People talk about cloud computing being scalable, but data in a database doesn't scale easily," explained analyst Mike Gualtieri, one of the report's authors. "Data is locked into one database, and can't shard across databases without a redesign. Caching can help scale data across multiple instances [of an application]. Microsoft's decision to fold its "Velocity" caching technology into Windows Azure was an astute acknowledgment of this problem, he added.

"People don't understand this yet, but this is actually a cloud story," Gualtieri added. "[Elastic caching] is one of the gaps to be filled in for scaling data in the cloud."

Some caching solutions have advanced the state of the art to where high-speed data analysis is possible through Map/Reduce techniques. In plain English, that means that work is taken to the data instead of moving data to work. That technique can help solve bandwidth problems that would otherwise occur when working with large data sets, Gualtieri explained. Both Oracle and ScaleOut Software, a company that specializes in creating in-memory data grids, have this capability. You may recognize Map/Reduce through its association with Hadoop, an open source project that takes a disk-based approach for working with massive amounts of data. Commercial solutions including Aster Data work much the same way - with varying degrees of performance.

While using all memory is seen as being less economical than a disk-based approach on a very large scale, using Map/Reduce to apply a method on objects/namespaces in an all memory grid creates new opportunites in e-commerce, finance and other applications that require instant (and fault tolerant) data analysis.

Industry heavyweights including IBM, Oracle and currently dominate the elastic caching market, according to Forrester's weighted assessment based on technology and strategy. Newcomers GigaSpaces and Terracotta are likewise listed as leaders. The report also highlights several smaller players as being strong contenders including Gemstone on the Java side, and Alachisoft and ScaleOut Software on the .NET side (although ScaleOut supports both platforms). Oracle, through its acquisition of Coherence, and Gigaspaces originated the category.

Gemstone was recently acquired by VMware, TIBCO is entering the market with a product called "ActiveSpaces," and Terracotta is a possible acquisition target for Red Hat, which is also entering the market, Gualtieri noted. While it has developed its own caching technology, Microsoft's Velocity is not as robust as its partners' solutions , he said. Microsoft traditionally leaves room for its ISV partners to make money, but could realistically acquire either Alachisoft or ScaleOut, he added.

I've spent many hours examining documents that Microsoft had produced about its Midori OS incubation project, and became very familiar with its concepts. Over time I've seen several Midori ideas implemented in .NET: a more efficient runtime (Silverlight), its programming model (F#), and began to think of Windows Azure as a potential vehicle for delivery. Google has developed new legacy-free techonlogies for dealing with distributed concurrency such as "Go," which breaks from C/C++. Microsoft could up the ante with Midori.

That said, I'm not certain about the project's current status. The company is working on other projects to deal with concurrency at the OS level, and I've been told by insiders that it has many incubations in the works. Midori was differentiated from those, because Microsoft placed the project under the jurisdiction of executive Eric Rudder and began recruiting allstar programmers to the project. Either way, it has determined that it cannot tackle the challengies of concurrency (devices, cloud, on premise, many-core) by evolving its existing technoolgies.

My colleague Jeff Feinman just published a story about new Intel parallel programming tools. In it, he mentioned that Intel bought out RapidMind, which also helps scale applications running on many-core processors.

RapidMind was a stand out at some of the trade shows that I attended; it produces software that creates a layer of abstraction intended to make parallel programming easier. Its software worked on a number of different processors and was not tied to Intel technology, and it is my sincere hope that it stays that way. One of RapidMind's biggest selling points was that it is an alternative to vendor tools and SDKs that may lock developers into a specific hardware platform.

Intel has been very innovative developing parallel tools for its platform. Intel's Parallel Studio tackles some of the complexity that parallel programming introduces, helps developers avoid common mistakes, and most importantly, cuts down on the time it takes to develop parallel applications. RapidMind's technology will no doubt complement the work Intel has already done, but Intel shouldn't drop RapidMind's core products just to absorb its technology.