4 ms·

> 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 funct

by sklogic 12y ago

> 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.

rebootthesystem 12y ago
You see, i am arguing from practice and you from theory. In theory you are absolutely correct. In practice the vast majority of code is NOT written in total languages. A more likely scenario is one where somebody is using language X and, in the middle of a project they decide there's this recursion thing they read about or learned in school. And off they go. In that context. In the context of a practical world where virtually nobody is is using total languages, the injection of recursion by the wrong people is dangerous. I say this from first hand experience. Let's just agree to disagree.
- sklogic 12y ago
  > You see, i am arguing from practice and you from theory. ??? My "theory" is being extremely widely used in practice. Take a look at the Intel FDIV bug history and its consequences for example. They've been formally certifying critical parts of the hardware ever since then. Or take a look at the widely used seL4 kernel: http://ssrg.nicta.com.au/projects/seL4/ http://ssrg.nicta.com.au/projects/seL4/ > In practice the vast majority of code is NOT written in total languages. And this is the problem, not recursion or whatever else. Incompetent coders are evil, and you cannot blame any particular technique for any failures. Luckily, in my practice, nobody ever dared to let any graduate larvae to hang anywhere near any kind of mission-critial code. I've heard stories, of course, but never witnessed anything like that myself. > they decide there's this recursion thing they read about or learned in school. As I said, people of this degree of cognitive development will screw up anyway, no matter what techniques they use. In a monkey with a hand grenade situation you should not worry too much about a sharp stick this monkey may accidentally pick up. > the injection of recursion by the wrong people is dangerous Pretty much everything else they do is equally or more dangerous anyway. And, getting back to your rant which started this thread - you said that recursion is dangerous and useless. Unconditionally. Now it turns out that it may be dangerous, but only when used by complete tools and only in heavily mission-critical embedded projects. Quite a distance from what you've said originally. No wonder you've got such a response.
  - rebootthesystem 12y ago
    I think you are at a point where you just want to argue to argue because. I'll give one more spin and I am out. The world you paint isn't the real world. The world I am considering is this one: http://langpop.com/ http://langpop.com/ In other words, one where your total languages are virtually nowhere to be found. Not by a small margin, by a landslide. So, as they say in the movies, in a world where the top 5 most used languages are C and and C derivatives and total languages are almost nowhere to be found or a thing of academia, then, yes, what I am saying is very relevant and, dare I say, true and appropriate. And, BTW, even experienced programmers screw up recursion because it just isn't used that often. I don't want to blame newbies. So I look at this world, as evidenced by the charts on that site and a data I am sure could be dug up on a bunch of other sites I can very easily conclude that total languages are still mostly in academia and so is safe recursion. In a world dominated by C and derivatives, recursion can be really dangerous. Bad recursion hidden inside a library can be really bad news. Anyhow, I am done with the back and forth. I understand where you want to come from. I am just asking that you understand that the frame of reference you have constructed is not one that matches our current reality. Which means one can't say that recursion is safe because when total languages when virtually nobody, in relative terms, uses them. And then, when they do use them, you have to ask what they are using them for. Is it Academia or real world application? Enough said. Thanks for a good discussion. I wish people were not so nasty with down-votes on HN as it detracts from trying to have a discussion based on ideas contrary to the underlying HN culture. That's just the way it is.

by sklogic 12y ago

rebootthesystem 12y ago

You see, i am arguing from practice and you from theory. In theory you are absolutely correct. In practice the vast majority of code is NOT written in total languages. A more likely scenario is one where somebody is using language X and, in the middle of a project they decide there's this recursion thing they read about or learned in school. And off they go. In that context. In the context of a practical world where virtually nobody is is using total languages, the injection of recursion by the wrong people is dangerous. I say this from first hand experience. Let's just agree to disagree.

sklogic 12y ago
> You see, i am arguing from practice and you from theory. ??? My "theory" is being extremely widely used in practice. Take a look at the Intel FDIV bug history and its consequences for example. They've been formally certifying critical parts of the hardware ever since then. Or take a look at the widely used seL4 kernel: http://ssrg.nicta.com.au/projects/seL4/ http://ssrg.nicta.com.au/projects/seL4/ > In practice the vast majority of code is NOT written in total languages. And this is the problem, not recursion or whatever else. Incompetent coders are evil, and you cannot blame any particular technique for any failures. Luckily, in my practice, nobody ever dared to let any graduate larvae to hang anywhere near any kind of mission-critial code. I've heard stories, of course, but never witnessed anything like that myself. > they decide there's this recursion thing they read about or learned in school. As I said, people of this degree of cognitive development will screw up anyway, no matter what techniques they use. In a monkey with a hand grenade situation you should not worry too much about a sharp stick this monkey may accidentally pick up. > the injection of recursion by the wrong people is dangerous Pretty much everything else they do is equally or more dangerous anyway. And, getting back to your rant which started this thread - you said that recursion is dangerous and useless. Unconditionally. Now it turns out that it may be dangerous, but only when used by complete tools and only in heavily mission-critical embedded projects. Quite a distance from what you've said originally. No wonder you've got such a response.
- rebootthesystem 12y ago
  I think you are at a point where you just want to argue to argue because. I'll give one more spin and I am out. The world you paint isn't the real world. The world I am considering is this one: http://langpop.com/ http://langpop.com/ In other words, one where your total languages are virtually nowhere to be found. Not by a small margin, by a landslide. So, as they say in the movies, in a world where the top 5 most used languages are C and and C derivatives and total languages are almost nowhere to be found or a thing of academia, then, yes, what I am saying is very relevant and, dare I say, true and appropriate. And, BTW, even experienced programmers screw up recursion because it just isn't used that often. I don't want to blame newbies. So I look at this world, as evidenced by the charts on that site and a data I am sure could be dug up on a bunch of other sites I can very easily conclude that total languages are still mostly in academia and so is safe recursion. In a world dominated by C and derivatives, recursion can be really dangerous. Bad recursion hidden inside a library can be really bad news. Anyhow, I am done with the back and forth. I understand where you want to come from. I am just asking that you understand that the frame of reference you have constructed is not one that matches our current reality. Which means one can't say that recursion is safe because when total languages when virtually nobody, in relative terms, uses them. And then, when they do use them, you have to ask what they are using them for. Is it Academia or real world application? Enough said. Thanks for a good discussion. I wish people were not so nasty with down-votes on HN as it detracts from trying to have a discussion based on ideas contrary to the underlying HN culture. That's just the way it is.