There is no language lower than C++


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.


Comments (15)

  1. anon says:

    This the story about Mortamer, Elvis, and Einstien? 🙂

  2. Brandon Bray says:

    Indeed, those are the names. I can’t resist making jokes about those names, so I avoid talking about them in public forums. 🙂

  3. I don’t think you can generalize programmers that easy. I fit into every condition for a C++ programmer you mentioned except reading ASM code. The only reason I don’t fit there is because I’ve never learned or used it. I fit into this C++ programmer model, yet I’ve never been exposed to C++ either. I can somewhat agree with what you’ve said because this filter seems to work for most, but remember those exceptions out there. 🙂

  4. Anonymous says:

    *I knew that this sounds stupid, but how many people were involved in building Microsoft Visual C++ ?

  5. Anonymous says:

    I knew that this sounds stupid, but how many people were involved in building Microsoft Visual C++

  6. Jason says:

    I just wanted to say that I glad that some people still see the power of C++ over other languages. Being a C++ programmer I understand the power this lanuage provides. I keep fearing the day that I might have to move to Java or C# ( the better choice of the two). I can’t help feeling that these languages (Java and C#) are more fragile programming lanuages and in general a step backwards in language design. I am glad that MS can see the power and has the vision to make C++ even more powerful and useful.

  7. Anonymous says:

    long lives c++ !

  8. C++ offers all kinds of useful stuff.

    The dreaded multiple inheritance. Sometimes interfaces just don’t cut it. (And no I don’t think multiple inheritance is harmful.)

    It can also interface directly with C code, global functions, permit inline assembly, handle lots of binary data (sometimes carelessly) interpreted as arrays of structs, etc.

  9. Terence Bower says:

    Surely assembler programming is MUCH lower than C++.

  10. dimitry says:

    Is C++ dead?

  11. Lowly C++ says:

    But many of the Assemblers are written in C/C++.

Skip to main content