Subject: Re: Static/Strong/Implicit Typing From: Erik Naggum <email@example.com> Date: 26 Jan 2004 10:12:25 +0000 Newsgroups: comp.lang.lisp Message-ID: <3284100745605210KL2065E@naggum.no> * Kristian Elof Sørensen | I too am a recent arrival to the Lisp camp am still not convinced as | to the unconditional superiority of the dynamic aspects of the type | system. Nobody implied it was unconditionally superior. You have to lose this «one winner takes all» attitude. Different solutions can coexist. In fact, different solutions /must/ coexist for the proper solution to be applied to problems that differ from the historic problems to which they were the solutions. Think evolution. In the real world, there are no winners, only temporary advantages. The myth of the «winner» is probably the second most destructive myth that Western civilization has hoisted upon its population. (The most destructive myth is that of people being either «good» or «evil», which is the root cause of all injustice ever perpetrated by humans.) | But if this is the case, then is all this dynamic typing stuff only of | benefit during development and debugging, and of no use during actual | use by end users because at that time going into the break loop equals | a crashed program? What «this» refers to is not the case and none of the above follows. If you insist that the way you view the world is the only only possible (as is implied by resorting to «unconditional superiority»), everything will turn out to run against your world-view sooner or later, and this will naturally be interpreted as there being something wrong with the world. For instance, when you equate a handled error condition with a crash, you look at only the most superficial quality of a failure: That it does something other than the user wanted. But most of the time, real-world applications have an extremely strong requirement to either complete their task to specification or not do any harm. The Common Lisp condition system is eminently able to make computers behave in the most rational way possible when they are unable to complete a task. I strongly suggest that you not explore the boundary conditions until you are comfortable with the normal operating parameters. This means that you have to lose «unconditional», «all», «only», «of no use», etc. Incidentally, type errors are irrelevant. They just do not happen in Common Lisp code as often as they do in languages where the compiler is responsible for catching them. It is understandable that someone who has been burned hard and often by compilers who never seem to be satisfied with one's code no matter how hard one tries, will believe that this kind of mistake is very important and stands between him and total disaster of the program. However, this is not how it works in Common Lisp, because Common Lisp systems do not crash. They are so forgiving and friendly that anyone who approaches them believing that they will be hostile and interpret their responses as if they could only have been hostile, will misunderstand and fight the system, much like they would people they mistakenly believe are hostile. -- Erik Naggum | Oslo, Norway 2004-026 Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.