6 ms·

> Of the billions of lines of C++, few completely follow modern guidelines, and peoples’ notions of which aspects of safety are important differ. I and the C++

> Of the billions of lines of C++, few completely follow modern guidelines, and peoples’ notions of which aspects of safety are important differ. I and the C++ standard committee are trying to deal with that If only people were perfect, then things would be perfect. There’s, what, 40 years of evidence to suggest that most people, most of the time, simply cannot write memory-safe C++ code (50 years if you count C.) Maybe we should continue the experiment for another 50 years, just to be really sure the language is the problem.

7e 3y ago
Programmer education, tools, language standards and best practices are all vastly different than 50 years ago. That's like pointing at a Ford Edsel and then claiming that modern humans can't make good cars.
- marcus0x62 3y ago
  I’m not pointing at a contemporary akin to Ford or Edsel. I’m pointing at people today using the latest versions of these tools today making the same class of mistake as someone might have made 4 or 5 decades ago. The tool is the problem.
  - moomin 3y ago
    Ironically, Margaret Hamilton _was_ able to produce a bug free program back in the 60s. However, no-one is seriously considering replicating her techniques because they (some of them, ant least) are way too expensive for modern software.
    - marcus0x62 3y ago
      1) The Apollo Guidance Computer software was not bug-free[0] 2) The AGC software was not written in C++ The NASA approach to software development undoubtedly results in high quality assurance, but at a huge productivity cost that most commercials shops could not shoulder. What do you do about the huge amount of software that needs to be developed that is too complex and cannot justify things like having 5 independent concurrent executions running two completely separate but functionally identical code bases tested by a completely independent adversarial test team? I’d argue you could start by using tools that don’t allow, let alone encourage, your programmers to make common mistakes with catastrophic consequences. 0 — see, for instance, https://ibiblio.org/apollo/Documents/COM-1.pdf https://ibiblio.org/apollo/Documents/COM-1.pdf
- pkulak 3y ago
  In 1958 35,000 people died on American roads. Last year, 43,000. So yeah, cars have gotten safer at about the rate that C++ has.
  - drewda 3y ago
    Just as what's damning to C++ is how its security track-record compares to other programming languages available today, it's how the US's current number of roadway deaths and serious injuries compares to other developed nations that is so embarrassing and depressing: > [I]n the last 30 years, the US has not kept pace with tumbling traffic death rates in Europe, east Asia and Canada. In 2021, as the US hit a 16-year high for fatalities, Japan and Norway posted the lowest number of road deaths since the 1940s. > The contrast is especially striking among so-called vulnerable road users, a category that includes walkers as well as those using bikes, scooters and wheelchairs. According to the OECD, pedestrian deaths in the US rose over 40% from 2010-18, more than twice the pace of any other member country (most of which saw a decline). https://www.bloomberg.com/news/features/2022-11-03/why-us-traffic-safety-fell-so-far-behind-other-countries https://www.bloomberg.com/news/features/2022-11-03/why-us-tr...
  - cbsmith 3y ago
    The rate of deaths has dramatically declined. A lot more people are driving, and they're driving a lot more.
  - shrimp_emoji 3y ago
    Hehe, but if you count "broken dependencies" as accidents/fatalities akin to bugs, it's way safer than all new languages by virtue of being too old/disorganized for a built-in packaging system. The left-pad incident was a 4,000,000-car pile up!
- heresie-dabord 3y ago
  An Edsel, 70 years later, still doesn't have seat belts, air bags, a crumple zone, and a crash-test rating. Almost all modern cars are better.
cbsmith 3y ago
> If only people were perfect, then things would be perfect. That argument doesn't hold up too well, considering that people are involved either way.
- marcus0x62 3y ago
  It’s been holding up pretty well for the specific memory safety guarantees offered by modern languages, and for a simple reason: if your language is unsafe and has a bunch of foot guns in it, all the users of that language have to be perfect all the time to avoid trouble. If your language provides a certain safety guarantee, the implementors of that guarantee have to be perfect, but at least you have a relatively constrained point to test, perhaps even something small enough to provide a formal correctness guarantee. You can’t do that writ-large with end-user code. The flipside, of course, is that language or tool problems have a much, much, larger blsst radius. Still, you can twist yourself into knots to try to claim otherwise, but the track records of these tools speak for themselves.
  - cbsmith 3y ago
    > It’s been holding up pretty well for the specific memory safety guarantees offered by modern languages That seems unrelated to whether people need to be perfect to avoid security exposures. In fact, it would seem to be in contradiction. > if your language is unsafe and has a bunch of foot guns in it, all the users of that language have to be perfect all the time to avoid trouble That's an entirely different argument, and depends on the semantics of "unsafe" and "foot guns". I think it's more than fair to say that having more protections in place allows for mistakes to avoid becoming vulnerabilities more often, but that's a different argument.
    - marcus0x62 3y ago
      > That seems unrelated to whether people need to be perfect to avoid security exposures. In fact, it would seem to be in contradiction. It seems to me to be directly related when modern languages make certain types of mistake impossible, imperfect though the creators of those languages are. > That's an entirely different argument, and depends on the semantics of "unsafe" and "foot guns". No. It is literally the same argument. People are imperfect, and will make mistakes (that are possible to make.) In the case of C++, we have decades of evidence that people will make memory-safety mistakes over and over and over again.
nradov 3y ago
Have we tried genetically engineering perfect C++ programmers? I feel like that might be possible in another 50 years.
- kazinator 3y ago
  If they don't have to be human, probably 10-15.

7e 3y ago

Programmer education, tools, language standards and best practices are all vastly different than 50 years ago. That's like pointing at a Ford Edsel and then claiming that modern humans can't make good cars.

marcus0x62 3y ago
I’m not pointing at a contemporary akin to Ford or Edsel. I’m pointing at people today using the latest versions of these tools today making the same class of mistake as someone might have made 4 or 5 decades ago. The tool is the problem.
- moomin 3y ago
  Ironically, Margaret Hamilton _was_ able to produce a bug free program back in the 60s. However, no-one is seriously considering replicating her techniques because they (some of them, ant least) are way too expensive for modern software.
  - marcus0x62 3y ago
    1) The Apollo Guidance Computer software was not bug-free[0] 2) The AGC software was not written in C++ The NASA approach to software development undoubtedly results in high quality assurance, but at a huge productivity cost that most commercials shops could not shoulder. What do you do about the huge amount of software that needs to be developed that is too complex and cannot justify things like having 5 independent concurrent executions running two completely separate but functionally identical code bases tested by a completely independent adversarial test team? I’d argue you could start by using tools that don’t allow, let alone encourage, your programmers to make common mistakes with catastrophic consequences. 0 — see, for instance, https://ibiblio.org/apollo/Documents/COM-1.pdf https://ibiblio.org/apollo/Documents/COM-1.pdf
pkulak 3y ago
In 1958 35,000 people died on American roads. Last year, 43,000. So yeah, cars have gotten safer at about the rate that C++ has.
- drewda 3y ago
  Just as what's damning to C++ is how its security track-record compares to other programming languages available today, it's how the US's current number of roadway deaths and serious injuries compares to other developed nations that is so embarrassing and depressing: > [I]n the last 30 years, the US has not kept pace with tumbling traffic death rates in Europe, east Asia and Canada. In 2021, as the US hit a 16-year high for fatalities, Japan and Norway posted the lowest number of road deaths since the 1940s. > The contrast is especially striking among so-called vulnerable road users, a category that includes walkers as well as those using bikes, scooters and wheelchairs. According to the OECD, pedestrian deaths in the US rose over 40% from 2010-18, more than twice the pace of any other member country (most of which saw a decline). https://www.bloomberg.com/news/features/2022-11-03/why-us-traffic-safety-fell-so-far-behind-other-countries https://www.bloomberg.com/news/features/2022-11-03/why-us-tr...
- cbsmith 3y ago
  The rate of deaths has dramatically declined. A lot more people are driving, and they're driving a lot more.
- shrimp_emoji 3y ago
  Hehe, but if you count "broken dependencies" as accidents/fatalities akin to bugs, it's way safer than all new languages by virtue of being too old/disorganized for a built-in packaging system. The left-pad incident was a 4,000,000-car pile up!
heresie-dabord 3y ago
An Edsel, 70 years later, still doesn't have seat belts, air bags, a crumple zone, and a crash-test rating. Almost all modern cars are better.

cbsmith 3y ago

> If only people were perfect, then things would be perfect. That argument doesn't hold up too well, considering that people are involved either way.

marcus0x62 3y ago
It’s been holding up pretty well for the specific memory safety guarantees offered by modern languages, and for a simple reason: if your language is unsafe and has a bunch of foot guns in it, all the users of that language have to be perfect all the time to avoid trouble. If your language provides a certain safety guarantee, the implementors of that guarantee have to be perfect, but at least you have a relatively constrained point to test, perhaps even something small enough to provide a formal correctness guarantee. You can’t do that writ-large with end-user code. The flipside, of course, is that language or tool problems have a much, much, larger blsst radius. Still, you can twist yourself into knots to try to claim otherwise, but the track records of these tools speak for themselves.
- cbsmith 3y ago
  > It’s been holding up pretty well for the specific memory safety guarantees offered by modern languages That seems unrelated to whether people need to be perfect to avoid security exposures. In fact, it would seem to be in contradiction. > if your language is unsafe and has a bunch of foot guns in it, all the users of that language have to be perfect all the time to avoid trouble That's an entirely different argument, and depends on the semantics of "unsafe" and "foot guns". I think it's more than fair to say that having more protections in place allows for mistakes to avoid becoming vulnerabilities more often, but that's a different argument.
  - marcus0x62 3y ago
    > That seems unrelated to whether people need to be perfect to avoid security exposures. In fact, it would seem to be in contradiction. It seems to me to be directly related when modern languages make certain types of mistake impossible, imperfect though the creators of those languages are. > That's an entirely different argument, and depends on the semantics of "unsafe" and "foot guns". No. It is literally the same argument. People are imperfect, and will make mistakes (that are possible to make.) In the case of C++, we have decades of evidence that people will make memory-safety mistakes over and over and over again.

nradov 3y ago

Have we tried genetically engineering perfect C++ programmers? I feel like that might be possible in another 50 years.

kazinator 3y ago
If they don't have to be human, probably 10-15.