Programming language trends come and go. First, Java is the hot new language, then it’s Python, then Ruby steals the limelight, then it’s back to JavaScript. But the latest language darling is probably the last one anyone expected. Believe it or not, 2011 could be the year of C++.

Last week, the latest version of the ISO C++ Standard was approved by unanimous vote. It’s the first major revision of the language in 13 years. Now officially known as C++11, the new standard introduces features designed to make it easier to develop software for modern parallel processing architectures, including lambda expressions and new data types for concurrent computing.

Not that C++ really ever went away. With its older cousin C, it remains one of the most popular languages for systems programming and for applications that call for performance-intensive native code, such as 3D game engines.

Outside its specialized niches, however, traditional systems programming itself has fallen out of favor in recent years. Modern programmers have increasingly turned away from native compilation in favor of managed-code environments such as Java and .Net, which shield them from some of the drudgery of memory management and input validation. Others are willing to sacrifice some performance for the syntactic comforts of dynamic languages such as Python, Ruby, and JavaScript.

But C++11 arrives at an interesting time. There’s a growing sentiment that the pendulum may have swung too far away from native code, and it might be time for it to swing back in the other direction. Thus, C++ may have found itself some unlikely allies.

Native code’s unlikely champions include Google
Google is probably the last company you’d expect to be interested in native code. For years, it has championed the idea that the very concept of desktop software is obsolete. In Google’s ideal world, applications run exclusively in the browser — and it has developed Chrome OS to prove it.

Yet even Google recognizes that sometimes interpreted JavaScript isn’t enough. In past columns, I’ve covered Google Native Client (NaCl), the sandbox environment that allows the Chrome browser to download and execute native binaries to handle performance-intensive operations. It’s no idle experiment; Google shipped a new version of NaCl in the latest beta version of Chrome last week, and for the first time the technology is enabled by default. Rumor has it, too, that the Netflix streaming support Google quietly slipped into the most recent build of Chrome OS also relies on NaCl APIs.

NaCl isn’t Google’s only nod toward native code, either. The search giant’s Go programming language has been widely described as “Java-like,” but that’s only partially true. Syntactically it does resemble Java in some ways, but Go code does not run in a virtual machine; it’s compiled directly to native code. What’s more, Google has gone so far as to make sure that Go binaries can run not just on the desktop, but in the Google App Engine cloud computing environment as well.

Oddly enough, these moves put Google in harmony with its rivals in Redmond. As the world’s largest desktop software vendor, Microsoft has always been friendlier toward C++ than many companies. In recent years, however, native C/C++ developers have felt somewhat marginalized as Microsoft directed most of its energy toward C#, its managed-code C derivative for the .Net platform.

But that appears to be changing. Visual Studio 2010 already supports most of the features of C++11. In July, Microsoft launched a new video series on its Channel 9 developer website called “Going Native,” dedicated to native-code development with a particular emphasis on C++. Meanwhile, astute observers have noticed a distinct lack of .Net-related hype leading up to Microsoft’s Build conference (formerly the Professional Developers Conference, or PDC) in September.

The natives are restless
Those of us who learned to program before the Java era will naturally appreciate a renewed interest in native code. Traditional software development methods have a long and storied history, and sometimes a well-optimized native binary is still the best way to wring the maximum possible performance out of a CPU.

That said, native code has its drawbacks. First among them are the security issues I mentioned earlier. Because languages like C and C++ allow developers to get closer to the bare hardware than they can with managed languages such as C# and Java, there are a lot more concerns to weigh, and inexperienced programmers can do a lot more damage.

Portability is another concern. For Windows developers living in a Wintel world, writing code that could compile on multiple processor architectures was never much of a problem, even in the old days. On the Unix side of the fence, however, it was a different story.

Now Google’s NaCl environment has reintroduced some of the same problems. Web developers are accustomed to their applications working in any reasonably standards-compliant browser, but NaCl modules are tied to specific processor architectures. To get the same module to run on x86, x64, and ARM processors, you have to compile three separate versions and host all three on the Web server. That will take some getting used to for developers raised on PHP and Perl.

But the most important thing to remember is to always choose the right tool for the job. No one wants to go back to the bad old days of wrangling text data for the Web using CGI scripts written in C. On the other hand, shoehorning every application into the same interpreted language or managed code environment, irrespective of the task at hand, isn’t the right way to go, either.

Modern computers are incredibly sophisticated, versatile, and powerful. To make the most of them, developers should have access to the broadest range of tools possible. The resurgence of native code is a welcome step in the right direction.


Related Posts:


Comments are closed.