3 ms·

Everyone makes mistakes, but not if the tools they use don't allow them to make them. Yes, if everyone working on it was perfect then you would be correct. Than

Everyone makes mistakes, but not if the tools they use don't allow them to make them. Yes, if everyone working on it was perfect then you would be correct. Thankfully this is not a requirement for any profession.

nineteen999 8y ago
Unfortunately there are a lot of scenarios where C/C++ are still the only practical choices. No other language even comes close to their ubiquity AND performance at the same time. I'm sure the day will come though. And there are those working on mitigating some of the worst issues with those languages, maybe someday they will bear practical fruit as well. https://github.com/Microsoft/checkedc https://github.com/Microsoft/checkedc
Moru 8y ago
New tools = New security bugs we still need to find. If you know your tools there is less risk that you produce security bugs. You know the sideeffects of all the commands and functions. If you use a black box and trust it fully, you will (unknowingly) find ways to make new security holes noone ever thought of before. I'm not saying that we should not innovate, just that we should not rush head first into the blue sky thinking everything is fine just because we use the new shiny thing where we can't make bugs ever.
- pas 8y ago
  Agreed. Though using conceptually better tools (parser generators) usually has real gains. (Even if it makes the system a bit more rigid. You usually can't just put an "if" in the middle of generated code. But this seems like a sane trade off.)
ken 8y ago
There are parts of some jobs where perfection is required. People working at height don't drop anything (and there are cases where safety lines aren't possible). Surgeons don't get to just say "oops, my finger slipped" when holding a scalpel near your heart. In "From the Earth to the Moon" [1], someone explains that the main problem of the Apollo 1 fire was that nobody thought to label that test "hazardous". Sitting on the ground was supposed to be safe. We should expect perfection when writing C code, but we should also be clear that writing C is a hazardous activity, and not to be taken lightly. My surgeon is a human being, so I don't expect him to never make a mistake, but he's also a skilled and careful professional, and I do expect him to never make a 101-level mistake while holding a scalpel. [1]: https://www.youtube.com/watch?v=J_HZr2otkg4 https://www.youtube.com/watch?v=J_HZr2otkg4
- Jach 8y ago
  I've made this point before too. Not only is perfection expected elsewhere, it's routinely achieved. Not always but routinely. My example is a Cirque Du Soleil performance. Seeing the routine lack of screwing up points to some actionable advice too: practice and train, study, have competence rankings.
- zozbot123 8y ago
  "There are cases where safety lines aren't possible" in programming, too, but such cases should be as rare as possible. Coding C/C++ software in this day and age (or software in any other language lacking extensive safety properties, for that matter) is the IT equivalent of working at height and without safety lines 100% of your working life, purely for shits and giggles.

nineteen999 8y ago

Unfortunately there are a lot of scenarios where C/C++ are still the only practical choices. No other language even comes close to their ubiquity AND performance at the same time. I'm sure the day will come though. And there are those working on mitigating some of the worst issues with those languages, maybe someday they will bear practical fruit as well. https://github.com/Microsoft/checkedc https://github.com/Microsoft/checkedc

Moru 8y ago

New tools = New security bugs we still need to find. If you know your tools there is less risk that you produce security bugs. You know the sideeffects of all the commands and functions. If you use a black box and trust it fully, you will (unknowingly) find ways to make new security holes noone ever thought of before. I'm not saying that we should not innovate, just that we should not rush head first into the blue sky thinking everything is fine just because we use the new shiny thing where we can't make bugs ever.

pas 8y ago
Agreed. Though using conceptually better tools (parser generators) usually has real gains. (Even if it makes the system a bit more rigid. You usually can't just put an "if" in the middle of generated code. But this seems like a sane trade off.)

ken 8y ago

There are parts of some jobs where perfection is required. People working at height don't drop anything (and there are cases where safety lines aren't possible). Surgeons don't get to just say "oops, my finger slipped" when holding a scalpel near your heart. In "From the Earth to the Moon" [1], someone explains that the main problem of the Apollo 1 fire was that nobody thought to label that test "hazardous". Sitting on the ground was supposed to be safe. We should expect perfection when writing C code, but we should also be clear that writing C is a hazardous activity, and not to be taken lightly. My surgeon is a human being, so I don't expect him to never make a mistake, but he's also a skilled and careful professional, and I do expect him to never make a 101-level mistake while holding a scalpel. [1]: https://www.youtube.com/watch?v=J_HZr2otkg4 https://www.youtube.com/watch?v=J_HZr2otkg4

Jach 8y ago
I've made this point before too. Not only is perfection expected elsewhere, it's routinely achieved. Not always but routinely. My example is a Cirque Du Soleil performance. Seeing the routine lack of screwing up points to some actionable advice too: practice and train, study, have competence rankings.
zozbot123 8y ago
"There are cases where safety lines aren't possible" in programming, too, but such cases should be as rare as possible. Coding C/C++ software in this day and age (or software in any other language lacking extensive safety properties, for that matter) is the IT equivalent of working at height and without safety lines 100% of your working life, purely for shits and giggles.