Top Mud Sites Forum - View Single Post

angelbob · 03-26-2003, 02:59 PM

Your argument (Yui) that every feature is a good feature because it improves the expressivity of the language is interesting. Are you a massive fan of Perl for large projects for that reason?

My problem with C++ in practice has been that the average quality of code I've seen is terrible, even compared to similar projects in C. And the code I'm talking about is actually at professional software companies I've worked at. By "terrible" I mean "prone to crash/deadlock and hard to debug". The problems have been that different people use different subsets of the language, nobody knows the whole language, and you have to debug the code of people that use a different subset of the language than you do.

In a programming project that you control, you get to be the autocrat and spend a lot of time tearing misused or "wrong" (i.e. forbidden) features out of code other people submitted. As in a professional software environment, nobody reads the coding standards and nobody follows them, so you still have to go in and fix the results afterward.

Fair enough.

Goto is a fine example of the same principle. There are specific examples where it's basically acceptable. Palm (the company) used it for about the same purpose you list above, though with a couple more restrictions. Nonetheless, the vast majority of C code I've seen using "goto" is quite bad. Overall, its existence has done far more harm than good for the maintainability of the code I've seen in my professional career. In my private code I don't work on C++ projects with other people so it's a non-issue.

I'd like to again draw attention to the phrase I used above, the one that goes "nobody knows the whole language". C is a pretty snappy little language, and a clever fellow can figure out the whole thing and know the vast majority of the subtleties (what does "++bob++" do if "bob" is an integer? Is it legal? Which has higher precedence?) within a couple of years of regular use.

I've interviewed with a guy who was on the C++ ANSI standards committee. I've worked professionally in C++ for several years, and I've worked with many people who use it very regularly. I've built C++ parsing code, code to produce it from a template, debugged massive systems and worked under about four different template libraries in it at three different major companies. What I have never done, though, is to meet somebody with a very firm grasp of all the current standard language subtleties and how they work together.

By contrast, I've probably met about six people who could say that for C and who actually keep up with all the latest ANSI standards. Perl, like, C++, seems to have no full-on experts. It's simply too big, too varied and too weird.

Like you say, we could just rule out big chunks of the language and be an expert on the rest. If you believe that will work, you've worked on very different projects with very different people than I have. At least at the companies I've worked at and on the OSS projects I've worked on, you can't get people to follow the project's coding standards without constant and painful enforcement.

Though I suppose, if you had any significant number of contributors, you could just reduce your whole role to "constant and painful enforcement". That's what I've been doing primarily on my project lately -- and I'm using a simpler, cleaner language than C++.

03-26-2003, 02:59 PM	#21
angelbob Member Join Date: Feb 2003 Location: Bay Area, CA, USA Posts: 39	Your argument (Yui) that every feature is a good feature because it improves the expressivity of the language is interesting. Are you a massive fan of Perl for large projects for that reason? My problem with C++ in practice has been that the average quality of code I've seen is terrible, even compared to similar projects in C. And the code I'm talking about is actually at professional software companies I've worked at. By "terrible" I mean "prone to crash/deadlock and hard to debug". The problems have been that different people use different subsets of the language, nobody knows the whole language, and you have to debug the code of people that use a different subset of the language than you do. In a programming project that you control, you get to be the autocrat and spend a lot of time tearing misused or "wrong" (i.e. forbidden) features out of code other people submitted. As in a professional software environment, nobody reads the coding standards and nobody follows them, so you still have to go in and fix the results afterward. Fair enough. Goto is a fine example of the same principle. There are specific examples where it's basically acceptable. Palm (the company) used it for about the same purpose you list above, though with a couple more restrictions. Nonetheless, the vast majority of C code I've seen using "goto" is quite bad. Overall, its existence has done far more harm than good for the maintainability of the code I've seen in my professional career. In my private code I don't work on C++ projects with other people so it's a non-issue. I'd like to again draw attention to the phrase I used above, the one that goes "nobody knows the whole language". C is a pretty snappy little language, and a clever fellow can figure out the whole thing and know the vast majority of the subtleties (what does "++bob++" do if "bob" is an integer? Is it legal? Which has higher precedence?) within a couple of years of regular use. I've interviewed with a guy who was on the C++ ANSI standards committee. I've worked professionally in C++ for several years, and I've worked with many people who use it very regularly. I've built C++ parsing code, code to produce it from a template, debugged massive systems and worked under about four different template libraries in it at three different major companies. What I have never done, though, is to meet somebody with a very firm grasp of all the current standard language subtleties and how they work together. By contrast, I've probably met about six people who could say that for C and who actually keep up with all the latest ANSI standards. Perl, like, C++, seems to have no full-on experts. It's simply too big, too varied and too weird. Like you say, we could just rule out big chunks of the language and be an expert on the rest. If you believe that will work, you've worked on very different projects with very different people than I have. At least at the companies I've worked at and on the OSS projects I've worked on, you can't get people to follow the project's coding standards without constant and painful enforcement. Though I suppose, if you had any significant number of contributors, you could just reduce your whole role to "constant and painful enforcement". That's what I've been doing primarily on my project lately -- and I'm using a simpler, cleaner language than C++.