Thank you for your reply.

where any failure is simply not acceptable
...
That's a helluva concept

Yes it is. However, many such situations exist today where a single bug will completely destroy a company's reputation and open them up to severe liability. A single bug in certain medical systems could easily cause many deaths. A bug in flight control software can cause (and has caused) a hundred million+ dollar mission to end in failure.

But how can you expect substance, "working code", stuff that can be "directly applied", etc, in the context of talking about programming in general?

You'll have to obviously narrow the field a bit to get to the level I'm requesting, but narrowing out brainfuck doesn't exactly eliminate a good portion of your audience. Pseudo-code, class diagrams, etc can be equally applied to Perl, Java, Python, Ruby, C++, and almost any language in popular use today.

The causes of software failure constitute an open set. They include not only things that are arguably wrong in the code design, but also varieties of data or operating conditions that no programmer could anticipate, no matter how careful or thorough the design and testing.

Actually, I disagree. Provided that the supporting systems interfaces are accurately and fully specificed and that they do not fail, the responsibility rests entirely on your code. If everyone follows that strategy then you will have a flawless system (this is obviously a lot harder at the hardware level). The task is not to complete the entire product perfectly, but to complete your software's functionality perfectly.

In order to learn the best way to write code, and in order to improve your skill as a programmer, you have to write code, fix code, review and critique code, and be involved enough in each particular application domain to know what the code should be doing

Yes, but after that what happens? To continue simply learning a simple fix here and there will not result in the reliability required for such systems.

Pseudo-code, class diagrams, etc can be equally applied to Perl, Java, Python, Ruby, C++, and almost any language in popular use today.

... The task is not to complete the entire product perfectly, but to complete your software's functionality perfectly.

Good points -- but it actually looks to me like the thrust here should be how to write specifications that are appropriate, adequate, bullet-proof and idiot-proof, and also make sure that these specs are readily translatable into the chosen programming language, complete with all necessary testing protocols -- i.e. given that the spec says "input comes from X, consisting of N bytes, etc" the test has to say "here's what is supposed to happen when input comes from anything other than X, and/or does not consist of N bytes, and/or etc."

Most of the perl core documentation (and much of the extra module documentation) that I've seen has a lot of the properties that one would want for proper/robust software specifications -- the reader is told what inputs are needed or allowable for a given function/method, what it returns when used properly, and what happens when not used properly. And this is typically done using clear, simple language, not overburdened with nonce acronyms, jargon or "technical legalese", and yet not at all vague, either. I would hope that critical-impact projects would model the development of specs on such examples.

Admittedly, the theory (or practice) of robust software design in critical-impact apps is not an area where I should try to assert any sort of personal expertise. I'll shut up now.

Admittedly, the theory (or practice) of robust software design in critical-impact apps is not an area where I should try to assert any sort of personal expertise. I'll shut up now.

You're doing at least as good as the "experts." Besides, as my good friend Francis always said truth comes sooner out of error than confusion :).

You raise a good point about the specifications as well. Perhaps a problem well stated is indeed a problem half solved here. It appears to me that a proper tool for such a job would have to effectively generate tests to cover each set of possible errors introduced by the source code. It would not be possible to create all the tests by hand, that would only transfer the problem from the instructions to the tests.

Anyone have any thoughts/information on self-verifying languages? Is there a different term for them I'm missing? ("self-verifying programming language" turns up nothing in google).

I think that learning Perl, besides reading some books is not so difficult since the code is nearly always open to read it.

If I were you, I would choose a subject that you have worked on it for a long time (expert by direct experience) and after finding the best script of this kind develloped by someone that you respect, try to modify it and improve it.

That is an active way of developing skills and style.

You won't like to change the author's style. And since the concept comes from another mind you are going to be forced to understand the way of thinking of this author.

That is a universe to disconver for your improving. And it is free. Just try to improve the code and then publish it, mentioning the improvements and the original author.

Finally, if you didn't learn a lot by re-writing the code you are going to learn a lot by the critics or by the people that love your improvements :)