Subject: Re: macros vs HOFs (was: O'Caml)
From: Erik Naggum <>
Date: 10 Sep 2002 23:56:33 +0000
Newsgroups: comp.lang.lisp
Message-ID: <>

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