Subject: Re: Tail recursion & CL From: Erik Naggum <erik@naggum.net> Date: Mon, 08 Oct 2001 22:53:59 GMT Newsgroups: comp.lang.lisp Message-ID: <3211570436970544@naggum.net> * Juliusz Chroboczek <jch@pps.jussieu.fr> | JS> If you run your (loop) example on a laptop running on batteries | JS> you will see in not so long time that even (loop) is doomed to | JS> "terminate" because some resource is exhausted. | | I see. It's actually useless to try to write reliable programs, | because my machine might very well run out of batteries. Juliusz, I find your approach in this thread to be irrational, and I suspect that it has some philosophical underpinnings that I cannot quite get a grip on. You have removed the real world from your reasoning, and when people reintroduce it, they fall apart like they depend on a reality different from what is normally experienced. There is something wrong with a philosophy when that happens. In this case, your probably half- facetious response betrays, I think, a failure to differentiate between the normal and the exceptional. This is akin to what we find in politics when people make no distinction between normal and emergency ethics -- under normal circumstances, no person's life is in danger and endangering a person's life is wrong, but in an emergency, a person's life is in danger and it may be ethical to endanger another person's life, such as the attacker of the first person. If you attempt to apply normal ethics to the emergency situation, you _will_ endanger someone's life and that is wrong whichever way you look at it, so there is no right answer, anymore, meaning your ethics has failed, but you cannot argue that your normal ethics has failed across the board -- it has only failed in an emergency. Likewise with software: If your theory assumes a normal course of execution and termination, the theory _fails_ if apply it to exceptional termination, but that does not mean the theory is wrong apart from being abused for exceptional situations. This issue is of course getting more complex in software where the normal course of execution includes a large number of exceptional situations, but running out of resources is clearly such an emergency that no theory of reliable _software_ can deal with it. The hardware exists. It cannot be abstracted away while the theories are still expected to have their usual predictive power. Regardless of how reliable your software is, if you are running it on a laptop computer in, say, Kabul, it just becomes so incredibly stupid to argue that the _software_ failed if the hardware evaporates and that it is useless to write reliable software when it might as well blow up on you, literally. On the other hand, we do have people from vendors in this newsgroup who argue that just because you need sockets, which are not standardized, you might as well disobey some other parts of the standard because the standard is not perfect in its power to encompass the needs of the world. I think it is the same bogus ideas that underlie the attitude to perfection and normalcy of both of you guys, that if you define a perfection that is inherently unattainable and impossible, you can go on griping about irrelevant flaws forever. As far as I can tell, Common Lisp is good enough that it attracts people who can make up a desire for an irrationally perfect world and thus never actually be satisfied with what they are able to get in any real life. For instance, you will never get a guarantee for tail-call merging in the standard, and it is _completely_ useless to ask for it or even pretend that you can get more than actual support for what you want from vendors. The standard is not at fault for not giving you the irrationally perfect. /// -- My hero, George W. Bush, has taught me how to deal with people. "Make no mistake", he has said about 2500 times in the past three weeks, and those who make mistakes now feel his infinite wrath, or was that enduring care?