3 ms·

Allow me to be contrarian Hard to count, but, excluding webapps, maybe 98% (or more) of generally used software has a basis in c/c++. Your fridge, watch, compu

Allow me to be contrarian Hard to count, but, excluding webapps, maybe 98% (or more) of generally used software has a basis in c/c++. Your fridge, watch, computer, car, phone. clang, gcc, photoshop, your browser, almost any desktop app, your 3d games. The remaining 2% (or less), is maybe even majority written in assembly, forth, etc, in your calculator and toaster So to agree with you, I would need an explanation of why such wispy benefits led to such a large effect Oberon existed, pascal, ada, they are excellent and safe, why then were they not popular? Note: Easy to disagree with that percentage, but the effect is enormous, and as far as I understand, not explained by the current bandwagon

Jtsummers 3y ago
Politics and price. C and Unix were free, other options were not. Oberon is also unsuitable for most use-cases if taken to Wirth's extreme, though the other variations are better they were still very niche (also it was never exactly well-known or well-distributed). With Pascal, which Pascal? The early Pascal's needed extensions (leading to the Modula line and Delphi ultimately). They also tended to cost, people like free. Politics are why Ada lost, along with costs. Ada, as a mandatory language for a time in DOD, had a compelled audience with "deep" (not always that deep) pockets who could afford $10k/seat licenses (or more), that didn't make it a suitable language for the *nix hackers of the 90s and Linux (in particular) has eaten the world. So C and C++ won out as the systems languages. Not because of quality, but price and politics. EDIT: I mean Unix broadly, there were obviously non-free commercial Unixes.
jerf 3y ago
That's not a contrarian take, because it's just not relevant. "C and C++ seem to work" is not the question at issue. Moreover, C and C++ are the world we live in in which CVEs flow like water, where our systems crash routinely, where we have the problems that are making us have this discussion in the first place. If you think this is all just fantastic, that there isn't any option of doing better, we just have to live with the effects of memory unsafety, and there's no point even trying to improve the quality of our base level tools, then honestly all I can say to such a battered spouse syndrome sufferer is that we're going to have to agree to disagree.
- tsegratis 3y ago
  This is an interesting reply Note that c/c++ can be made safe, for instance tcc adds runtime bounds checking. Memory could simply be runtime checked. Problem solved You make a good point as to why we don't. Ada has done exceptionally well at doing what you ask for a very long time. It is not hard. But we don't Hubris is maybe the right reply People deliver code without full line and fuzz tests: probability of code being correct; low-to-zero. This is independent of 'seems to work' c/c++ memory safety. It suggests the problem is deeper We just assume we're safe and correct, and know best; and then live as battered spouses of our own hubris Alternative POV: we allow sharp knives in kitchens. Kitchens are unsafe as a result. It is maybe unavoidable. Road safety causes more deaths than code safety. We allow it. A lack of safety is inherent in any complex system Spark, Coq, provers are great. But unbounded systems quickly become unprovable. Unbounded memory allocation is one of those -- whether 'safe' or not I think this is a major reason missing from the debate. Safety hinders and complete safety is completely impossible However the truth probably lies somewhere in the middle Since you are right: computers are fast enough that even 3d games could often have memory safety In conclusion The current memory safe languages remove more from the table than I think you expect; and that is why I would suggest most important software has been written in 'unsafe' languages For instance, servo arguably demonstrates that. A surprizingly small amount of firefox has been replaced by rust, and not due to lack of effort But also we simply don't care about correctness enough to get closer to it. So I would say it is good you ask for that But too often, to me, the debate looks like we swap one blindness for another

Jtsummers 3y ago

Politics and price. C and Unix were free, other options were not. Oberon is also unsuitable for most use-cases if taken to Wirth's extreme, though the other variations are better they were still very niche (also it was never exactly well-known or well-distributed). With Pascal, which Pascal? The early Pascal's needed extensions (leading to the Modula line and Delphi ultimately). They also tended to cost, people like free. Politics are why Ada lost, along with costs. Ada, as a mandatory language for a time in DOD, had a compelled audience with "deep" (not always that deep) pockets who could afford $10k/seat licenses (or more), that didn't make it a suitable language for the *nix hackers of the 90s and Linux (in particular) has eaten the world. So C and C++ won out as the systems languages. Not because of quality, but price and politics. EDIT: I mean Unix broadly, there were obviously non-free commercial Unixes.

jerf 3y ago

That's not a contrarian take, because it's just not relevant. "C and C++ seem to work" is not the question at issue. Moreover, C and C++ are the world we live in in which CVEs flow like water, where our systems crash routinely, where we have the problems that are making us have this discussion in the first place. If you think this is all just fantastic, that there isn't any option of doing better, we just have to live with the effects of memory unsafety, and there's no point even trying to improve the quality of our base level tools, then honestly all I can say to such a battered spouse syndrome sufferer is that we're going to have to agree to disagree.

tsegratis 3y ago
This is an interesting reply Note that c/c++ can be made safe, for instance tcc adds runtime bounds checking. Memory could simply be runtime checked. Problem solved You make a good point as to why we don't. Ada has done exceptionally well at doing what you ask for a very long time. It is not hard. But we don't Hubris is maybe the right reply People deliver code without full line and fuzz tests: probability of code being correct; low-to-zero. This is independent of 'seems to work' c/c++ memory safety. It suggests the problem is deeper We just assume we're safe and correct, and know best; and then live as battered spouses of our own hubris Alternative POV: we allow sharp knives in kitchens. Kitchens are unsafe as a result. It is maybe unavoidable. Road safety causes more deaths than code safety. We allow it. A lack of safety is inherent in any complex system Spark, Coq, provers are great. But unbounded systems quickly become unprovable. Unbounded memory allocation is one of those -- whether 'safe' or not I think this is a major reason missing from the debate. Safety hinders and complete safety is completely impossible However the truth probably lies somewhere in the middle Since you are right: computers are fast enough that even 3d games could often have memory safety In conclusion The current memory safe languages remove more from the table than I think you expect; and that is why I would suggest most important software has been written in 'unsafe' languages For instance, servo arguably demonstrates that. A surprizingly small amount of firefox has been replaced by rust, and not due to lack of effort But also we simply don't care about correctness enough to get closer to it. So I would say it is good you ask for that But too often, to me, the debate looks like we swap one blindness for another