No, that actually means they want a specific person, indeed not mentioned in the listing. When the right person applies, all those unsatisfiable requirements are suddenly ignored.
All death is "fractional" if you make a fraction out of it. For example, dividing the number of people that died making the Empire State Building by the total number of workers. It seems subjective which fractions matter and which don't. It seems to be based on how much the responsibility can be laundered.
From an ISO 26262 perspective, it seems like for the driving scenario of "unexpected windshield wiper speed increase", they may have set the controllability to C0 (Controllable in general) [1] when it may have needed to have been something less controllable (C1 means 99% of drivers can avoid harm in the condition, C2 means 95%, C3 means less than 90%). That probably set their risk level to something lower than it actually was. They probably need to do some tests for anything they're diverting to the touchscreen to figure out how many drivers can manage the situation within the time frame of avoiding a crash.
It looks like Tesla's job postings reference ISO 26262 experience as a plus [2], but I can't get a straight answer to Tesla's adherence to it in-house. My understanding is that no government mandates its use, but lots of car companies adopt it anyway.
Most safety standards that address software's contribution to hazards use some notion of "controllability" to determine risk. For example, ISO 26262 explicitly calls it controllability [1], and it directly contributes to how rigorously the software functionality has to be tested.
MIL-STD 882E uses "Software control categories" that determine the risk introduced by software [2, page 15-17]. Since those definitions are hard to track, they also provide a table near the end that tries to be a little more specific [2, page 96].
In other words, the safety community already takes into account the need for human or mechanical intervention when it comes to risks introduced by software.
In "The Soul of a New Machine," there is an engineer who spends months debugging nanosecond-level glitches in their new CPU, snaps, and runs away after leaving a note: "I am going to a commune in Vermont and will deal with no unit of time shorter than a season."
The alleged Socrates quote is a mutation of some quotes in a dissertation published in 1907 where the author was summarizing common complaints about children in ancient times (src: https://quoteinvestigator.com/2010/05/01/misbehave/ ).
You can answer this question yourself: simply figure out how you'd implement certain types of programs in Prolog. For example: an operating system, a Unix command-line tool, a video game, etc. You'll quickly shake out deficiencies.
What's wrong with writing Unix command-line tools in Prolog? I'm asking because the "deficiencies" aren't clear to me, although I have written command-line tools in Prolog.
These are good questions! As a simple control, I have asked myself these questions with Java in mind, which enjoys notable popularity.
Would I write an operating system in Java? No. A Unix command-line too? No. A video game? Probably not.
In my view, this casts some doubt on the test's adequacy to answer the initial question. In the concrete case of Java, I think marketing and other influences also played important roles. It could be possible to apply these advantages to Prolog too.
You are not asking the same questions. The question is how would, not would. While I'll admit writing an operating system in Java is non-trivial (thinking of kernel-level programming here), writing a command-line tool or a video game is pretty simple. You main method receives command line arguments, so that part is covered, and for games you do pretty much what you would do in any other language.
Thank you! Indeed, the question was "how" would I do it, so let us consider it:
Operating system in Prolog: Non-trivial, i.e., like in Java. Command-line tool: Pretty simple: My main predicate receives command line arguments. There are countless such examples already, included in the SWI-Prolog distribution (for example). And, as you say, for games I would do pretty much the same as in any language also in Prolog.
In my view, this still leaves the same doubt about these questions: Can we distinguish Java from Prolog in any way by answering them?
There was/is no RFC for the ZIP file format (there is for gzip and the DEFLATE algorithm). It was Phil Katz releasing a text file called APPNOTE.TXT describing the file structure (latest version is available at https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT ).
