2 ms·

> It turns out that computing differences safely is actually quite hard for signed integers because of underflow, even in languages which support wrapping behav

by lisper 5y ago

> It turns out that computing differences safely is actually quite hard for signed integers because of underflow, even in languages which support wrapping behavior for them, e.g INT_MAX - INT_MIN is still going to be incorrect even. There just isn’t a trivial way to do this safely And that right there is a compelling reason not to use C or C++. If the language is so broken that it doesn't even let me subtract signed integers safely without risking shooting myself in the foot it is worse than useless in today's world because it gives me the illusion of programming in a high-level language when in fact I am not. When I want to subtract x from y, I want to be able to write y-x and have the language worry about the details. That is the whole point of having a high level language, to abstract away the low-level details and let you write high-level abstractions without having to worry about introducing bugs that could imperil your entire enterprise. C and C++ don't do that.

ncmncm 5y ago
This is the argument not to use computers at all. It is not persuasive. There is never a reason to use C. But C++ is a language for engineers. If you don't have the patience to do engineering, then you should not. If you have a need for engineering anyway, hire one.
- lisper 5y ago
  Part of engineering is choosing the right tools, and that means avoiding tools that have booby traps built in to their design unless there is a very compelling reason to accept that risk. C was a good tool when computers were much more resource-constrained than they are now and security was much less of a concern, but those days are long gone.
  - ncmncm 5y ago
    Part of engineering is understanding your tools, and not imagining they are other than they are. There is no risk when there is no delusion. A professional will always choose the sharpest tool, and respect it. There are no booby traps, only booby programmers.
    - 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 ago
        Demands 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 ago
        Engineering 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.

by lisper 5y ago

ncmncm 5y ago

This is the argument not to use computers at all. It is not persuasive. There is never a reason to use C. But C++ is a language for engineers. If you don't have the patience to do engineering, then you should not. If you have a need for engineering anyway, hire one.

lisper 5y ago
Part of engineering is choosing the right tools, and that means avoiding tools that have booby traps built in to their design unless there is a very compelling reason to accept that risk. C was a good tool when computers were much more resource-constrained than they are now and security was much less of a concern, but those days are long gone.
- ncmncm 5y ago
  Part of engineering is understanding your tools, and not imagining they are other than they are. There is no risk when there is no delusion. A professional will always choose the sharpest tool, and respect it. There are no booby traps, only booby programmers.
  - 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 ago
      Demands 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 ago
        Engineering 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.