> I am also assuming that well-designed language runtimes and compilers do not.
I guess the big point I was trying to make in other parts of the thread is that this is sort of begging the question. If you can assume that runtimes and compilers are flawless, then of course you should use the biggest, hairiest ones you can get your hands on, and furthermore you should argue for every possible piece of functionality to be put into the runtime, so that it will work correctly and not have any bugs.
In practice, though, that is not the best possible factoring of the problem. If it were, you wouldn't be using C++! So I don't think it provides a very good guideline to use for questions like "would moving from C++ to Java make our code more reliable?" I think that answering that question properly involves a lot more reasoning about the particular runtimes and compilers involved, as well as the structure of your application — or lack thereof, if you really have an unbounded number of places you might have written a buffer overflow!
What you say about compilers' formal correctness might be true in theory, but in practice, all compilers contain a large number of bugs. I don't think it is true in theory, though. Optimizing a piece of code is AI-complete, and verifying the equivalence of the source and target programs is known to be uncomputable, since it subsumes the halting problem — in theory, it's impossible to even determine whether the compiler has inserted an infinite loop into your program, let alone whether the rest of its semantics are preserved.
The string → string nature of compilers does mean that they can be highly portable and not spend much time interfacing with the rest of the universe, though.
> I don't think it's possible to specify the behavior of a word processor to the same extent.
Maybe not, but you can probably specify the behavior of its string class to have no buffer overruns. I mean, you can write a word processor in Python, right?
Comments
> I am also assuming that well-designed language runtimes and compilers do not.
I guess the big point I was trying to make in other parts of the thread is that this is sort of begging the question. If you can assume that runtimes and compilers are flawless, then of course you should use the biggest, hairiest ones you can get your hands on, and furthermore you should argue for every possible piece of functionality to be put into the runtime, so that it will work correctly and not have any bugs.
In practice, though, that is not the best possible factoring of the problem. If it were, you wouldn't be using C++! So I don't think it provides a very good guideline to use for questions like "would moving from C++ to Java make our code more reliable?" I think that answering that question properly involves a lot more reasoning about the particular runtimes and compilers involved, as well as the structure of your application — or lack thereof, if you really have an unbounded number of places you might have written a buffer overflow!
What you say about compilers' formal correctness might be true in theory, but in practice, all compilers contain a large number of bugs. I don't think it is true in theory, though. Optimizing a piece of code is AI-complete, and verifying the equivalence of the source and target programs is known to be uncomputable, since it subsumes the halting problem — in theory, it's impossible to even determine whether the compiler has inserted an infinite loop into your program, let alone whether the rest of its semantics are preserved.
The string → string nature of compilers does mean that they can be highly portable and not spend much time interfacing with the rest of the universe, though.
> I don't think it's possible to specify the behavior of a word processor to the same extent.
Maybe not, but you can probably specify the behavior of its string class to have no buffer overruns. I mean, you can write a word processor in Python, right?