Subject: Re: What is LISP? From: Erik Naggum <erik@naggum.no> Date: 2000/02/11 Newsgroups: comp.lang.lisp Message-ID: <3159296157829526@naggum.no> * 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