"“Consider your project a Big Dig”
It needs to be ill-thought out, horribly inconvenient to everyone in the area, and go tremendously over budget?"
And kill innocent users.
Worst analogy ever.
What about D programming language http://www.digitalmars.com/d/ as a “better c++”?
"I’m gonna have to agree with JM. I’m dismayed at the generation of “programmers” brought up on java or C# who have no idea how computers work at all.
stuff like .NET breeds bad programmers."
Chris on August 30, 2007 07:16 AM
The pit of despair and the pit of success are one and the same (at least in programming).
Honestly, I have seen bad code in any language you can mention. Yes, depending on which language you are working in, you are likely to end up in a different kind of hell, but if you write bad code, they all lead down some pit of despair.
The belief that you can solve the problem of bad code by designing the perfect language is, IMHO, misguided. Memory management in C++ is not hard if you have a clue about how to program (RAII springs to mind), neither are most of the common problems you encounter in any other language.
The real problem is bad programmers. People who do not understand what they are doing and cannot seem to be bothered spending the time to learn their field and to keep up with it. Unfortunately that seems to be most of the people in the field.
How about, ‘the Valley of Success’. An easy saunter into a fertile, land of abundance…
Arrogance.
I direct this at the majority of responders of the “C++ is fine. lrn2code n00b” ilk.
Yes, C++ is a badass language and deserves respect, I don’t believe Jeff is debating that. He’s highlighting how easy it is to shoot yourself in the foot in so many different ways, if you DON’T KNOW know what you’re doing in C++.
And you’re all saying “Yeah, but it’s fine if you DO KNOW know what you’re doing.”
So tell me, how many years did it take you to get from DON’T KNOW to DO KNOW in C++. (And if you say you mastered C++ in 1 year I’d like to see what else you lied about on your resume.)
I’m just going to ballpark and guess it’s an order of magnitude longer to get competent in C++ safety than in C# safety. And in that time difference how many more features*, and tests, iterations, and overall quality improvements can the C# folks get safely out the door while you learned not to thrash the living hell outta memory.
And eventually once the C++ and C# coders are on equal footing skill and safety wise, how much are the milleseconds of execution time saved by the C++ guy worth compared to the amount of troubleshooting and extra “thinking through the plumbing” time incurred?
These comments smack of Jeff’s infamous fizzbuzz post:
http://www.codinghorror.com/blog/archives/000804.html
Where instead of commenting on the sad state that lots of Johnny’s can’t code at all and what we can do about it, we saw every code monkey and their uncle commenter try to prove that they can in fact code (a ludicrously easy program at that). Grats people, grats on your swing and a miss.
A very good post nonetheless.
-Andy
- We’re talking everyday Bus Apps here people, not graphics shaders or pacemaker timers.
Dear Jeff,
I think that all those people who’re blaming C++ for its “unsafety” are talking about “programming on C++ in C-style”. I mean, using manual memory allocation, printf-style functions, pointer arithmetic, longjumps and maybe even gotos. Actually, you can program on C++ in a very different way. You may use STL, Boost, the RAII concept and full power of strict type checking. It’s your choice.
The last program I wrote in C++ (~8 KLOC) has passed valgrind’s memory checking without complains–it means that there were no memory misuse.
C++ allows you to write “unsafe” programs. I think, there’s almost no possible way to write OS kernel or a driver in a “safe” way. But you’re not obliged to write your payroll program the same way an OS kernel is written.
Greg (the guy who designed Q),
Have you looked at the more modern implementations of BASIC? They seem to follow the design concepts you’ve listed.
I’ve been programming for a little or 5 years now as a hobby. I tried to start with C and ended up getting lost and confused. A QuickBASIC clone ended up teaching me all I needed to know about good programming practices and my short time with C kept me from relying on the garbage collection. Overtime I’ve grown to appreciate the simple complexity of C, however I still can’t get over having to include libraries and sticking a semi-colon at the end of the line so I guess I’m stuck with BASIC forever.
Wayne.
Wow. Not enough traffic, so you start a jihad against C++? Kidding!
I’ve been programming mostly C++ for about 12 years now, with the occasional bit of VB, and Perl. Quite frankly, I’ve never had problems with memory management. I don’t know what others have done that it causes them so many headaches, but I’ve just never had many problems with that.
So. I think a large part of this is a matter of attitude. I don’t want a language to protect me from myself. I don’t want a language that restrains me from writing bad code; I like writing good code and I don’t like writing bad code, so why restrain me from it?
I get the feeling that a lot of people don’t care that much about writing code well. I get the feeling that they’re really just concerned with getting the code written, not caring how ugly it may be. If you’re one of those people, and using Java or C# or whatever helps you write code that does what you need it to do right now, more power to you! But don’t rip me for choosing to use C++ just because you can’t use it safely and effectively. That’s sort of like ripping on someone who can drive a quad-axle dump truck because you can only drive a Toyota Camry with an automatic transmission.
I didn’t master C++ in a year. I still haven’t mastered C++ after 14 years working with it. BUT I can use it very effectively to write some very good code, and I think that’s a testimony to its power and flexibility.
C++ perhaps more than others is like a giant salt shaker with big wholes in the top. Sprinkle with care because sometimes you pour in more than you want or need. Just like too much salt, you can’t it take out so you have to throw it away and start over. Truly a salt pit of despair.
With C++ its always easy to fail, but living on the edge is quite exhilirating at times. So although I no longer write C++ everyday, I still spend a few days a month doing stuff in C++, just because of the thrill!
I just wrote something similar about a tiny program I recently wrote (systhread.net/texts/200708etucross.php). I was writing a small piece of software designed to fit into another software system. I had come across a change I needed to make and thought I might have to do some very serious voodoo to do something as simple as determine a file type. It turned out that the software system I was writing for already had the capability (and many more that I have not explored yet). The pit of success here would be learning to rely on the pre-existing software system
The right language for the right Job.
C++ = Great for Drivers, low level functions, app isolation
SQL = Good for data retrieval, transformations, storage
Texas Instruments BASIC = good for animating the letter ‘0’ around the screen ( as long as its in green and black).
Choose your battles developers, don’t let them choose you…
Jeff,
Your lettering is all greyish fuzzy can you fix that please ?
There are no pits of success. It’s one of those second-law-of-thermodynamics things: they just don’t exist, anywhere. Not in programming, not in any part of life. All pits are pits of failure. If you think you’re falling into a pit of success, that’s just because you haven’t hit bottom yet.
Matthew Cuba: “I’m not all that wowed by JM’s “500-1000 lines of production code” comment. That really isn’t all that much code, frankly.”
Yeah sorry - I accidently left out “per day”. Over sustained periods of time (like 1 year projects). That is a substantial amount of code.
And if you keep up with certain open source projects, you’d recognise the names.
Is the Microsoft Common Language Runtime written in C++ ?
“A program written in C++ overruns an array… and an exception is raised by the O/S which kills the program.”
Except if you do what most people do - run without bounds checking. The problem isn’t applications getting killed, it is applications corrupting their own memory area and doing bad stuff as a result of that.
“Personally, I love these new-age languages; my salary just keeps going up”
And with the added knowledge I gave you above, your salary should keep going straight to the moon.
Some thoughts:
-
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. -
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).
- 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.
-
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.
-
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.