There is no language lower than C++

  • Article

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.