Falling Into The Pit of Success

blog
80

Some thoughts:

  1. C# is a nice, sleek car, and can get you where you want as long as you stay on the road. C++ is an off-road 4x4 and it can get you everywhere, even through the woods if you want it to. (Not my metaphor, but it’s a good one.)
    C++ is what it is. It has been and is being used VERY SUCCESSFULLY on many, many projects. If you want C#, you know where to find it.

  2. On thing that Jeff’s article claims (and Lippert’s essay hints) that “the C++ pit of despair” is a doomed place, full of evil hungry bears that will maul your previous project and cause it to fail. The “pit of success” will cause it to succeed.

However, the first and main lesson of Peopleware (based on their actual research, I believe) is that projects fail not because of technological reasons but because of PEOPLE reasons. As long as your programming language choice is good enough, your project can succeed or fail based on other criteria. This has also been my experience.

Is there some research that you can point me to that shows that C++ projects fail more than C# projects? Or succeeds more? My bet, based on what research I have heard of, is that no, it doesn’t much affect the success of failure of the resulting project (though it does affect the quality of the result).

  1. I like C#. I like it a lot. However it has its own warts. Why are events a keyword? It most definitely could be implemented as part of the framework, as a class.
    Why are “empty” events implemented as null? It’s like an empty list being implemented as a null object? Why should I have to check if an event is null all the time? Isn’t this a place where the ACTUAL LANGUAGE SPECIFICATION makes it easy for me to fail? Wouldn’t it be more robust for the compiler/framework/whatever to check that for me, in a thread-safe manner?

I am sure there are good reasons for this. REALLY GOOD REASONS. I give credit to C#'s designers. They are smart people who have done a mostly good job.

What annoys me is that Lippert doesn’t give the C++ designers and committee the same benefit of the doubt.
Just because Lippert can’t think of a good reason for a certain wart in C++, doesn’t mean a good reason for it does not exist. Give some credit to the people who design the language. They are smart. VERY VERY smart. Assume they are at LEAST as smart as you.

  1. I’d take an accomplished programmer who has invested a few years in mastering a language (ANY language, though C++ requires more time than I guess some others) than a bunch of junior programmers who think they can write good code because language X has an easy learning curve.

  2. I agree that API, tools, and languages should if possible make it easy to do the right thing, harder to do the wrong thing.
    I just think that this has to be balanced against other requirements.

When you balance it against, for example, C++'s primary tenant “you only pay for what you use”, it turns out that you have no choice than to allow the user to do the wrong thing.
That’s why ALL methods are non-virtual in C++ by default. That’s why a destructor has to be explicitly made virtual. Even if that means you might get a resource leak if you forget to make it virtual.