I believe it is essential to realize that any software written in a language at a level higher than machine code native to a specific processor is subject to the vagaries of the compiler
If some industry goes to great lengths to ensure its software quality, that's the aviation industry. Compilers have to pass certification levels (see, e.g.,
here or
here). Among other things, traceability from source code to generated assembler is validated. About the software itself, formal proof (e.g.
SPARK) and real-time deadline analysis I think are the norm. Nothing to do with the crash-prone in-flight entertainment systems.
I'm in total agreement that computers do what they're told and nothing more, nothing less, and there can be a problem of under/misspecification (basically, the human side of software design). How can we expect any system to perform correctly out of its specs, be it code or a mechanism with its tolerances? My point is that I don't think "computer fairies" in the sense of the ones we experiment in our desktop computers have much to do with this crash, at least until some evidence in this direction is found. And while general software production is certainly of a bare-minimum-and-ship quality, that's not the case in avionic systems.
Someone talked before about the different degradation qualities of computer systems and mechanical systems, once you push their limits. I think this may be a valid point for discussion; once you exceed some routine preconditions, bets are off. But then also cables snap.
Going slightly off-topic: I'm not an insider, but I'm a software engineer with a great interest in these matters. I was told once by some person in the business something that I don't know if is the truth (I'd like to know if it is not, obviously), but that to me, as a programmer, is quite impressive. He told that no plane accident to date can be attributed to a software bug. Note that I mean a runtime bug, in the sense of correct input, unexpected output; not some misunderstanding between pilot and automation, or operating out of the specifications (which can fail to anticipate situations, as Machinbird I think is concerned in a recent post).
E.g. the much touted Ariane 5 blow-up was not really a software programming problem (and that's not civil aviation anyway), but a software management issue. The closest I know are the unexpected pitch commands recently in some Qantas A330/340, but I think that's still unclear. Also I vaguely remember that unexpected spikes in input data could be the cause (although if these spikes came from another software component I don't know).