python was: transputers again was: The dissolution of Commodore 2922
Based on some of the code that escaped into the wild, not paranoid enough ;) (And yes, I know that in the eyes of the LSG, the VAX camp was a den of iniquity inhabited by unwashed barbarians)
Hell, if I could get the programmers I work with to write even the most trivial unit-test cases, our defect rate would drop 50% overnight.
I am the *last* guy to jump onto the Next Big Thing bandwagon, but those Extreme Programming people are really onto a good idea with their testing dogma.
No, it doesn't really enter into my thinking much.
Because I have an insatiable intellectual curiosity, I would like to fully grok RISC processors, and be able to argue the merits of this technique versus that technique for register coloring or any of a myriad other details of code generation, but that is far afield from my primary responsibility, and *would* be a distraction.
It boils down to this:
python was: transputers again was: The dissolution of Commodore 2923
Of course. It takes years and a lot of learning to be paranoid perfect. Nope. They washed but only knew how to clean using...
1) We (humans) always interact with the machine at some abstraction level, beginning fifty years ago, when some clever guy got the idea to use handy mnemonics for instruction codes, so he didn't have to remember 26 == ADD and 34 == SUB.
2) We could not write the complex systems we do without the higher levels of abstraction we enjoy today.
Today I write code in a very high-level system, that runs simultaneously in a network of thousands of physically disparate machines running different operating systems, and having different CPU architectures. If I had to write from bare-metal the entire system, it would take several lifetimes to get to first test, and a few millenia to get to FCS.
transputers again was: The dissolution of Commodore 2927
Now consider comparing subroutines with CISC instructions. And look at compilers analyzing statements from an HLL...
At some point, you have to believe what it says on the box -- whether the box says "ADD A,FOOBAR" will successfully add the contents of memory location FOOBAR to the A accumulator, that the retrieve() method of a B*-tree library will really return the record you inserted return an empty set.
The important thing to remember is: The guy who is writing the SQL engine, believes that the B*tree library works (it worked in all the test suites, he is using it in within the parameters specified as to length and flavor of key, etc); The author of the B*-tree library has to believe that the C compiler will generate code that really increments a pointer by the correct size when he types *p++; The author of the C compiler believes that the buttembler will really emit the correct instruction when he says addl2 16,r4, and the author of the buttembler has to buttume that the processor really will add 16 to register-four when it executes instruction 5410C0.
At each level, you have to perform some acceptance test - since an exhaustive test is impossible (considering that even a small computer nowadays has on the order of 10**10 bits of memory, and therefore 10**20 states) - and here's an important part: It takes a specialist qualified at some layer to know how to perform that inductive proof. I cannot be that specialized in that many layers at the same time.
Whom can you trust? Who is held accountable? I think BAH is of the mind, "Only trust that which I personally can prove," but, with due respect, that limits the scope at which you can perform, without being a super-human. The epoch of the "bit gods" has pbutted -- even a Super Genius cannot hope to keep up on every front of computer knowledge - the field is growing at a quadratic rate.
IMO Software defects fall into three broad categories --
transputers again was: The dissolution of Commodore 2925
David Scheidt ... snipped stuff with silly non-standard quote marks ... Just to use your example, there...
transputers again was: The dissolution of Commodore 2926
Ok, people should not write long chunks of code. But a language should provide the tools for doing so -- because the programmer may be too occupied with...
1) My subsystem did not perform the behavior it was documented to perform. This is IMO the most common - and can be rooted out with better unit testing.
2) My subsystem was pbutted parameters outside of the domain for which it is defined. This is a big philosphical battle that has been going on since before I was born, and will survive me: Who is responsible for validating parameters -- the caller or the callee. I vote for the callee, but that's just because I seem to be a better programmer than my peers, and by squawking early and often about bad parameters, my callers will be more inclined to find their defects during unit testing.
3) My subsystem depended on a sub-subsystem which did not perform as documented (i.e. I call a library that has a defect of the 1st form), despite being given parameters within the specified domain. These can be discovered through improved qualification tests.
Fifteen or twenty years ago, one saw a lot more defects of the third form, "compiler generated bad code when I did (x)" or "trig library returned nonsense data when I asked for sin(PI-3)". In recent memory, even using some pretty bleeding-edge technologies, those kinds of defects have fallen into the realm of Freaks of Nature.
The output of Redmond (and others of their ilk) notwisthstanding -- software quality *is* slowly improving.
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Computer software consists of only two components: ones and zeros, in roughly equal proportions. All that is required is to sort them into the correct order.
Alt Folklore Computers Newsgroups