> See any functional languages in that list?

Not a single one. Not even a functional language, not to mention total languages. Lisp does not qualify as a functional language and never even pretended to be one. And APL is a tacit one, quite a distant thing from anything functional.

Now, try to read my previous post carefully. Referring to the relevant literature when in doubt. My point, again:

the only practical way to have a program 100% proven to be correct, and at the same time avoid wasting hundreds of man-years developing it, is to develop it in one of the total languages. Which implies that the only mean of iteration you've got is recursion and nothing but recursion.

I.e., if you want to be 100% sure that your software and hardware will not kill, and will behave exactly as specified, then you must use recursion.

Yes, of course I'm perfectly aware of the reasons behind things like JPL coding standards. They're pretty outdated and should not be brought back now, in 21st century.

> Have you ever had to write software that considers the real-world possibility of a bit flipping in memory?

I did, as well as designing hardware with such a possibility in mind. Before things like HOL and ACL2 became available it was a total hell to do so. Now it's a piece of cake.

> So you have software engineers graduating from CS programs

And how recursion is responsible for idiotic HR policies? One should never hire graduate engineers for anything distantly mission-critical. Never.

> And so he used it, oblivious to the potential consequences.

This sort of people will screw up anyway, no matter what kind of tools they're allowed to use. Recursion is far below pretty much everything else on a list of things that an ignorant epileptoid can screw up, starting with off-by-one and pointer arithmetics.

And, leaving the embedded software aside, stack overflow is by far the least common issue out there, dwarfed by things like null pointer dereferencing and the said off-by-one.

> And so my issue with recursion is one of theory vs. practice.

Practice is irrelevant. It will never give you a full coverage of all the things you can potentially screw up, not even with hundreds of years of experience. Theory, on contrary, is perfectly capable of doing so.

> Frankly, I can't remember any programming technique that has killed more people.

Magic constants. Perverted approach to parallelism (shared memory instead of message passing). Google for "Therac-25" for example.

> why would anyone willingly allow a programmer to use such a dangerous approach to solving a problem?

Where the other means of ensuring correctness are not available, the right coding standards are more or less ok (the said JPL coding guidelines for example).

> Those of use who came up through machine/assembly language and low level stuff like Forth learn this because, well, you have to.

Can you imagine someone without this kind of background allowed to meddle with a mission-critical embedded software? I'm not aware of such cases, and I spent quite a few years in predominantly embedded environment.

> if, and only if, there is no other way to accomplish the same task.

Bingo. In the total languages there is no other way to accomplish, well, anything. And only the total languages are safe enough for the mission-critical software and hardware. Turing-completeness is evil - this is what you should have been attacking, not the innocent recursion.

> Introducing recursion into a mission critical piece of software means introducing something that must forever be in the back of your mind as a potential source of catastrophic failure.

Human mind is a broken tool and should not be allowed to judge a quality of a software. Formal logic is much better in ensuring that the software behaves exactly as prescribed.