🚀 go-pugleaf

Thank you, Michael for a lucid, no-bullshit explanation of your view of the
object-oriented paradigm.  I have heard a similar summary from some of the
(precious few) other promoters of this paradigm who are willing to provide a
non-mystical comparison of it to more established programming techniques,
using conventional computer science terminology.  This leaves me with two
unanswered questions:

(1) What is the difference (other than a rather contrived, anthropomorphic
    view of the relationship between functions and values), between O-O
    programming and the ten (?) year old theory and practice called "abstract
    data types"?  The fundamental belief with technical importance in
    both methods (with which I completely agree) is that pieces of programs
    should be divided into chunks that have a precisely documented interaction
    with other chunks, but the internals of which are completely unknown (or
    irrelevant to) other chunks.  Put more concisely, "separate WHAT it does,
    from HOW it does it, so that the HOW can be changed without affecting the
    WHAT".  Isn't O-O programming simply a special case of, i.e. one particular
    method for achieving, abstract data types?  It seems to lie completely
    under the definition of an abstract data type as a collection of types
    and functions on those types, together with the notion that we can have
    multiple objects of the abstract data type.

(2) Why is it so hard for O-O programming advocates to explain the advantages
    of their programming methodology without slipping into obscure, specialized
    O-O jargon, or invoking the religious argument, "well you can't under-
    stand why it is better until you've done a large amount of O-O programming
    yourself"?
-- 
Michael Condict		{ihnp4|vax135}!m10ux!mnc
AT&T Bell Labs		(201)582-5911    MH 3B-416
Murray Hill, NJ