DevSource: What do you think is important to understand about the universe of C++? What's changing about it... and what isn't changing?

Currie: The most important thing to understand about the universe of C++ is that it's not going anywhere. It seems like every time a new language is introduced, people start predicting the demise of C++, but it hasn't happened yet. In fact, C++ is more popular than ever. It is still the most used and taught language in academia, and many developers and organizations that previously adopted Java are now returning to C++. There are substantial amounts of existing C/C++ code, perhaps more than any other language, and extensive existing knowledge assets of C++ programmers around the world.

Combine that with the fact that C++ as a language is still just as relevant today as it was a decade ago, and it becomes clear that C++ will be a major programming language for a long time to come.

What's changing? C++ must be updated to include support for programming paradigms that have been recently accepted by the professional programming community. Specifically, C++ needs to have built-in support for many of the features of managed platforms like .NET, such as compacting garbage collectors, properties, security, and verifiability. The C++/CLI standard provides a C++ language syntax for targeting .NET or more generally the Common Language Infrastructure. Going forward, many of these concepts and syntactic features are likely to be adopted by the ISO C++ standard as well.

What's not changing? Extensions to the C++ programming model will continue to be backwards compatible with existing code. One of the great strengths of C++ is the wealth of existing code and knowledge. That will not be compromised by future additions to the language. The C++ language designers have always been careful to provide new features and additional complexity in a way that let developers completely ignore that complexity if they choose to. This is likely to continue to be the case for C++.

DevSource: Languages are just tools, and each has its appropriate use. For what tasks are C++, C#, VB, Java (and any others you want to add) the best choice? What makes each of those the right one for the job?

Currie: There are certainly some things that you can only do in subsets of these languages. In most cases, you can only do system level programming with C++, since it is the only one of these languages that currently has professional quality compilers that support native code generation. You can only do cross platform development with C++ and Java, since they are the only languages that have robust, enterprise quality tools and runtimes available on many different platforms. Aside from some of those high level scenarios, we could jump into a variety of specific problems and argue over which language provides the most power or flexibility or ease of use for any particular domain or for specific code patterns. This, of course, would be a waste of time.

There is a common theory that there are exactly two philosophies about programming language choice. One of these philosophies is indicated by your question. This philosophy asserts that languages are tools that have specific strengths and weaknesses and that the appropriate language should be selected for any given programming problem. The second philosophy asserts that language choice is akin to religious observation and that developers make significant monetary, time, emotional, knowledge, and other investments in a specific language. This forces the developer to consistently choose and believe their language to be best for all tasks, regardless of how appropriate that language might be as a tool for solving that specific problem.

I think that the truth is a bit more complicated than either of these philosophies would suggest. First, it's not really languages that matter. It's really all about the programming model. A programming model consists not only of the programming language but also the libraries, runtime services, and tools that are commonly used by developers. For example, C# programming is as much about the BCL, GC, AppDomains, NGen, and a variety of other .NET libraries, services, and tools as the core C# language itself.

For the huge majority programming problems, one .NET language's programming model is not so different from any other that language choice actually ends up being all that important from the language-as-a-tool perspective. Since the C#, VB, C++, and J# programming models are so similar in every non-language aspect and those non-language aspects dominate the programming model, all of these languages will solve most problems similarly well.

What about the language-as-a-religion philosophy? That's just a huge oversimplification. It's not that most developers actually feel that their favorite language is the best language for all applications. More often, they realize that they are most familiar with one language and that even when suboptimal from the language-as-a-tool perspective, it isn't worth investing in a new language to accomplish some small new task. This makes a lot of sense. It is expensive to figure out which language is optimal, learn the language to the level that you feel comfortable writing shipping code with it, learn the necessary libraries, learn any new programming model specific tools, and potentially adapt test scripts and build processes. It is rarely worth that level of investment.

When a customer asks me which programming language from Visual Studio 2005 to use, I usually suggest that they use the language they are already most comfortable with. That's not to say you should never use other languages. I would always suggest that you try to keep skills sharp in a variety of languages, because you never know who might make your language choice for you in the future (clients, bosses, etc.). I'd also suggest that developers should be much more willing to use a diversity of languages for internal tools that don't need to be of shippable quality. Also, in the future, the Visual Studio languages are likely to diversify a bit more so that the class of obvious language choice circumstances (like the system programming and cross platform examples above) expand to include a broader variety of scenarios.