Edsger Dijkstra's famous rant "Go To Statement Considered Harmful" did an immense amount of harm. He was a theorist who didn't program much himself and proudly claimed that he didn't have regular access to a computer. A lot of "computer science" is like that.
formatting link
--
John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com
Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators
GE. Well, nobody has died. I mostly work with P&W.
Probably ADA, but there is that problem, lack of programmers. C can be reliable if you use it right: simple state machines, all static buffers, no or careful use of pointers, and most important, checking the code. And avoid libraries as much as possible.
--
John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com
Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators
Don't know about the engine Honeywell maybe. But the new FADECs were by Textron and had already destroyed one Chinook on the ground prior to this incident. A c*ck-up that the maker paid £3M compensation for or about 20% of the hardware replacement cost. Sounds very cheap to me for a totally wrecked expensive military airframe - but then MOD purchasing negotiators are notoriously dim and overpay for everything.
formatting link
They didn't learn either the next version they ordered proved impossible to certify as air worthy and the debacle rumbles on...
formatting link
The point here is that the algorithm has to be correct as well as the programming implementation. Focussing too much on any one magic bullet invariably leads to a false sense of security.
There are static analysis tools that can find a fair proportion of common coding faults and diagnostic tricks that will catch othersat runtime but you can never be sure with C/C++ that there is not a wild pointer waiting in the wings for a chance to bite you.
IFF they are applied. Many are very expensive and do no better than =46OSS/UNIX "lint". Many programmers find the tools "get in the way" of shoving code out (which the bosses love).
Grossly insufficient. Does not check corner cases properly. Does not allow for requirements changes.
Do you understand the concept of regression testing at all?
Untrue. Code checking tools prevent stupid errors getting past the compiler. There is no point allowing detectably incorrect code to compile!
It is the *sloppy* programmers that refuse to use them!
Static analysis tools catch any mistake that can be detected by data flow analysis at compile time. Paths through code where a variable is never initialised for instance. There is *no* excuse for not using them.
Lint is pretty long in the tooth now there are much better tools.
I actually have a rather sophisticated compiler where the writers had a sense of humour and for some absolutely fatal errors compile the code with just a warning. The executable line that fails is replaced with a hard trap and an error message. Anyone with any sense promotes these "warnings" to compile time faults rather than execution time errors. They did it this way to make a point.
Modern optimising compilers can detect a lot of latent errors from the internal flow graph of the code they are compiling, but annoyingly these features are only enabled in the most expensive versions.
It should be in the teaching versions to get the net generation trained properly with state of the art toolsets - not crash and burn mentality.
The people who can afford the tools are disinclined to use them as they don't like having their mistakes pointed out by a machine :(
Although it is insufficient in many cases it isn't done even at a more rudimentary level. And GUIs have made it orders of magnitude more difficult to generate test cases. If you look at the review of the FADEC that killed 25 senior anti-terrorist officers the reviewers gave up after examining 18% of the code with nearly 500 anomalies found. This was in aerospace code that is supposed to be damn near bug free!
When the original x87 was subjected to reverse engineering for a new black box implementation by Cyrix several hidden faults and minor arithmetic quirks were identified as a direct result of the formal analysis. The specification they derived was used to generate the boundary cases and it was found that the original 8087 did not meet the full spec. No-one had noticed though. Cyrix did it exactly right.
He isn't all that far off. Normally a few representative cases and the boundary cases that are meant to work together with a set of beyond the boundary cases that should fail gracefully are enough. I used to have a reputation from bringing things down by unreasonable final testing.
Based on the sorts of daft things that users actually do !
Yes. I have implemented it too along with other metrics. See previous threads. It is tragic that this stuff is only available in the most expensive corporate versions of MS tools - it should be in the teaching versions so the next generation learn good practice at the outset.
They're not that bad. They are kind of "stupid" ( they'll flag idioms you know are perfectly valid ) but a shop that converges on a checker is probably better off with it than without it.
The "expensive" thing is both true and a problem - they need to be more widely understood.
The phrase "combinatorically interesting" is left up to the person writing the tests. You do what you can to catch the corner cases.
I don't mean you wave hands at it.
Absolutely. This is where regression tests come from. But if you don't have a code base that's ... "test harness drive-eable", all you do is end up with a large binder full of test procedures that do not accumulate as a controlled deliverable.
Then again, you may end up with a large expensive regression suite that is of limited value.
But it costs LESS to code carefully and get it done sooner, in less iterations, with fewer bugs deployed to the field. Customers also appreciate not being unpaid code testers.
--
John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com
Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators
SF is indeed packed with code geeks lately. Twitter is moving in a few blocks away, and 3000 hungry, wildly overpaid geeks will make it impossible to get a seat at one of the few, small restaurants around here.
But we sure won't "HAVE ALL THE PROGRAMMERS YOU NEED applying for a job." The startups are raising money, 5 or 10 or 20 million to start, and are bidding up on anybody who can script Python or Ruby or HTML5. There are food truck clusters in parking lots around here [1] and we get to stand in line with the 20-somethings who talk shop constantly. It's a good mix, europeans and asians and Indians, male and female. The males all drink Coke with lunch, and the females drink bottled water.
These "programmers" are web and iPad apps coders. They would be useless at embedded programming.
It's insane. Kids are getting $150K/yr to scrawl Perl for silly social apps. One bedroom apartments are renting for $3500 a month, $5K in a prime location. Old buildings, former industrial stuff, now gutted as open-plan coding farms, are selling for $700 per square foot. People don't even get a cube; they wear headphones to keep out the distractions.
It's going to collapse, like the last .com craziness did. There are, what, half a million iPhone apps. Do we really need a million?
[1] The food truck thing started in LA, I think, and it's a big deal here now. Mexican, seafood, rotisserie chicken, Indian, and one improbable truck that offers Irish and Eritrean food. I stood in a long line and had a hot dog and a soda for $10 last week. I read that food trucks are getting popular in Paris.
--
John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com
Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators
As I plainly noted, all the variables are signed 32 bits.
This particular operation is apparently allowed to be compiler-dependant. A lot of C stuff is compiler dependant, "within its rights" to be unpredictable.
What you do in these cases is examine the assembly intermediate and try to figure out what this particular compiler feels like doing with this particular source line this particular afternoon.
I caught this corner case by accident while testing, when I overshot on a cal factor and railed the DAC in the wrong direction. It could easily have been shipped, a latent bug. My point is that C is often quality controlled not at the source level, but by being runtime tested. That's dangerous.
Look:
Yes.
No. It gets a final constant offset added later, and clipped, to keep a comparator output off ground, so we kept it signed right up to the end. Really, we thought this through.
Or people who like to get stuff right the first time. Commenting gives the coder a second opportunity to THINK about what he's doing. Slow down to finish the code faster. Most programmers want to type fast and avoid thinking, and fix the bugs as they are reported.
Sure. That comment is useless. But good comments say why things are being done, and note stuff like expected results and ranges... DAC codes, volts, resulting delays in picoseconds per LSB. Good stuff to have a few years from now. Lots of uncommented code is so bad that it's better to toss it than to try to modify it.
I'm just now reading a biography of Alan Turing. The first real computer program that he wrote had a bug. That started a fine, long tradition.
--
John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com
Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators
I don't know how else you can do QC without some level of runtime testing. Don't say Ada; you can still write "rail the DAC the wrong way" bugs in Ada.
Okay, so I'd have cut and paste the calculation out of context, written a test driver for it to run on a PC, then done an analysis on the output if it were critical. You can plot/regress this in Excel. You don't have to generate 2^32 samples; just a subset.
Or I'd have put asserts() in to range check.
If you know the compiler switched for MinGW/GNU well enough, you can emulate any other compiler.
The ship would sit in international waters roughly 12 miles (20 kilometres) off the California coast in order to bring foreign entrepreneurs closer to the technology capital.
Blueseed president Dario Mutabdzija says ferries will take the heads of the small companies back and forth each day to attend meetings on land with venture capitalists.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.