From ...
From: Erik Naggum <erik@naggum.no>
Subject: Re: What is LISP?
Date: 2000/02/11
Message-ID: <3159296157829526@naggum.no>#1/1
X-Deja-AN: 584751612
References: <38A1BF22.B22BB9E1@raytheon.com> <3159120191728291@naggum.no> <38a47d9a.40618064@news.netvision.net.il>
mail-copies-to: never
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: newsmaster@eunet.no
X-Trace: oslo-nntp.eunet.no 950311264 10997 195.0.192.66 (11 Feb 2000 23:21:04 GMT)
Organization: Naggum Software; +47 8800 8879 or +1 510 435 8604; fax: +47 2210 9077; http://www.naggum.no
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5
Mime-Version: 1.0
NNTP-Posting-Date: 11 Feb 2000 23:21:04 GMT
Newsgroups: comp.lang.lisp

* Erik Naggum
| C++-style overloading is fundamentally evil, and is therefore not
| supported by good languages.  (note: this is not an opinion.)

* Vladimir Nesterovsky
| So far it's the only C++ feature as I know of, that has no correspondence
| in Common LISP.  That's the only argument of the C++ people that I don't
| know how to answer to.
| 
| While I'll take your word for it, could you please just provide me with
| some explanation, so that whenever that argument comes, I'd have an
| answer.

  sure.

  the main semantic argument against C++-style operator overloading is that
  there is nothing in the language that helps maintain consistency of any
  kind for each implementation of an overloaded operator.  in particular,
  each implementation may well have completely different argument lists,
  commutativity may differ at will, but you still have to cope with the
  same associativity and order of precedence.  a + is not a +, anymore.
  (witness the absurd and decidedly overcute use of << and >> for I/O.)

  the main pragmatic argument against C++-style operator overloading is a
  fatal design decision.  the choice of which function to call makes the
  use of overloaded operators downright dangerous: the return type of an
  overloaded operator is _not_ taken into account when choosing the
  particular implementation, which causes a cascade of decisions in nested
  or sequential forms over which you have no control.  in particular, code
  changes anywhere in an interconnected system can affect such decisions
  adversely, without even the possibility of warning or traceability since
  editing and (re-)compiling are so separated tasks.

  the main stylistic argument is that a reader of the code has no idea what
  to expect from _any_ expression that uses operators that _might_ have
  been overloaded, without _manually_ checking for surprises, _remembering_
  the types of objects, and trying to reconstruct the whole decision chain
  made by the compiler.

  so what makes a language feature evil?  first, when it wastes human brain
  time on minutiae that language features are supposed to help _conserve_
  or at least spend _more_ wisely.  second, when it forces people to
  second-guess the compiler to figure out what's going on.  third, when you
  despite second-guessing the compiler can no longer know for _certain_
  what will happen, but have to makes guesses in the first place.  all in
  all, a language feature is evil when it removes from the programmer's
  control what, precisely, he is doing, at all levels of abstraction and
  semantics and he is left with uncertainty and doubt, if not obscure bugs
  that are extremely hard to find and which makes systems using such
  features frightfully fragile.

  even the good uses of operator overloading, for which they were added to
  that miserable excuse for a programming language, destroy the ability of
  _any_ "visiting" programmer to know what _any_ expression means, meaning
  that the required level of intimacy with the code is tremendously high,
  which translates to "job security" for Joe C++ Programmer and "how to get
  royally screwed" for his employer.

  so not only is operator overloading evil, programmers who want it are
  looking for "insurance" if they should ever have any serious gripes with
  their employers.  as I have said previously, in connection with the need
  among C++ programmers to "protect" their data and methods, C++ is for
  thieves and bums who expect _others_ to steal, too; operator overloading
  is just more of the same: bad people are attracted to features with high
  abusiveness potential along with anal-retentive protection schemes
  because they expect everybody else to screw them, too.

  (very little of this is _mere_ opinion.)

#:Erik