Subject: Re: Lisp advocacy misadventures
From: Erik Naggum <erik@naggum.no>
Date: 25 Oct 2002 22:56:26 +0000
Newsgroups: comp.lang.lisp
Message-ID: <3244575386963745@naggum.no>

* Tim Daly, Jr.
| I was talking with a friend of mine about Lisp.  He said that people
| write things in C because of speed.

  But this is incorrect.  People use C because it /feels/ faster.  Like, if
  you build a catapult strong enough that it can hurl a bathtub with
  someone crouching inside it from London to New York, it will feel /very/
  fast both on take-off and landing, and probably durng the ride, too,
  while a comfortable seat in business class on a transatlantic airliner
  would probably take less time (except for getting to and from the actual
  plane, of course, what with all the "security"¹) but you would not /feel/
  the speed nearly as much.

¹ http://www.theonion.com/onion3838/faa_passenger_ban.html

| I said that Lisp will not necessarily cause a program to be slow, and in
| fact, because it lets you write a better program, things may even get
| much faster.  He said 'like what?'
| 
| Hmm.

  Better algorithms and type systems are well known to produce better
  performance by people who actually study these things.  It is often very
  hard to implement better algorithms correctly and efficiently in C
  because of the type poverty of that language.  Yes, you get to tinker
  with the bits as fast as the machine can possibly tinker, but, and this
  is the catch, you get to tinker with the bits.  If you are not super smart
  and exceptionally experienced, the compiler will produce code that is
  faster than yours.  If this holds from assembly to C, it holds from C to
  Common Lisp, given that you want to do exactly the same thing.

  The core problem is that C programmers think they can get away with doing
  much less than the Common Lisp programmer causes the computer to do.  But
  this is actually wrong.  Getting C programmers to understand that they
  cause the computer to do less than minimum is intractable.  They would
  not /use/ C if they understood this point, so if you actually cause them
  to understand it in the course of a discussion, you will only make them
  miserable and hate their lives.  People are pretty good at detecting that
  this is a likely outcome of thinking, and it takes conscious effort to
  brace yourself and get through such experiences.  Most people are not
  willing even to /listen/ to arguments or information that could threaten
  their comfortable view of their own existence, much less think about it,
  so when you cannot answer a C programmer's "arguments" that his way of
  life is just great the way it is, it is a pretty good sign that you let
  him set the agenda once he realized that his way of life was under threat.
  Since you have nothing to defend, your self-preservation instinct will
  not activate hitherto unused parts of your brain to come up with reasons
  and rationalizations for what you have done, you will not be aware that
  you have been taken for a ride before it is over and you "lost".

  If you deny people the opportunity to defend something they feel is under
  threat, however, some people go completely insane with rage and actually
  believe that you threaten them on purpose and that you willfully seek to
  destroy something very valuable to them.  However, some of the time, you
  meet people who /think/ and who are able to deal with threats in a calm
  and rational way because they realize that the threat is all in their head
  and it will not go away just because they can play word games with people
  and stick their head in the sand.  If it /is/ the threat they feel it is,
  they realize they had better pay some real attention to it instead of
  fighting off the messenger so they can feel good about themselves again.

  Much of the New Jersey approach is about getting away with less than is
  necessary to get the /complete/ job done.  E.g., perl, is all about doing
  as little as possible that can approximate the full solution, sort of the
  entertainment industry's special effects and make-believe works, which
  for all practical purposes /is/ the real thing.  Regular expressions is a
  pretty good approximation to actually parsing the implicit language of
  the input, too, but the rub with all these 90% solutions is that you have
  /no/ idea when they return the wrong value because the approximation
  destroys any ability to determine correctness.  Most of the time, however,
  the error is large enough to cause a crash of some sort, but there is no
  way to do transactions, either, so a crash usually causes a debugging and
  rescue session to recover the state prior to the crash.  This is deemed
  acceptable in the New Jersery approach.  The reason they think this also
  /should/ be acceptable is that they believe that getting it exactly right
  is more expensive than fixing things after crashes.  Therefore, the whole
  language must be optimized for getting the first approximations run fast.

  See how elegantly this forms a completely circular argument?  But if you
  try to expose this circularity, you necessarily threaten the stabiliity
  of the whole house of cards and will therefore be met with incredible
  hostility and downright hatred, and you will not even hear about the
  worst fits of insane rage until years later when some moron thinks he can
  get back at you for "hurting" him only because his puny brain could not
  handle the information he got at the time.

| Well, I'm blinded by the very misconceptions that led me to this point,
| and I'm not sure what to tell him.  Can you help me out?

  Ask him why he thinks he should be able to get away with unsafe code,
  core dumps, viruses, buffer overruns, undetected errors, etc, just because
  he wants "speed".

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