Portability Is Reliability

Citation needed. I don't believe it's anywhere close to the Pareto frontier of language design, nor do I think we should reasonably expect it to be - it's fundamentally a language put together by two kids with no formal training, designed for programming a machine that had 256 kilobytes of RAM. It became popular due to some accidents of history (Unix, availability of free compilers) and the following network effects far more than the technical merits of the design.

> Every design decision in a language is a trade-off. And the trade-offs in C / C++ are so well chosen that there was no easy improvement for decades. No low hanging fruit. A C programmer has to understand much more about memory management because there is no virtual machine / garbage collector / interpreter running which takes care of it. But for that you get efficiency that is not possible by design with the other approaches.

That's nonsense IMO. ML was and remains an overwhelmingly better language, the performance of an incorrect program should be considered meaningless, and for all that C is supposedly more efficient, when I've actually seen a C program rewritten in an ML-family language the result has been substantially better performance.

Linux actually doesn't bother fixing a lot of the kind of bugs I'm talking about (thus their use of e.g. -fno-delete-null-pointer-checks) and doesn't bother being portable between different compilers.

> Oracle should also throw away their database code. As you say, it's faster to rewrite their 30m LoC database than to add a few lines of bugfixes.

Oracle only stays alive because of aggressive sales and legal teams. H2 is both more standards-compliant and better-performing (why do you think Oracle's license doesn't let you benchmark it?).

> Wait, hang on ... what about my volvo s/wagen? The various ECUs in it are all written in C! Certainly I don't want them to fix problems and roll out a patch next week. I'll wait the 5 years it takes for them to rewrite the entire system.

> Then, of course, there's airliners. You're completely correct that we should not fix the problems in their code; we can shutdown air travel for the 8 years or so it takes to rewrite the system.

Safety-critical software is not written in C in the sense of everyday C codebases. It might be written using C syntax, but that code will not be treated as normal C: specific (often non-optimizing) compilers will be used, analysis tools will be applied, particular coding policies will be applied, using arbitrary C libraries is right out...

>Linux actually doesn't bother fixing a lot of the kind of bugs I'm talking about (thus their use of e.g. -fno-delete-null-pointer-checks) and doesn't bother being portable between different compilers. >

Correction, thy don't bother fixing some of the bugs you are talking about. A lot of the other bugs that you are talking about (bugs due to the C language) are fixed. Your proposal was to not add any fixes due to bugs in the C language.

>> Oracle should also throw away their database code. As you say, it's faster to rewrite their 30m LoC database than to add a few lines of bugfixes.

>Oracle only stays alive because of aggressive sales and legal teams.

What does that have to do with your proposal? In fact, if as you say that Oracle is alive because of non-technical reasons, then your proposal that a rewrite is better than a bugfix is even more unreasonable - they can use their lock-in to spend a decade rewriting their core products.

They aren't doing this though.

> H2 is both more standards-compliant and better-performing (why do you think Oracle's license doesn't let you benchmark it?).

How is that relevant?

>> Wait, hang on ... what about my volvo s/wagen? The various ECUs in it are all written in C! Certainly I don't want them to fix problems and roll out a patch next week. I'll wait the 5 years it takes for them to rewrite the entire system.

>> Then, of course, there's airliners. You're completely correct that we should not fix the problems in their code; we can shutdown air travel for the 8 years or so it takes to rewrite the system.

>Safety-critical software is not written in C in the sense of everyday C codebases. It might be written using C syntax, but that code will not be treated as normal C: specific (often non-optimizing) compilers will be used, analysis tools will be applied, particular coding policies will be applied, using arbitrary C libraries is right out...

I've worked as C programmer in safety-critical software. Specifically, in munitions control. The "safety" that comes is not from religious adherence to MISRA-like guidelines but from regulatory bodies who specify the process around QA, testing and official release of the software.

Changing from C to another language might help, but rewriting the entire product is out the window completely - the regulatory hurdles to re-certify and re-test alone means that such an attempt is bound to kill the rewrite effort outright.

I'm currently working in another field (C and C++ this time), and making small incremental changes is considered by the regulatory bodies as less risky than throwing everything away and restarting.

The meme "scrap C, rewrite it in $FOO" only applies to software that has very little impact on the world.