Wednesday, May 25, 2005

The Reports of Its Resurrection May Be Greatly Exaggerated

(With apologies to Mark Twain.)

There seems to be some opinion that the new version of Managed C++ is all that an a bag of Krispy Kremes. This may well be true - I've followed MC++ a bit, and they seem to have done a great job making this latest version a very powerful and elegant language. However, via Chris I see that at least some people think this means C# is dead. With that, I cannot agree.

See, technologies don't succeed because they're fast, or elegant, or powerful. If they did, Windows never would have made it to 2005. (Note, I'm not saying that it sucks. Just that it used to.)

No, technologies succeed for a whole bunch of reasons that have to do with psychology, not engineering. For example, did you program in C++ for three months one time without a debugger at a job you hated? If so, you'll probably have thoughts like, “I'll never program in C++ again as long as I live.” Even C++ had suddenly turned into something that looked exactly like C#.

The fact of the matter is, people really like C#, and - as far as I can see - are rarely unable to do what they want to with the language. The libraries come up short much more often than the language, but that's to be expected, as the sorts of things we want to do move higher and higher up the abstraction stack. And people generally see C++ as hard, truthfully or not. So my guess is that C++ may have gotten a whole lot better, but it probably isn't about to get a whole lot more popular.

If the new features that C++ is sprouting really were able to determine whether it would displace C#, we'd all already be programming in LISP.


  1. C++/CLI may or may not gain mindshare. If you dont want to use it then dont. But that is no reason to undermine other peoples hard work.

    And they stopped calling Managed C++ a couple of years ago. I smell FUD

  2. Actually, I'm not undermining anyone's work. In fact, I believe I imply that C++ is more elegant, faster, and more powerful than C#. My claim is merely that it won't matter.

    I (mis)used MC++ as a nickname for "C++/CLI". That was probably a mistake on my part, but merely one of terminology. Thank you, however, for the correction.

  3. Craig, so you don't see yourself preferring this kind of syntax? :-)

    System::Data::DataTable ^table = gcnew System::Data::DataTable();



    array<Object^>^ row = gcnew array<Object^>(2);

    row[0] = 1;

    row[1] = "Name1";


    for each(System::Data::DataRow ^ row in table->Rows)

    Console::WriteLine("{0}, {1}", row["ID"], row["Name"]);

  4. I give you faster and more powerful, but more elegant? If anything C++/CLI looks even more "like a comic-book character swearing" (Paul Graham) than regular C++. In terms of elegance C# wins hands-down.

    However, I think a bigger problem for C++/CLI will be the lack of a target audience. C++ is popular for programming "to the metal", creating the smallest and fastest programs possible. By definition this excludes .NET. On the other hand, if you don't mind the .NET overhead why not just use the simpler and prettier C# language?

    That seems to restrict the appeal of C++/CLI to those few tasks where you have to interface managed and native code. So I agree with your conclusion that C++ won't see a resurrection, though I think people are more rational about this matter than you seem to imply.

  5. Sean: That syntax is a *lot* better than MC++, and so close to C# that I can already read it quite easily. And to Chris's point, it's obviously not more elegant for the types of tasks that C# is already good at (although things like -> versus . is no big deal to me). But when you get into the realm of interop, then as you say, C++ has a more natural syntax for expressing powerful constructs. So it's either more or less elegant depending on the task. But either way, my point stands.

    As for whether people choose languages for rational reasons - then why didn't we all switch to Java from C++ when it came out? It would have given us basically the same environment we have with C#, but years earlier.

  6. Craig, all the people whose applications were covered by Java language and libraries (i.e. web programming) did switch to Java years ago. But Java was initially rather sluggish, and it's still very weak for Windows client-side programming (GUI support, Win32 access). That's why people continued to use C++ or vB in that area.

  7. Chris: your statement is demonstrably untrue. I'm not a GUI programmer, and I could have switched to Java for a good chunk of the work I did long before .NET surfaced in 2000.

    But leave Java aside: LISP is a very powerful language that has been around *forever*. Why haven't people switched to that?

  8. Well, maybe you're some kind of Java wizard but every single Java client app I've seen up to this day was sluggish, ugly, and feature-poor compared to native Win32 apps. And comments from professional Java programmers indicate that it's still rather difficult to get an acceptable GUI out of Java. Of course there are also those propagandists who simply claim it's all untrue and those awkward Java GUIs are just great. :)

    As for Lisp, similar problems: reputation for slowness, lack of libraries for virtually anything but text I/O. Additionally, you have the off-putting ((())) syntax, lack of infix operators (except with brittle hacks), an intolerably verbose OOP system, and a similar problem as with Eiffel: the choice of implementations is limited to either half-baked freeware or very expensive products by small companies (high initial investment, questionable support perspective).

    Personally I think you very much overrate expressive power as a rational reason for choosing a language. Virtually nobody really *needs* all the power of C++ or Lisp, certainly not badly enough to sacrifice ease-of-use (relative to the desired application area). In my opinion, the decision to choose ease-of-use is not irrational; the decision to choose unneeded complexity is.

  9. Actually, I was pointing out that for *non-GUI* Java tasks, Java was acceptable years ago. On the GUI side, I won't argue with you.

    As for LISP: "reputation" for slowness? :) Well, that one sort of supports my argument about choices being non-rational. Especially when you think about how most people approach optimization.

    Libraries, granted.

    Syntax is in the eye of the beholder (e.g. XML is great, but LISP sucks?)

    On the "lack of support" side, again, granted, although that one is a bit less of a factor, IMO. Not because libraries aren't important (they so are), but because all it would take would be a big vendor deciding to do it.

    But by now I'm not sure that we're disagreeing at all. Neither of us thinks that the new C++ means C# is dead, because we both think that there are reasons beyond raw power to choose a language. The ones you give are rational reasons not to pick C++, and for the most part I agree with them. I simply assert that there are nonrational reasons as well. If I seemed to imply that people chose language *solely* on the basis of nonrational factors, then I misstated myself - that is not my belief.

  10. I need to use a platform such as .NET or J2EE for software integration via Web services and other middleware. I need a procedural language with O-O extensions for numerically intensive applications. C++/CLI seems better suited for this purpose than C# or Java, in spite of its clunkier syntax. (I have thus far refrained from using managed C++, since that misgudied attempt to cram a round language peg into a square platform hole yielded a product that was as appealing as the prospect of removing your own gall bladder with a warm spoon.)

  11. In your case, it sounds like C++ is probably the best choice. And it will definitely be for others as well. My guess is that you're in the minority, though. Not that there's anything wrong with that: having a range of languages to choose from is generally a good thing.

  12. The stack semantics (which aids deterministic destruction without the need for weird constructs like the C# using construct), mixed mode compilation, STL.NET, managed templates - aren't all these reason enough for C++ guys to stick to C++ as their .NET programming language? Why move to C# when C++/CLI gives you everything C# does + a little bit more?