3 ms·
The problem is that C/C++ has hijacked a common notation used to denote subtraction and used it to denote something that kinda sorta looks like subtraction but
by lisper 5y ago
The problem is that C/C++ has hijacked a common notation used to denote subtraction and used it to denote something that kinda sorta looks like subtraction but actually isn't, and then it provides no backstop for the situations where it isn't. The specification of the language explicitly allows anything to happen if the programmer screws up this thing that the design of the language actively encourages you to screw up. That is terrible engineering practice. The design of engineering tools, like anything else, needs to take into account the fact that humans are fallible and will make mistakes. Good design guides people away from making mistakes and minimizes the consequences when people make mistakes nonetheless (as they inevitably will). The design of C/C++ lures people into making mistakes by making something look like something it is not, and then it amplifies those mistakes into consequences that are potentially catastrophic, all in the name of efficiency. That might have been a reasonable tradeoff in the 1970s. In the 2020s not so much.
- ncmncm 5y agoDemands on efficiency are every bit as stringent today as in the '70s. Machines are faster, but we expect them to achieve even more. Clock rates have stagnated, but problem sizes have not. The failure modes of C and C++ ints are less bad than is typical of construction materials. The common mistake is hiring CS people and expecting them to think and act like engineers.
- lisper 5y agoEngineering is the art of making trade-offs between multiple competing concerns. Efficiency is one such concern but it is not the only one. Safety matters too. You can make aircraft more efficient by eliminating all of the safety equipment and redundant systems. That might have made sense for the Wright Flyer but no sane person would advocate that for a modern passenger airliner. If the subtraction problem were the only issue that might be manageable but it is not. It is just one example of a very long list of such problems. C and C++ are metaphorical minefields of gotchas, any one of which can result in a literal crash or a security breach, which in today's world can be every bit as damaging as a physical failure of a critical system. Actual examples of this occur on an almost daily basis. It is akin to trying to build a modern passenger aircraft out of wood and muslin. It really is unacceptable.
- ncmncm 5y agoYet, you would be happy to release a safety-critical system with only run-time type checking? Engineering is a discipline that requires years of study and supervised practice, not reducible to "the art of making trade-offs". Non-engineers hired to perform engineers' jobs like to make this sort of mistake. Management might not be able to tell the difference. Thence 737-MAX.
- lisper 5y ago> Yet, you would be happy to release a safety-critical system with only run-time type checking? https://en.wikipedia.org/wiki/Tu_quoque https://en.wikipedia.org/wiki/Tu_quoque To say nothing of the fact that your backhanded assertion is completely baseless. Also, C and C++ provide neither run-time safety nor compile-time safety, so you argument is a non-sequitur as well.