On 18/05/2017 21:12, Chris Angelico wrote:
On Fri, May 19, 2017 at 5:29 AM, bartc <b...@freeuk.com> wrote:
"largely" verified. Can you be absolutely certain that not one of
these compiler-detected issues is actually a problem? Would you stake
your life on it - for example, would you compile this code and put it
in charge of an airliner that you then ride on?
No I wouldn't. But I wouldn't trust any C or C++ or Python code either!
I want people who write such systems to use something like Ada, or a
stricter, safer subset of one of those others. And add redundancy on top
plus all the other things they do in aviation.
But still not Python or other languages where you trap most errors at
runtime rather than compile-time. Not even for the in-flight entertainment.
In other words, you are *DELIBERATELY* making your program
non-portable.
That's true; it probably won't work on a obsolete system or a DSP or
some oddball mainframe, but... so what?
And why am I being put through the third degree?
Will every program /you/ write work on every computer in the world,
past, present and future?
Would you trust every piece of software you write (ignore any
irrelevance!) to control the systems in any airline that you ride on?
You're being entirely unfair. Someone creates a product that probably
runs on 95% of the world's computers (the ones with a keyboard), and
your criticism is that it doesn't work on the 5%. Or it probably has
bugs in it so it can't be used to control a space shuttle.
I'm sorry, Mr Perfection, but that's the best I can do!
Why not just distribute a binary instead? You're not
gaining any portability.
How do binaries work with Linux? Are they guaranteed to work across
Linuxes running under the same processors as happens with Windows?
I know that there are problems with C. But you don't eliminate them by
saying "I compile other code via C". Even with complete unit-test
coverage, you can't prove that your translator is 100% bug-free. And
how much test coverage *do* you have, bartc?
Well, if something goes wrong, I usually know soon enough. My static
language M is written my dynamic language Q. Q has a compiler and
interpreter written in M. There is a circular dependency which is very
sensitive to problems. (I used to have the Q compiler written in Q too.)
I also need to detect any such problems before I've been through a
couple more generations, otherwise everything - including all my other
tools - can suddenly stop working. (Then it's time to see if my backups
work.)
For a change, M can emit C code. I can run my own C compiler (written in
M) to create a new version of Q, which compiles a new version of M,
which compiles a new version of the C compiler...
It seems a bit of a luxury that the CPython people can use an external
tools (C language and compilers maintained by other people), and don't
need to worry that a bug that has slipped past that has unknowingly
infected gcc or MSVC in subtle ways.
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
