When I got seriously interested in computers back in the late 1970s, among the first books I read were the late Daniel McCracken's books on Algol, Fortran, and his classic on COBOL. I actually used Algol (NU-ALGOL) in our file processing course at the University of Maryland (my fellow students used Fortran-66) and COBOL for our database course circa 1980 (to create and access network databases--Codasyl?). COBOL wasn't bad and certainly wasn't terrible (like Java, I'll agree!). Although my favorite languages are probably C and Scheme, I've got a healthy respect for other languages and will note, like Donald Knuth did in his response (Computing Surveys?) to Dijkstra's"Go To Statement Considered Harmful", that good programmers write good code in any language, even assembler.
I also remember a frequent poster/COBOL evangelist on one of the USENET groups (comp.lang.c or comp.lang.unix?) back in the late 1980s who posted a *portable* 4-line COBOL program to sort a file. The sections in a COBOL program are optional and, in fairness and perhaps to the point, standard COBOL has a SORT function. In C and other languages without a standard SORT-like function, you can't simply do a "system ("sort
Years later, Donald Knuth wrote a literate Pascal program to do something and a couple of Unix legends famously responded with short shell scripts or whatever. I love Unix and often reach for awk(1) (which is ingrained in my brain despite having also used Python and Perl before). However, Knuth's Pascal program could be built and used on any platform with a Pascal compiler, while the respondents' scripts only worked on platforms that had the Unix tools available (GnuWin32 or Cygwin on Windows, for example)
Now, let me get back to replacing those mercury delay lines with bubble memory
But frankly I have a VERY hard time believing that the engineers involved did not know that what they were doing would violate the law.
I know you know engineers, so this question is rhetorical: Do you know engineers?
10 years ago, I worked on a project that adapted an existing codebase to use CORBA and, as a selling point, used wide-character strings in the interfaces for "internationization". One developer wrote an inline C++ function to convert a wide-character string to a normal C character string and everyone was forced to use it, including me. His "sophisticated"-looking code checked if the value of the wide character would fit in the target character width (which, while not explicitly specified in the code, was of course 8 bits). If not, an error exception was raised. If so, the wide character was simply truncated to the target character width. In other words, our whole system only handled Unicode values between 0 and 255.
Several times, I tried to raise the issue that this approach was wrong; the better approach was to convert wide-character strings to UTF-8, which our existing software could use without problems regardless of the wide-character values (except possibly in the GUI, which was done by another group). The managers and the other developers (who didn't know much about Unicode) took the side of the other developer, who insisted that his approach worked.
So, we had a whole bunch of developers using something they didn't understand that was wrong. And many of the developers were very smart. Hence I can imagine the engineers at VW implementing the emissions test without worrying about the legal implications and not thinking to get verification in writing of the requirement.
To make matters worse, the developers (not in our company, but who, I am sure, were reasonably smart) who wrote the TAO CORBA implementation we used didn't understand the (pretty straightforward) CORBA GIOP/IIOP specification of how to marshal/unmarshal wide-character strings over the network--and they got it wrong! This was a known problem on the TAO support forum for the version of TAO we were using; I had a parallel implementation of IIOP, became aware of the problem, and therefore looked for it on the forum. Our other developers probably didn't read the forum or weren't aware of the problem. Before I left the project (voluntarily), I warned that there might be trouble if this problem was ever fixed. (Our system controlled satellites. Before rolling out a new version of our system, a client company would run the new version for a while in parallel with the earlier version of our system that was in place, both versions communicating with each other, until they were confident there were no problems. With the wide-character string encoding fixed in TAO, our new and old system versions wouldn't be able to talk to each other; possibly there was a run-time configuration tweak to have the new version of TAO revert to the old broken protocol for wide-character strings.)
At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer.