At the PDC, I was part of a panel that answered questions on the future of programming languages. Naturally, I represented C++. I also have a passion for functional programming languages, so I'm certainly a fan of Erik Meijer who was the moderator. (We had a rather late night at the country bar near Universal Studios the night before the panel if anyone at the panel was wondering. J)

Perhaps the most talked about message from the panel was my summary that "there is no language lower than C++." (I'll have some evidence to back this up later in this writing.) Some people have interpreted my unbridled enthusiasm for claiming that C++ developers are the smartest developers as a measure to rescue C++ from C#. Oddly, some people compared C++ to Visual Basic. It is quite amusing actually. I'm sure many people would find it interesting to have a behind the scenes look at how C++, C#, and Visual Basic compare each other.

First, the C++ language design team has made a point of not being in competition with C#. In many ways, the introduction of a language in the middle has helped Visual C++. Prior to the introduction of C#, there was a number of advanced Visual Basic users that needed to go to C++ to get there job done. Obviously, that's a tough leap. The low end of C++ isn't really a lot of fun if you're not really into programming. So, with the introduction of C#, the Visual C++ team has had the opportunity to focus more on the needs to advanced developers and those who know and understand C++. One example of this happening is the effort to make templates better in Visual C++ 2003 and to bring standards conformance levels to a more respectable level.

At the PDC, I was asked whether C# thinks they're in the middle. The answer is absolutely! A few years ago, the usability team at Microsoft developed personas for programmers in each of the languages. The Visual Basic developer was the "opportunistic programmer", the C# developer was the "pragmatic programmer", and the C++ developer was kind of guy who knew the whole system. Each of the personas were given names (yeah, I know I'm not telling you what they are) so that all teams could identify with the programmer for each language. What makes C# and C++ programmers different? Well, for one C++ developers are really multilingual developers. They use the programming language best suited for a task. A C++ programmer also tends to understand the whole system, and doesn't mind reading MSIL or assembly code. C++ developers also think in much broader contexts – they think about the architecture of the whole program, rather than just single pieces. C++ developers also tend to appreciate lower level components that can be combined to create simpler components. (It's really very difficult to create components with more utility from higher level components that have less utility). C++ programmers tend to think about performance more often, and understand the dependencies in their programs. C++ programmers try to maximize tools available to get things done more efficiently (be it, sed, awk, profilers, lint tools, perl scripts, etc.) C++ programmers will also build tools to get the job done when a tool is not available.

There is much to be said about what a C++ programmer can do. Obviously, not every developer would fit the mold of persona we developed. We were trying to make sure we built a product that was best suited for a more advanced developer and make that person productive. Every language has a goal of being productive, but different kinds of programming tasks have different demands and thus different ways of achieving productivity.

And of course one of the ways a C++ programmer is productive is that he is not blocked from going to a lower level programming style when necessary. Constantly, the C++ language design team has made an effort to expose everything the CLR enables. Three examples come to mind:

  1. A class should be allowed to be abstract and sealed. The CLS disallows global functions, so a library writer targeting many languages needs to create a utility class to contain static functions. A utility class is not meant to be a data structure, and thus it is sealed. Since all the functions in a utility class are static, it is abstract to prevent instantiation. The notion of abstract and sealed are orthogonal to each other, and while other languages disallow their combination (and in some cases have even introduced alternative ways of expressing the same concept), C++ allows it simply because the CLR allows it.
  2. The ".override" directive in MSIL is used to explicitly override a virtual function in a base class. Other languages expose this feature only for explicitly implementing an interface method. C++ provides syntax for getting to this CLR feature directly, and can be used in contexts other than explicitly implementing an interface.
  3. Properties and events really are a collection of functions. This means that different accessibility levels for get and set functions is possible, and it is also possible to bind delegates to the get or set functions.

Of course, it should also be noted that C++ has the ability to express things at a much higher level, and in some cases expresses concepts in a much more consistent, correct, and succinct manner. An example of this is destruction semantics in C++ that pretty much makes the Dispose Pattern unnecessary. I'd even say that this makes C++ a less fragile programming environment for large and long lived applications. I'll certainly spend time talking about this in more depth later.

As always, I view C++ as an enabling language. It provides a significant amount of power, and number of language tools to get the job done. The C++ language design team strives to make answers to "can I do this" questions yes whenever possible.