4 ms·

Blaming someone else for your own poor design decisions is cowardly and irresponsible. Better languages than C++ can easily be built on top of C. For example,

Blaming someone else for your own poor design decisions is cowardly and irresponsible. Better languages than C++ can easily be built on top of C. For example, Objective C is a better language than C++, also built on top of C. Implicit type conversions could have been eliminated by having a "use strict" mode for new files, as was done in Perl 5. C++ didn't do this because the designers didn't see implicit type conversions as a problem. In fact they dramatically expanded the number of types that could be implicitly converted to include all user-defined types, as I have just described. But I guess the evil C designers somehow forced them to do that? At what point do you start taking responsibility for your own mistakes? It's sounding a lot like "never". By the way, C++ could have had a module system too. Objective C does, and people are talking about adding one to C++. But then again, Objective C had good designers, not "I just work here" type people who blamed all their problems on the previous engineer.

pjmlp 11y ago
> For example, Objective C is a better language than C++, also built on top of C. Somehow I cannot agree that a language that has [] and @ everywhere, relies on the programmer to manually write retain/release, uses dynamic typing and keeps all C defects, has a better design. Remember Objective-C didn't had ARC in 1983. > But I guess the evil C designers somehow forced them to do that? At what point do you start taking responsibility for your own mistakes? It's sounding a lot like "never". Yes, when 100% compatibility with existing code is a design goal. > Objective-C does, and people are talking about adding one to C++. Objective-C modules is a work from Apple, relies on clang linker and wasn't part of the original language design. Likewise, the upcoming C++ modules require the implementation of new linkers. Both don't work with the UNIX linker model that Bjarne had to use. Just the C++ compiler was new. The linker had to be the system linker already in place. This is how name mangling came to exist. Languages that use modules and have their own linkers don't rely on name mangling.
- reality_czech 11y ago
  There are lot of "roads not taken" that would have been better than what C++ actually did. Clearly Bjarne could have implemented his own linker-- if Go, Rust, Objective C, etc. etc. can do it in a year or two, then Bjarne could have-- he's a big boy, after all. Even without rewriting the linker, you could create an informal module system the same way the linux kernel does-- by having well-defined and cleanly separated interfaces between modules which got linked into .a (library archive) files. Of course C++ failed to do this, either at the (nonexistent) module level, or even at the library level. C++ ABIs are a complete mess even to this very day-- it is effectively impossible for anyone but hardcore C++ gurus to know what changes to a class will break library compatibility. The best solution is to wrap your C++ API in a C API. Because C was a better thought-out and designed language, and can support stable APIs, whereas C++ can't.
  - pjmlp 11y ago
    > There are lot of "roads not taken" that would have been better than what C++ actually did. Clearly Bjarne could have implemented his own linker-- if Go, Rust, Objective C, etc. etc. can do it in a year or two, then Bjarne could have-- he's a big boy, after all. Then he would have failed to have zero friction with the tools being used at AT&T and no C developers would have "incrementally" adopted C with Classes, as C++ was known back in its early days. > Because C was a better thought-out and designed language, and can support stable APIs, whereas C++ can't. C++ was designed to support copy-paste from C code and use the same linkers. Everything that C can do, C++ can do exactly the same way.
unscaled 11y ago
It's not blaming someone else. Bjarne worked at AT&T Bell Labs, and once C++ caught management's eye and became more than his own personal project, 100% compatibility with C++ was a business requirement. Bjarne ended down expanding a huge effort to bring that down to about 99% compatibility, to avoid some of C's most insidious warts such as prototype-less functions, but compatibility was still a goal. That goal included semantic compatibility (C++ constructs shouldn't feel alien to C) and performance equivalence (C++ abstractions should have the same performance cost as C). That's why Objective C's good(?) design of strapping Smalltalk's syntax and semantics to C inside square brackets was never an option. Objective C containers not supporting C primitives would have never made it. And let's not forget that Objective C uses dynamic dispatch and must box primitive types, so it could never claim to be on par with C performance-wise.

pjmlp 11y ago

> For example, Objective C is a better language than C++, also built on top of C. Somehow I cannot agree that a language that has [] and @ everywhere, relies on the programmer to manually write retain/release, uses dynamic typing and keeps all C defects, has a better design. Remember Objective-C didn't had ARC in 1983. > But I guess the evil C designers somehow forced them to do that? At what point do you start taking responsibility for your own mistakes? It's sounding a lot like "never". Yes, when 100% compatibility with existing code is a design goal. > Objective-C does, and people are talking about adding one to C++. Objective-C modules is a work from Apple, relies on clang linker and wasn't part of the original language design. Likewise, the upcoming C++ modules require the implementation of new linkers. Both don't work with the UNIX linker model that Bjarne had to use. Just the C++ compiler was new. The linker had to be the system linker already in place. This is how name mangling came to exist. Languages that use modules and have their own linkers don't rely on name mangling.

reality_czech 11y ago
There are lot of "roads not taken" that would have been better than what C++ actually did. Clearly Bjarne could have implemented his own linker-- if Go, Rust, Objective C, etc. etc. can do it in a year or two, then Bjarne could have-- he's a big boy, after all. Even without rewriting the linker, you could create an informal module system the same way the linux kernel does-- by having well-defined and cleanly separated interfaces between modules which got linked into .a (library archive) files. Of course C++ failed to do this, either at the (nonexistent) module level, or even at the library level. C++ ABIs are a complete mess even to this very day-- it is effectively impossible for anyone but hardcore C++ gurus to know what changes to a class will break library compatibility. The best solution is to wrap your C++ API in a C API. Because C was a better thought-out and designed language, and can support stable APIs, whereas C++ can't.
- pjmlp 11y ago
  > There are lot of "roads not taken" that would have been better than what C++ actually did. Clearly Bjarne could have implemented his own linker-- if Go, Rust, Objective C, etc. etc. can do it in a year or two, then Bjarne could have-- he's a big boy, after all. Then he would have failed to have zero friction with the tools being used at AT&T and no C developers would have "incrementally" adopted C with Classes, as C++ was known back in its early days. > Because C was a better thought-out and designed language, and can support stable APIs, whereas C++ can't. C++ was designed to support copy-paste from C code and use the same linkers. Everything that C can do, C++ can do exactly the same way.

unscaled 11y ago

It's not blaming someone else. Bjarne worked at AT&T Bell Labs, and once C++ caught management's eye and became more than his own personal project, 100% compatibility with C++ was a business requirement. Bjarne ended down expanding a huge effort to bring that down to about 99% compatibility, to avoid some of C's most insidious warts such as prototype-less functions, but compatibility was still a goal. That goal included semantic compatibility (C++ constructs shouldn't feel alien to C) and performance equivalence (C++ abstractions should have the same performance cost as C). That's why Objective C's good(?) design of strapping Smalltalk's syntax and semantics to C inside square brackets was never an option. Objective C containers not supporting C primitives would have never made it. And let's not forget that Objective C uses dynamic dispatch and must box primitive types, so it could never claim to be on par with C performance-wise.