Subject: Re: macros vs HOFs (was: O'Caml) From: Erik Naggum <erik@naggum.no> Date: 10 Sep 2002 23:56:33 +0000 Newsgroups: comp.lang.lisp Message-ID: <3240690993463545@naggum.no> * Oleg <oleg_inconnu@myrealbox.com> | The type checker is there for a reason: one is execution speed, another | reason is reliability. This is commonly believed, but in fact, a type checker introduces bugs. It shifts the cost of a certain class of mistakes so much that the kinds of mistakes people make in the presence of a type checker destroy their ability to think clearly about types. Experience strongly suggests that people who use strongly-typed languages and have compilers who produce informative error messages when type constraints are violated, cause their programmers to believe several idiotic ideas: (1) Type errors are important. They are not. You would not make them if the cost of making type errors was higher. (2) Satifsying the compiler is no longer only an inconsequential necessary condition for a program to be correct, it becomes a sufficient condition in the minds of those who make the first mistake. (3) Errors in programs are separated into two kinds of vastly different nature: static errors (which the compiler may report) and dynamic errors (which the compiler cannot find). This false dichotomy completely warps the minds of progrrammers in these languages: Instead of becoming fundamentally stupid errors that the compiler should just go and fix, static errors become /more/ important than dynamic errors, leading to serious growth of dynamic errors because programmers tend to rely on the compiler for detection and correction of mistakes. | While a type checker can never guarantee that your program will do what you | wanted, it removes a *great* deal of bugs: in C++, I would frequently have | this bug when I divide one int by another and treat the result as a float. In a real programming language created by people who actually understand numerical types and mathematics, dividing one integer by another does not lose information and truncate the value to an integer if the result is not in fact an integer. The rational number that is an exact representation of integer division does not exist in languages where types are used to increase execution speed -- if you were primarily occupied with execution speed, you would not even be able to /invent/ the rational number since it may easily be a drag on performance. | That's a very nasty type of bug, especially in any kind of scientific/numeric | application. This kind of bug is a consequence of strong typing and thus must be caught by the strongly-typed system that introduced it. It is, however, fascinating that people who invent bug opportunities because of some elegance, according to some religion, of doing something the wrong way, do not understand that when they have chosen to /overcome/ the bug opportunity they have invented, such as with type checkers, other people may have removed the bug opportunity altogether and thus not be any worse off; they may indeed be /better/ off when the bug opportunity has been removed. Of course, provide a user of the bug- opportunity-ridden languages with a language where this kind of bug does not occur and he will feel frightened and lost, filled with emotions that prevent him from thinking and acting rationally. The simple concept of numeric type stacks (or towers or hierarchies) does not readily register with people used to over-specify their types, but it is also typical that they feel fear when bereft of their security blanket a.k.a. type checker and thus shut down their thinking. It is in fact a grave design error for integer division to return integers when the results are not always integers, but this moronic flaw in the language does not register with people who have narrowed their options to that which their type system can express -- Sapir-Whorf all over again -- and hence they cannot begin to understand a fundamentally different system. People also make the kinds of mistakes they can afford to make. Because they know that the type checker will kick in and catch their type bugs, they allow themselves to create type bugs to begin with by not expending the necessary mental capacity on this kind of inhumanly intricate detail. While probably not conscious except in the highly intelligent and introspective, when you realize that the cost of a caught type mistake is less than the cost of being totally anal about types when you write the code, you let the type checker figure these things out for you. The psychology of this phenomenon is not only glaringly obvious, it has been researched in many other areas. People who pay attention to detail consider the cost of making mistakes higher than the cost of correcting them for personal reasons. (This a productive use of emotions, but one may get carried away.) Whether verbalized or not, people /are/ consciously aware of the cost of making mistakes and breaking rules -- it is called taking risks. Risks are poorly understood because people are so frequently told not to take them. | Lisp is such an extreme case that I'm surprised people are surprised that | Lisp isn't used at JPL [1]. This is mere idiotic flame bait. This doofus is clearly not posting here to understand anything he wishes to learn but to parade his lack of mental resources and stagnated thinking. Judgmental types tend to favor strong typing and only one way of doing things. | It wouldn't even prevent you from dividing an int by a string in some branch | of code! This is more idiotic flame bait. Experienced programmers with many years of actual experience know that timing of the reported error is inconsequential and there is a significant loss of real value in pretending that static bugs are more important than dynamic bugs because some fancy type theory can find the former. In fact, every uncaught dynamic error proves that focusing too much on the static errors is a grave mistake. [ Oleg, please do not respond. You are not expected to overcome your personal problems and behave rationally in the face of fundemental criticism of your belief system. Save us the irrationality and the hatred of your feelings. ] -- Erik Naggum, Oslo, Norway Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.