|
I'd been arguing (for pretty much this whole thread) that C++ tends to encourage bad code. We then hit the point last page where I suggested a metric for programming languages based on whether their feature set encouraged clean code. It sounds like you're apologizing for C++ scoring badly on that metric by saying it gains C backwards-compatibility in return. Is that what you're doing?
Well, yes. It started off as a preprocessor. I still choose to judge it on its merits as a language. You're welcome to judge it on its history as a language instead, but I'll laugh at you.
I'm aware of that. And you misspelled "supplant" ;-)
Actually, no. I was thinking of template syntax and class declaration syntax. The couple of things you can do with C++ without classes or templates or operator overloading are kinda cool. I wouldn't take the extra space hit in return for default arguments to functions, and they're not done that well anyway, but they're not bad. Not excellent, but they *are* one of the early things that worked in a preprocessor. So I provide them historical slack, if not slack on actual execution (satisfied?)
Well, other than purify working right. And many profilers. And a bunch of memory debugging tools. But if "the exact same debugger and tools they were using before" is VC++, you're right. So yeah, if you only use your compiler and one debugger, you're probably golden. In that case, there's no such thing as a "reduced range of debugging tools" except "no debugging tools", though, so I can see why you take exception.
You seem to read a lot of my mental state into my random utterances, so would probably be hard for me to be crazier than you thought I was and still successfully use a keyboard.
The problem with giving the programmer "a few useful features" and letting him run with it is that he'll either hate them, in which case nothing will happen, or he'll like them and use them everywhere. It's that second scenario, the one where you bastardize the codebase by adding a second paradigm on top of the first one, that gets folks into trouble.
Do I think that people should redesign their whole codebase to add a few useful features? No. But I find that adding a few useful *language* features after the fact is usually a major inviation to trouble. I've seen it work, mostly, by adding callout to another language. Usually that means that most developers on the project only know one language or the other. There are at least well-documented interfaces between the two, but debugging anything cross-language remains a pain.
You can add features after the fact with an extra preprocessor, too, the way C++ used to work. SGI apparently does their arcane template-like data structure stuff that way. By and large, though, nobody does. Why do you think that is? My vote would be: adding features to the language, especially when you have a large existing codebase, is usually an invitation to trouble.
By contrast, switching languages entirely guarantees that you do *not* have a large existing codebase, one way or the other. Am I in favor of switching languages instead? Not usually. Usually I'm in favor of keeping your large existing codebase in the language in which it was written, or rewriting it pretty much entirely.
|