






******************************************************************************
* The unzipped form of this file occupies 101158 bytes in a DOS file system. *
* This  document  is formatted for non-proportionate spacing and contains no *
* printer control characters. Page breaks are represented by dotted lines.   *
******************************************************************************






The critique of object orientation
***
A technical diatribe



06-23-1993


Gabriel Wyler

noctambule@aol.com
70661.2151@compuserve.com




Contents


  1.0 Introduction ......................................................... 1

  2.0 The flaws of object-oriented programming ............................. 2
  2.1 Introduction ......................................................... 2
  2.2 Flaws of the semantic model .......................................... 3
    2.2.1 A lopsided approach to semantic data modelling ................... 3
    2.2.2 Failure to support multiple classification ....................... 4
    2.2.3 Delusion by the phantom concept of multiple derivation ........... 5
    2.2.4 Semantic data modelling without a metadata facility .............. 8
  2.3 Flaws of the programming model ....................................... 8
    2.3.1 Distortion of the class/method relationship ...................... 8
    2.3.2 Dogmatic ban against class-dependent SWITCH statements .......... 10
    2.3.3 Conflict between data encapsulation and virtual derivation ...... 13
    2.3.4 False assumption about static knowledge of class identity ....... 14
    2.3.5 Naive optimism about incremental development .................... 14
  2.4 Flaws of the library construction model ............................. 15
  2.5 Flaws of the development model ...................................... 16
    2.5.1 Poor isolation of compilands .................................... 16
    2.5.2 Invasive preprocessing dictated by function homonymy ............ 16
  2.6 Summary and conclusions ............................................. 17

  3.0 The critique of general object technology ........................... 19
  3.1 Introduction ........................................................ 19
  3.2 The critique of object-oriented desktop management .................. 19
  3.3 The critique of object-oriented database management ................. 20
  3.4 The critique of object-oriented methodology ......................... 22
  3.5 The critique of object-oriented large-scale interoperability ........ 23
  3.6 Summary and conclusions ............................................. 23

  4.0 The myths of object orientation ..................................... 24
  4.1 Technical myths ..................................................... 24
  4.2 Journalistic myths .................................................. 26
  4.3 Mercantile myths .................................................... 27
  4.4 Junk myths .......................................................... 28

  5.0 The anthropology of object orientation .............................. 30






















1.0 INTRODUCTION



   Terminology

    There   are   two  possible  meanings  assigned  to   the   term   'object
    orientation' and its cognates in the present study:

    1.  a programming style

    2.  a software engineering culture

    This  distinction  is  of  paramount  importance.  In   many  instances  I
    explicitly indicate the intended meaning, but there are  also  a number of
    passages where I leave the job of disambiguation to the context.

   Structure

    The   present   paper  is  a  technical   diatribe   divided   into   four
    central sections:

    1.  In  Section  "2.0 The flaws of object-oriented programming" on page 2,
        I analyze the flaws of object-oriented programming  languages  through
        the  example  of  C++.  I  claim that  C++ is a naively  dogmatic  and
        flawed  toy  language  lacking  the  expressive  power  necessary  for
        capturing real-world complexity.

    2.  In Section "3.0 The critique of general object technology" on page 19,
        I  examine  the  emerging  culture  (and  cult)   of  general   object
        technology.  In  recent  years, general object technology has pervaded
        (and invaded) numerous  regions of software engineering far beyond the
        boundaries  of  compilers.  I claim that  general object technology is
        a verbal mirage. General object technology simply does not exist.

    3.  In  Section  "4.0  The  myths of object  orientation"  on page  24,  I
        survey the myths surrounding object orientation.

    4.  In  Section  "5.0 The anthropology of object orientation" on page  30,
        I conclude my study with comments on  object  orientation  as  a human
        phenomenon. I show that  object orientation  is  a societal and mental
        aberration.

   Caveat lector

    As  clearly  indicated  in its title, this paper  is a technical diatribe.
    My purpose  is  to debunk wrongheaded  trends  in software  engineering. I
    strive  to  build  solid  technical argumentation  most of the  time,  but
    occasionally I slip into a sarcastic, judgmental,  editorializing register
    of speech.









                                                                            1
------------------------------------------------------------------------------

2.0 THE FLAWS OF OBJECT-ORIENTED PROGRAMMING






2.1 INTRODUCTION


I  define  object-oriented  programming  as  a  programming  style  resting on
three pillars and aiming to satisfy three goals:

1.  data  encapsulation  (the protection of data structures from corruption by
    unlicensed  procedures,  the  support  of   the   class  construct  as  an
    autonomous unit of design)

2.  entity  classification  (derivation  of  data  structures, inheritance and
    overriding  of  methods,  virtual  method  pointers,  abstract interfaces,
    access control, etc.)

3.  support of code reuse (construction of extensible sealed libraries)

The fundamental  insight of incremental method management  can be  paraphrased
roughly in these terms: if procedures are clustered around data structures and
data  structures  are  derived  from  other  data structures in some organized
incremental  fashion,  then  clusters  of  procedures can also be derived from
other  clusters  of  procedures  in  some  organized  incremental fashion. The
construction  of  extensible  sealed  libraries is a refinement of incremental
method  development. At first blush these insights and goals seem quite sound.
I will show how unsound they truly are.

Object-oriented   programming  is   a  collection  of  uncodified  but  widely
accepted principles; C++ is an implementation of these principles. The present
section  examines  the  flaws of the object-oriented programming style through
the  example of a single object-oriented language, viz. C++. It follows, then,
that  this  paper  undertakes  neither  an exhaustive study of object-oriented
programming   nor   an   exhaustive  study  of  C++.  Characteristics  of  the
object-oriented  programming  style  not  exemplified by C++, on one hand, and
characteristics  of C++ not relevant to the object-oriented programming style,
on the other, are beyond the scope of the present study.

I  divide  the  flaws  of  object-oriented  programming   languages  into  the
following categories:

1.  flaws of the semantic model

2.  flaws of the programming model

3.  flaws of the library construction model

4.  flaws of the development model







                                                                            2
------------------------------------------------------------------------------

2.2 FLAWS OF THE SEMANTIC MODEL





2.2.1 A lopsided approach to semantic data modelling


Elementary  semantic  data  modelling  has   two  branches:  one   deals  with
referential  networks,  the  other  with  classification  hierarchies.  In the
interest  of  brevity,  I  will  omit a precise and detailed definition of the
theory  of  referential  networks.  Let  me  simply remind the reader that the
central  concepts  of  the  theory  of  referential  networks are primary key,
foreign  key, one-to-many relationship, many-to-many relationship, referential
integrity  constraint,  navigation,  join,  parts  explosion, self-referential
cycle,  etc.  Of  course,  classification hierarchies need not be discussed in
detail  because  they  dominate  object orientation and are assumed to be well
understood by the reader.

Object-oriented   programming    languages    concentrate   on  classification
hierarchies  and provide no specific support for referential networks. Is this
a  flaw  of  object  orientation?  Could  one  not  argue that object-oriented
programming  languages  simply  choose  to  specialize  in data encapsulation,
entity classification and incremental development, and not in the broader area
of  semantic  data modelling? Would it not be fair to say that object-oriented
languages  are under no obligation to provide specific support for referential
networks   just  because  classification  hierarchies  happen  to  share  with
referential  networks  the characteristic of constituting a branch of semantic
data  modelling?  In other words, could object orientation not simply disclaim
any  association  with semantic data modelling, claiming that any relationship
between entity classification and referential networks is accidental as far as
it  is  concerned?  Why  accuse  object  orientation of neglecting referential
networks  when  object  orientation claims to make no contribution to the more
inclusive discipline of semantic data modelling?

I  believe  that  object  orientation  is  in  the  business  of semantic data
modelling  whether  it  likes  it  or not. I support my claim by the following
arguments:

1.  It  is  exactly because the construction of extensible sealed libraries is
    the  capstone  of  object  orientation  that  object-oriented  programming
    languages must  provide specific support for referential networks. Serious
    libraries  are centered  on complex  network  data  structures,  not  just
    isolated   classification  hierarchies.    Library    and   classification
    hierarchy  are  far  from  being   synonymous.  A  functionally   complete
    library  package typically consists of numerous  referentially interlocked
    class hierarchies.

2.  Procedures  that  deal with referentially interlocked data structures must
    typically  be  methods  or  friends  of more than one such data structure.
    The  management  of  derivation  and   the  management  of  reference  are
    inseparable.

3.  Object  orientation  is about entity classification. Referential integrity
    constraints  create domains: both the parents and the children of a record
    (to use  popular  navigational  terminology) constitute attributes of that


                                                                            3
------------------------------------------------------------------------------

    record.  Thus reference, too, is entity classification.

4.  Metaclass  methods (factory methods) are managers of metadata. Metadata in
    the  object-oriented  sense  and  metadata  in   the  database  sense  are
    coterminous.  A program that manages metadata in the object-oriented sense
    can not shirk the  closely  related  and strongly analogous responsibility
    of managing metadata in the database sense.

5.  There  is a very fine line between hardening of collections of objects and
    virtualization of databases.

6.  The   relationship   between   referential   networks  and  classification
    hierarchies  shows  asymmetry  in  favor  of  the  former:  classification
    hierarchies can  be  recast ('faked out') in terms of referential networks
    but  referential  networks  can  not  be   subsumed  under  classification
    hierarchies. In  essence, referential  networks  are  more  powerful  than
    classification  hierarchies. C++ raises  the  less  powerful  of  the  two
    branches of semantic data modelling to formal language status and neglects
    the more powerful one.

7.  Multiple  derivation is a malformed concept but could accomplish a limited
    purpose  in  life  if  it  were  assigned  to  the  task  of  representing
    relational  joins. (Multiple derivation  is discussed  in  Section  "2.2.3
    Delusion by the phantom concept of multiple derivation" on page 5.)

In  sum,  class  hierarchies  without  referential  networks  are  of  limited
value.



2.2.2 Failure to support multiple classification


Classification  permeates  the  universe.  Classification is at  the  heart of
concept  building.  Classification  is  a  perpetual  human  activity  and  an
essential  consideration  in  all  areas  of programming. Whether a program is
about  business or science or software itself, it deals with classification at
every  turn.  Classification  is  the  soul  of  complex  designs.  (The terms
specialization,  IS-A relationship, derivation, subclassing and subtyping also
convey  the  notion of classification.) Classification is also the cornerstone
of virtual derivation, the mechanism that makes the construction of extensible
sealed libraries possible.

I  now  introduce the distinction  between simple classification  and multiple
classification.

Contemporary  non-object-oriented  languages  offer  multiple  classification.
To clarify the concept of multiple classification, let me use C as a syntactic
reference.

1.  A  collection of records embodies a multiple classification of entities if
    its record description is specified as an unrestricted STRUCT.

2.  The concept of unrestricted STRUCT is defined recursively. An unrestricted
    STRUCT  can contain any number  of UNIONs, the  layers of which,  in turn,
    can be unrestricted STRUCTs.



                                                                            4
------------------------------------------------------------------------------

3.  There  are  ENUMerated  selector  fields  associated  with the UNIONs of a
    multiple  classification.  There  is  a  one-to-one  relationship  between
    values of the ENUMerated domain and layers of the associated UNION.

Object-oriented  languages  emphasize   simple  classification  and  offer  no
language-specific  solution for multiple classification. Simple classification
is what would be accomplished by C if each STRUCT were allowed to contain only
one  UNION.  Given  that  C++  is a superset of C, it is, of course, true that
multiple   classification   is   available  in  C++  as  well.  However,  when
classification is studied within the object-oriented framework, classification
support  is  understood as sui generis specific object-oriented classification
support.  C++  offers  sui generis specific object-oriented support for simple
classification  but  not for multiple classification. It can not be emphasized
strongly enough that multiple classification is overwhelmingly the norm in all
areas  of  programming,  from  the run-of-the-mill business application to the
optimizing  compiler  and  the  advanced  graphic  library. The requirement of
multiple  classification  can  not be shrugged off. Failure to provide support
for  multiple  classification is a daring bluff. Object-oriented languages are
ill-suited  to  the  task  of serious semantically oriented programming, since
they support only an impoverished form of one half of semantic data modelling.



2.2.3 Delusion by the phantom concept of multiple derivation


At  first  blush,  multiple  derivation  seems  to  be  a straightforward  and
innocuous  generalization  of simple derivation: in the case of N-way multiple
derivation,  the  derived  class  concatenates N base structures and specifies
inheritance  or  override  for  N  sets  of  base methods. On closer scrutiny,
however,   multiple   derivation  proves  completely  impervious  to  semantic
interpretation.  It  is  my  contention  that  the  availability  of  multiple
derivation in object-oriented programming is not just accidental and pointless
but outright harmful. Multiple derivation invites parasitic concepts, suggests
a  delusive  view  of data, and engenders contorted procedural logic. Multiple
derivation  is  opportunistic  noise,  pretentious  claptrap, garish syntactic
glitter, pompous nonsense. Multiple derivation is a chimera.

The  lure  of  syntactic  generalization  is  not  a  good  enough  motive for
incorporating  an  exotic  construct  in  a programming language. One does not
stuff  syntactic  constructs  into  a language just because the opportunity is
there.  One  has  to  validate  the  construct on the semantic level by asking
questions of this nature:

   What is the construct's root in the real world?

   What deep need motivates the construct?

   How will the construct be used?

   What  common  computational  phenomenon  is  powerfully  captured  by  the
    construct?

   What hidden pattern of data does the construct illuminate?

   Is  the  construct  trivially  reducible  to other constructs, or does its
    expressive power reflect an emergent aspect of reality?


                                                                            5
------------------------------------------------------------------------------

   How does the construct dovetail with other constructs of the language?

Accordingly,  we  have  to  ask at least the following questions when  dealing
with multiple derivation:

   What  is  the  place  of multiple derivation in the theory and practice of
    entity classification and referential networks?

   To what patterns of method management does multiple derivation give rise?

Before proceeding to show that multiple derivation has no deep identity and no
real  purpose  in  life,  I  would like  to  point  out  that even its name is
fraudulent.  What  is  commonly referred to as multiple derivation is really a
merger  of  lineages  followed  by simple derivation and the most conventional
form  of method management. This must be forcefully emphasized lest the reader
fall  into  the  clutches  of the misconception that there is any relationship
between  multiple derivation and multiple classification. It can not be stated
strongly  enough  that  the  concept pair of simple and multiple derivation is
distinct from the concept pair of simple and multiple classification.

Multiple  derivation  seems to be suggested by,  or  adaptable to, a number of
semantic scenarios. All of them collapse under closer scrutiny.

1.  Ordinary containment of multiple records

    Ordinary   containment   does  not  justify   the   heavy   machinery   of
    multiple derivation.

2.  Containment supporting relational joins

    Containment  supporting  relational  joins  is  a  reasonable  application
    for    multiple    derivation.   E.g.,   the   collection   of    teaching
    assistants can be obtained  by  equi-joining the collection of instructors
    and  the  collection  of graduate  students  over  the  shared  column  of
    campus  identification  number.  Teaching   assistant   probably  inherits
    or  overrides   all  the  methods  of   instructor  and  all  the  methods
    of  graduate student and may, in addition, contribute  a  few  methods  of
    its  own.  Thus  the  object-oriented  rendition  of relational  joins  is
    characterized  by additive growth  of  method  population.  Unfortunately,
    object  orientation  isolates itself from  referential networks  and  thus
    multiple  derivation   can  not  be   credited   with   the   support   of
    relational joins.

3.  Multiple classification

    The   hypothesis   that   multiple   classification   is   the   root   of
    multiple derivation has to be dismissed for two reasons.

    a.  I   will  use   the  behavior  of  methods  as  a  touchstone.  If  an
        entity is classified  along two dimensions D1 and D2 and  the  fan-out
        widths of these two  dimensions  after  one  level  of  classification
        are  WD1 and WD2 respectively, then  the  number  of  overrides  of  a
        single  method  after   one  level  of  classification  could   be  as
        high  as WD1*WD2 in  the  least favorable  case. By contrast,  if  two
        lineages  L1 and L2 are merged and the number of methods of these  two
        lineages  is  ML1  and  ML2  respectively, then the  number of methods
        associated  with the two lineages after merger can not exceed ML1+ML2.


                                                                            6
------------------------------------------------------------------------------

        One  may  have  to  add  a  small  number  of  methods associated with
        the  merger  itself, rather  than  with  individual  lineages.  It  is
        easy  to  see that multiple classification  gives  rise  to  explosive
        multiplicative  growth   of  method   population  at   each  level  of
        derivation, while merger of  lineages  gives rise  to additive  growth
        of  method population and is unlikely  to be iterated at each level of
        derivation.

    b.  If,   contrary   to   the  above  reasoning,  a  particular  case   of
        merger  of lineages  can  be reduced to multiple  classification, then
        that  case of merger of  lineages  is  simply  a  flawed  design.  Let
        me  illustrate  this  claim  by  a  simple  example.  Interest-bearing
        checking  account   should   not   be  derived  from   the  merger  of
        interest-bearing account and checking account. Instead, account, which
        is  the  base   of  both   interest-bearing   account   and   checking
        account,  should   be   classified   along  the   two  dimensions   of
        interest-bearing behavior and checking behavior.

4.  Irreducible merger of lineages

    It is conceivable  that future  research  on semantic  data modelling will
    show merger of lineages to be a unique  and irreducible phenomenon of data
    semantics  and  combinatorial  analysis.  There  may  turn  out  to  be  a
    pattern  of  data  relationships  that  is  best  visualized as merger  of
    lineages  and  is refractory to   capturing   either  through  referential
    networks  or   through  multiple  classification.   It  is  unlikely  that
    object  orientation,  unable  to  cope  with  either   of  the  two  major
    branches  of  today's  semantic  data   modelling   technology,  will   be
    able  to  cope  with a mysterious  future  phenomenon such as  irreducible
    merger of lineages.

5.  Taxonomy

    The  last-ditch  attempt  to  save  merger  of  lineages  from  extinction
    invokes taxonomy.  Introductory  texts  on object orientation are charming
    bestiaries.  The zoo is the hoary standby that nannies and C++ instructors
    turn  to  when  all   else  fails.   However,  the  defense   of  multiple
    derivation  based   on   species   is  specious:   taxonomy   is   not   a
    candidate   for    formalization   through   object-oriented   programming
    constructs,  since  its  complexity  exceeds   the   expressive  power  of
    today's semantic data modelling by orders of magnitude.

By  way  of  conclusion  I  would  like  to mention the telltale phenomenon of
repeated,  or  diamond-shaped,  derivation.  Merger  of lineages may cause one
object  to appear twice in the ancestry of another object. Repeated derivation
is  a  source  of  run-away  sophomoric  debates  but  it  hardly deserves the
attention  lavished on it, since it is just a design flaw caused either by the
mismodelling  of  multiple classification or by the mismodelling of self-join.
Multiple derivation bears the stamp of immature language design.










                                                                            7
------------------------------------------------------------------------------

2.2.4 Semantic data modelling without a metadata facility


Semantic  data  modelling  is  a  concern  shared by database  management  and
object-oriented  programming. What is referred to as 'metadata' or 'schema' in
the  database literature is strongly analogous to the object-oriented concepts
of  'metaclass' and 'factory'. I will use the terms 'metadata' and 'metaclass'
interchangeably.

C++  deals  with  certain  aspects  of  semantic  data  modelling  but  has no
systematic  metadata  facility.  C++  does not treat classes as instances of a
built-in  factory  class and does not clearly formalize the concept of factory
method.  C++  has  an  accidental metadata facility. The C++ pseudo-factory is
made up of three poorly coordinated plants:

1.  The method routing facility

    The  method   routing   facility  is  completely   hidden   and   can   be
    neither controlled nor inspected by the user. It is diffuse and wasteful.

2.  The constructor/destructor facility

    The  constructor/destructor  facility  is  so arcane  and treacherous that
    some  C++  texts  find it necessary  to  devote more space to its pitfalls
    than to the discussion of entity classification and abstract interfaces.

3.  The static member facility

    The static member facility has the following unattractive characteristics:

    a.  The  mixing  of  static  and  non-static  members  in a  single  class
        construct obfuscates the true nature of class factory.

    b.  Storage  class  and  decriptive  level   are   confused.  The  storage
        class of metadata  can  not be controlled by the user. E.g., it is not
        possible to keep the metadata of a group of classes on the heap.

    c.  The  constructors  and  destructors of static data members run outside
        the   program's  scope.  This  makes  the  instrumentation  of  static
        data members extremely tricky.




2.3 FLAWS OF THE PROGRAMMING MODEL





2.3.1 Distortion of the class/method relationship


The  goals  of  quality  and  productivity  in  software engineering  strongly
suggest  the principle of data encapsulation. Data structures must be accessed
only by a small number of licensed procedures specializing in the manipulation
of  their  data  structures.  C++  uses a cross-referential safety scheme: the


                                                                            8
------------------------------------------------------------------------------

declaration  of  a  class  includes  the  declaration  of  its methods and the
definition  of  a  method includes a reference to the class it is a method of.
However,  the  class/method  relationship  in  C++ is warped. The objective of
documenting  and  controlling the method status of functions does not conflict
in  any  way  with  the  practice  of granting multiple method affiliations to
functions.  Framing  the class/method relationship as a many-to-many matrix is
simple,  intuitive  and  in  no  way  detrimental to the ideals of quality and
productivity.  Limiting  the class association of methods to a single class is
arbitrary, unnatural and unrealistic.

There  are  at  least  two  well-known  contexts  or scenarios  that  make the
many-to-many relationship between methods and classes highly desirable.

1.  An  N-way  join  requires  a  procedure  with N method affiliations if the
    collections  joined  are of unlike data types.  More generally,  any truly
    N-ary operation,  i.e.  any  operation  dealing  with  N  truly  different
    dimensions, requires procedures with N method affiliations.

2.  Even  procedures  that  have  only one major method loyalty need access to
    low-level global structures.

There  are  three work-arounds available in C++ when a routine needs access to
data in two or more classes.

1.  Certain  data  members  can  be  made public. This approach is unanimously
    rejected by all serious practitioners of C++.

2.  Data  members  can  be  accessed  through  accessor functions, i.e. public
    function  members  whose  only  purpose  in  life  is  to  provide  public
    access to private data members in a controlled manner. The use of accessor
    functions has several drawbacks:

    a.  Accessor functions tend to proliferate.

    b.  References to accessor functions tend to proliferate.

    c.  The  use  of  accessor  functions  introduces undesirable asymmetry in
        the syntactic  documentation  of a method's  inputs:  some inputs will
        be documented as  input  parameters of the method itself, while others
        will be documented as output  parameters of functions invoked  by  the
        method.

    d.  The   accessor   stratagem   is   a   thinly   disguised  and   costly
        circumvention of encapsulation.

    e.  The use of accessor functions tends to affect a program's clarity.

3.  A function needing data from two classes can be declared to be a method of
    one  and  a   friend  of  the  other.  The  friend  construct  raises  the
    class/method  relationship  to   the   many-to-many  level  and  seems  to
    overcome the arbitrary limitation  which  I  bemoan.  However,  the friend
    construct  must be rejected because  it is a blatant  circumvention of the
    data  encapsulation principle and degrades  the  quality  of  programs  by
    introducing  intuition-ruffling asymmetry.  Even though  two  objects  may
    play perfectly  symmetrical  roles in  the  logic  of a  procedure,  their
    symmetry is obscured in the code.



                                                                            9
------------------------------------------------------------------------------

    a.  A  function's  method  status is encoded both in the class declaration
        and the  function's  definition; a function's friend status is encoded
        only in the class declaration.

    b.  The  object  itself is  a  privileged parameter  of its methods and is
        passed to  them  by means of the dot notation; the object is passed to
        its friends as an ordinary parameter.

    c.  Methods have access to the THIS pointer, friends do not.

It  is  easy   to  see  that  the  flaws  of   C++'s  encapsulation  semantics
compromise C++'s entire framework of derivation. If the ban on multiple method
affiliations were lifted, most of C++'s derivation-related syntactic machinery
would  collapse.  A  procedure  with multiple method affiliations could not be
identified  by  a  single  two-part name consisting of class name and function
name  separated  by  a  dot.  The  THIS  notation  would go the way of the dot
notation. Method management would be shaken in its foundation.



2.3.2 Dogmatic ban against class-dependent SWITCH statements


The  elimination  of the SWITCH statement as  a form  of class-dependent  path
selection  is a central issue in discussions of object-oriented programming. I
will now summarize the object-oriented position regarding class-dependent path
selection and comment on its weaknesses.

1.  Summary of the object-oriented position

    Please  note   the  quotes  of  oblique   speech  surrounding  the  entire
    paragraph that follows.

    'In  object-oriented  programming  the  class  type  is internally managed
    by   compiler-generated   machinery   and   is  not   disclosed   to   the
    client;  in   non-object-oriented   programming   the   record   type   is
    managed explicitly by program  logic  and  is  used  as  a  basis of  path
    selection. The  object-oriented programming  technique  of  virtual method
    pointers  and   dynamic   method   binding   obviate  the  need   for  the
    conventional  class-dependent  SWITCH  statement;  in  non-object-oriented
    programming  the  relationships  among  class-dependent SWITCH statements,
    UNIONs and  ENUMerated  selector  fields  are  buried  in  the user  code.
    Circumvention  of  virtual  method pointers and dynamic method binding  by
    means  of    explicit   reference   to    class  type   is  redundant  and
    unsafe.  The  object-oriented  solution  is  superior, since  new  derived
    classes can be added to  extensible  sealed libraries  without maintaining
    complex  SWITCH  statements.  Class  types  must   be  managed  implicitly
    through compiler-generated  method selection  machinery  and  must  remain
    unnamed in the client code.'

    The  object-oriented  position  regarding  class-dependent path  selection
    can be  referred  to  as  the  principle  of  run-time anonymity of record
    types   or  the  Lohengrin  principle.   Lohengrin   was  not  a  computer
    scientist  but  a knight of the  Holy  Grail  and  a  Wagnerian  character
    who protected the weak and the innocent on the condition that they not ask
    him his name.



                                                                           10
------------------------------------------------------------------------------

2.  Weaknesses of the object-oriented position

    a.  Multiple  classification  can  not  be  handled  by  means  of virtual
        method     pointers     and     dynamic     method     binding.     In
        non-object-oriented   programming,  multiple   classification  can  be
        captured  by  means  of   nested  SWITCH  statements  and  appropriate
        subroutinization; in object-oriented programming,  a  separate derived
        class has to be declared for each unique combination of terminal nodes
        drawn  from   distinct   simultaneous  classifications.  Clearly,  the
        object-oriented solution  has much weaker expressive power. The number
        of  classes  that  have  to  be  declared   in  a  realistic  multiple
        classification  scheme  is  unwieldy.  Large  multiple  classification
        schemes  exceed the practical limits of compile-time declarations.

    b.  The  principle  of  run-time anonymity  of  record  types  is  clearly
        impractical  and  intolerable,  since  there  are numerous  common and
        unavoidable   boundaries   between   object-oriented    programs   and
        non-object-oriented programs at which the identity of record types has
        to be revealed.  One  simply has to accept the fact of  life  that the
        record  type is  best managed  explicitly  by  program  logic.  It  is
        difficult  to  see how  the  record  type  can be ignored  in database
        work, in data  communications  work,  or  in  the  context  of  a wide
        variety of low-level utilities  involved in diagnostics,  maintenance,
        reorganization and audit. The need  for  overcoming  the  difficulties
        of  run-time  anonymity   is  obviated  altogether  if  the  dogma  of
        run-time anonymity is abandoned.

        Various   underhanded  techniques  have  been  devised   for  run-time
        type  identification  within  the   object-oriented  framework.  These
        techniques  are   astutely  schizophrenic  ways  of   circumventing  a
        self-inflicted   artificial   stricture.   The   authors  of   several
        well-known   quaintly  perverse  texts  on  object-oriented   theology
        laud  the  inquisitors  of  the C++ faith  who  bent the  populace  to
        forswear  the  evil  practice  of  run-time  type  identification  and
        extirpated  from  the   language  even  the  faintest  temptation   to
        commit  that  unspeakable  sin.   With  a  cavalier   about-face,  the
        same  authors proceed  to  congratulate  themselves  on  reintroducing
        the  very same practice through the back  door  of obscure and  costly
        pseudo-factory  techniques.  C++  theorists are  also  reminiscent  of
        socialists  who first bankrupt an economy  and  then  take  credit for
        reinventing the market mechanism.

    c.  Paths   diverge  and  converge  multiple   times  based  on  the  same
        ENUMerated  path  selection   field  in   typical  non-object-oriented
        programs   that  address   complex   realistic   classifications.   In
        other  words,   non-object-oriented  programs  may   contain  multiple
        parallel  class-dependent  SWITCH statements that differ only  in  the
        subroutines they  call  at  corresponding  nodes.  The  postulate that
        object-oriented  programs can  not  contain  even one  class-dependent
        SWITCH  statement,   much   less  multiple   parallel  class-dependent
        SWITCH  statements, gives  rise  to  a  high  degree  of unnatural and
        counterproductive fragmentation of private methods.

    d.  Considerations   of   conciseness  and   performance   often   dictate
        unconstrained combinations  of  tabular  and procedural path selection
        techniques.



                                                                           11
------------------------------------------------------------------------------

    e.  SWITCH-less  programming  has  no  solution  for  the problem of  path
        selection   involving  two  or  more  classes.  Likewise,  SWITCH-less
        programming   has   no   solution  for  the  problem  of  nested  path
        selection  if a  class-dependent decision is made on a lower  level of
        control.

    f.  Much  ink  is  wasted  on  the  question  of  performance  of  dynamic
        method binding.  It  is  stated  with great zeal in all discussions of
        dynamic  method binding  that  the performance loss caused  by  it  is
        infinitesimal. This claim is a  red  herring:  it  conceals  the truth
        by  the truth. Given identical logical richness,  the  performance  of
        the  object-oriented  solution  (which  is  based  on  dynamic  method
        binding) will not  only not be infinitesimally worse than that of  the
        non-object-oriented  solution  (which  is based on SWITCH statements),
        but,  on  the  contrary,  will  most  likely be  significantly better.
        This   is  not  surprising:  compile-time  resolution  beats  run-time
        resolution.   The   term   'dynamic  method  binding'  is   deceitful,
        since  what  it really refers to is static  compile-time resolution of
        method selection. Dynamic method binding  is dynamic  only in name. In
        judging  whether  object-oriented  method  resolution  is  dynamic  or
        static,  what  really matters is whether methods are pre-packaged with
        object  instances  at  compile  time,   not  whether  the   method  of
        pre-packaging  involves  a  level  of   indirectness.  Object-oriented
        method selection is tabular and  involves  a  level  of  indirectness,
        but  it  is  static,  since  it  follows  an  impoverished   formalism
        imposed  by  the   compiler.  There  is  no  loss  of  performance  in
        object-oriented  method  selection; what  there  is a loss of is power
        and  generality.  Even  though  the  method  is called  dynamic, it is
        anything    but     that.     By      contrast,    non-object-oriented
        record-type-dependent  path  selection  is  unconstrained  and   fully
        dynamic. Its deep code  path can  also cause poor performance, a price
        exacted by rich functionality.

    g.  In  sum,  the  ancient  technique   of   record-type-dependent  SWITCH
        statement   and  run-time  type  identification  can  simply  not   be
        exorcized  from  complex  programs.   SWITCH-less  programming  is  an
        exercise in futility.

It has been argued that the true  source  of  language power is discipline and
specificity,  not license and genericness. Switching momentarily to PASCALese,
can   a  case  be  made  for  CASE-less  programming?  Can  the  principle  of
parsimonious  language  design  be  carried  to  the  extreme  of  eliminating
record-type-based  path selection? Is SWITCH another GOTO? I believe that GOTO
is harmful, while record-type-dependent SWITCH is necessary. Nevertheless, the
anti-SWITCH  campaign  is  a fascinating phenomenon. SWITCH was the structured
programming  camp's chief weapon against GOTO. If SWITCH were to go GOTO's way
and object orientation were worthy of being called a revolution, then we would
be witnessing another revolution devouring its children.











                                                                           12
------------------------------------------------------------------------------

2.3.3 Conflict between data encapsulation and virtual derivation


This section is about the emperor's new capsule.

Procedures  using  the public interface of a  class are  often  referred to as
its  clients.  By  analogy,  I  will  refer  to  the methods of a class as its
servers.   I   will  now  introduce  the  concept  pair  of  server-based  and
client-based  data  encapsulation.  The distinction will be based on where the
object  is  defined or allocated and on how much declarative material needs to
be included in the client code.

1.  Server-based data encapsulation

    The  traditional  approach  to  data  encapsulation  is  server-based. The
    data  structure  is  defined  or  allocated  by the server module and only
    the  server  module  has  to  include  a  full  declaration  of  the  data
    structure. The client of the   server   module   is   completely   unaware
    of   the   data   structure's  implementation.   The   data  structure  is
    completely hidden inside the server module  and  only the  server module's
    parameter  list  is  exposed   to  the  client.  The  implementation  data
    structure  is  referenced  by the  client through an essentially  typeless
    handle.

2.  Client-based data encapsulation

    The  object-oriented  approach  to  data  encapsulation  is  client-based.
    The data structure is defined or allocated by the client and is referenced
    by  both  the client and  the server. The client  has  to include both the
    public interface and  the  implementation  of the data structure. In  C++,
    the   interface   and  the  implementation   are   declared  in  a  single
    hydrocephalic  construct.  The implementation  data  structure  is  passed
    to the  server as a parameter fully described in the client.  Client-based
    data  encapsulation   is  self-defeating.  In  fact,   client-based   data
    encapsulation is data encapsulation only in name.

Data  encapsulation and  the  construction of extensible sealed libraries  are
conflicting  objectives. The most effective way to protect a data structure is
to  hide  its  implementation  behind the armor of method interfaces. In total
disregard   for   this   self-evident  principle,  C++  requires  that  object
implementations   be   declared   in   the   client  code.  Client-based  data
encapsulation  facilitates the construction of extensible sealed libraries and
complicates  everything  else.  Virtual  derivation  is  a  clever  invention,
inasmuch  as it exposes just the right amount of source code for potential use
by  unspecified  future  extensions, but it undermines data encapsulation. C++
accomplishes  the  diametrical  opposite  of  its own stated objective. Object
orientation  is embroiled in the intrinsic conflict of its own omnivorousness.
The  price  of  library  extensibility  is  a  head-on  collision  with  sound
programming   principles.  Client-based  data  encapsulation  is  a  grotesque
travesty.









                                                                           13
------------------------------------------------------------------------------

2.3.4 False assumption about static knowledge of class identity


Classes proliferate. The nodes  of a complex  classification hierarchy may  be
too  numerous  to be named, declared and managed exhaustively at compile time.
The number of nodes of a complex classification hierarchy may be so high as to
exceed  the  number  of  instances  in  the entire hierarchy. In fact, one may
encounter  classification hierarchies in which no two instances are associated
with  a  common  node  and,  as  a  result,  the distinction between class and
instance loses its meaning altogether.

C++   practices    client-based   data   encapsulation.    The   problem  with
client-based data encapsulation is not only that it is self-defeating but also
that  in  many situations it simply can not be accomplished. Client-based data
encapsulation makes the naive assumption that the client code knows what class
it  wants  to  be  instantiated.  Typically, the client only knows fragmentary
facts  about  the  future instance of a still unidentified class and it is the
server's  responsibility  to  complete  the  class identification process. The
client  specifies  a  query  argument,  i.e., an expression of key and non-key
attributes,  in  the  parameter  list of a server method. The server, in turn,
applies  an  algorithm  across  multiple  classes,  eventually  zeroes in on a
specific  class,  and  allocates  it on the client's behalf. The server has to
include  all  classes  of  the  classification  hierarchy. The key and non-key
attributes included in the search argument are not necessarily fully contained
in  the  root  of  the  classification  tree  and  may very well span multiple
boundaries  of  derivation  increments. It is pointless to saddle clients with
the inclusion of all classes of the classification hierarchy or to expect them
to  shoulder  a  part  of  the  server's responsibilities. Many classification
schemes  are  embodied in external databases, not in internal data structures:
fonts,  parts  of  speech  and  species  can  not  be  declared as types fully
identified at compile time.



2.3.5 Naive optimism about incremental development


I refer  to the combination  of  entity classification and the construction of
extensible  sealed  libraries  as  incremental  development.  The  fundamental
limitation  of  incremental development is that it is incremental. It is based
on a simplistic world model in which two assumptions are satisfied:

1.  The  only  form  of change in data structures along the derivation tree is
    accretion of quanta of specialization.

2.  The   change   of  methods  along  the  derivation  tree  is  gradual  and
    proportionate to the change  of  data structures. Methods  have  a  strong
    tendency  to   be  inherited  or  overridden  with   unchanged  signature.
    Overriding methods  tend  to  invoke the  corresponding overridden methods
    and to deviate from them only mildly.

In  reality,  it  is  not  possible  to  milk  derivation  indefinitely.  When
structural  change  in  the  classification  tree  is  overdue,  resisting its
pressures  creates  the  risk  of  catastrophic  disruptions.  It  may  become
imperative  to  dislocate, split, or collapse nodes, to impact higher nodes by
changing  data  members or introducing new methods or modifying signatures, to
change  access  control  along  the  hierarchy,  etc. There are times when the


                                                                           14
------------------------------------------------------------------------------

simplistic  world  model  of  conservative  gradual  change has to give way to
real-world  explosive  complexity.  The  technique  of  virtual  derivation is
ingenious,  but  only  as  long  as  it  applies. It is dangerous to sacrifice
substance  generously  while  holding on to form compulsively. It is not clear
whether  an extensible sealed library developed along object-oriented lines is
necessarily  a  better investment than a conventional library with a fixed but
rich  set  of  options  and  island  code  adaptors. Given that classification
hierarchies  can  only  be  extended within predictable limits, it is wiser to
push the original design to those predictable limits than to pursue the utopia
of   eternal   extensibility.  Change  in  software  is  fuelled  by  emergent
complexity,  not  by  the  availability of phantasmagorical language features.
Emergent  complexity  can not be captured by a naively dogmatic and flawed toy
language. Emergent complexity can not be wished away.



2.4 FLAWS OF THE LIBRARY CONSTRUCTION MODEL


The construction of extensible sealed libraries is billed as the foundation of
code  reuse.  The  library  construction  model  must  be considered  the most
important link in the web of object-oriented teachings since its impact on the
outside  world  is the strongest. The library construction model bristles with
inconsistencies and undesirable characteristics. It requires careful analysis.

1.  Virtual  derivation  dictates  that  data  encapsulation  be client-based.
    Client-based  data encapsulation is data encapsulation  only  in name. The
    price  of  library   extensibility  is  a  head-on  collision  with  sound
    programming  principles.   See  Section  "2.3.3  Conflict   between   data
    encapsulation and virtual derivation" on page 13.

2.  Classification  hierarchy  and  library  are far from synonymous. A single
    hierarchy  of  simple  classification  is  not necessarily  a functionally
    complete  library.   Functionally    complete  libraries  manage  numerous
    referentially interlocked   multiple   classification   hierarchies.   See
    Section  "2.2.1 A lopsided approach to semantic data modelling" on page 3.

3.  In  many  cases  client-based  data  encapsulation  is simply not possible
    because   the   client   code    possesses   only    fragmentary    static
    compile-time  knowledge   of   the   intended   object's   identity.   See
    Section  "2.3.4 False assumption about static knowledge of class identity"
    on page 14.

4.  There  is  more  to  reuse than subclassing. Subclassing can not be milked
    indefinitely.  Emergent  complexity  dashes  reductionist  illusions.  See
    Section "2.3.5 Naive optimism about incremental development" on page 14.

5.  Many  libraries  constructed  in  extensible  sealed style do not actually
    invite  subclassing.  The  extensible  sealed  library  construction style
    carries more glamor than usefulness.

6.  Extending  a  library that has complex behavior and is endowed with a high
    number  of  methods may  prove  a  dangerous  or impossible  mission.  The
    formalism of method  derivation does not  reduce  the degree to which  the
    inner workings of class  libraries  have  to  be understood. The developer
    engaged in  extending a sealed library must fully master  the semantics of
    each and every exposed class header.


                                                                           15
------------------------------------------------------------------------------

7.  The  developers  of many low-level building block libraries misjudge their
    targets'  make-or-buy   decision:   they   overestimate   their   targets'
    propensity  to buy  what  is  available  and underestimate  their targets'
    need  to  make  what   is  necessary.   Many   low-level   building  block
    libraries  cannot compete with  the  equivalent  tailored  native  code of
    intermediate-level functional components.  The  value of an extremely rich
    string object is questionable, since a message assembler  or a  parser can
    afford  its  own  ad  hoc  string  management  scheme.  The  value  of  an
    extremely  rich  collection  object  is  questionable,  since an operating
    system's storage manager or a  compiler's referential network manager will
    not necessarily opt for the use of independently developed linked lists.

8.  In  sum,  extensible sealed libraries are overcomplicated for simple tasks
    and simplistic for complex tasks.




2.5 FLAWS OF THE DEVELOPMENT MODEL





2.5.1 Poor isolation of compilands


Client-based  data  encapsulation  gives  rise  to  an excessive recompilation
cascade effect.

1.  The  modification  of  any private or public member impacts all clients of
    any public interface and, of course, all methods and friends.

2.  The  client  of  one  method  of a class has to include not only all class
    headers required for the support of the parameter list of the given method
    but  also  all  class  headers  required  for the support of the parameter
    lists  of  all  other  methods   of  the   same   class.  This  creates  a
    horizontal cascade of inclusion requirements.

3.  Any  time a class header is included to satisfy any inclusion requirement,
    all    parameters  of   all   methods   may   give   rise   to  additional
    inclusion requirements.  This creates  a  vertical  cascade  of  inclusion
    requirements.




2.5.2 Invasive preprocessing dictated by function homonymy


The  two  forms  of  function  homonymy  in  C++,  viz.  method  override  and
function overloading, must be resolved by a preprocessor phase before function
names  can  be  exposed  to  the  linker,  to the debugger or to the operating
system.  However, disambiguated names produced by a preprocessor phase are not
fit for human consumption. The phenomenon of mechanical disambiguation poisons
the  development  cycle  and  degrades  programmer productivity. The fact that
in-line  functions  and  constants  are  often praised as antidotes to the ill


                                                                           16
------------------------------------------------------------------------------

effects  of  the  conventional  C macro preprocessor only adds piquancy to the
horrors of name mangling.



2.6 SUMMARY AND CONCLUSIONS


I  divided  the  flaws  of C++ into  four categories for the  purposes  of our
discussion.

1.  Flaws of the semantic model

    a.  The   relationship   between  entity  classification  and  referential
        networks is not dealt with in a principled manner.

    b.  Multiple classification is not supported.

    c.  Multiple derivation has no deep identity and no purpose in life.

    d.  No systematic metadata facility is provided.

2.  Flaws of the programming model

    a.  The  dogma  of  one-to-many  relationship  between data structures and
        methods greatly complicates and degrades procedural logic.

    b.  The  dogma  of SWITCH-less  programming turns the  software laboratory
        into a horror chamber.

    c.  Client-based  data  encapsulation  facilitates  the   construction  of
        extensible sealed libraries but is data encapsulation only in name.

    d.  Client  code is  naively assumed to possess  compile-time knowledge of
        object identities.

    e.  The   framework   of   gradual  and  proportionate  method  derivation
        is unrealistic.

3.  Flaws of the library construction model

    The  construction  of  extensible  sealed  libraries   is  overcomplicated
    for simple tasks and simplistic for complex tasks.

4.  Flaws of the development model

    a.  Client-based      encapsulation    gives    rise    to    unmanageable
        recompilation cascade effects.

    b.  Function    name     ambiguity     is     resolved     by     invasive
        compiler-controlled artificial naming.

C++  foists  upon  its  users  a  naively  dogmatic,  unrealistic,  parochial,
impoverished  style.  Under  a  surface  of syntactic glitter, C++ has reduced
expressive  power.  C++  uses  excessive  syntactic cohesion to cover up total
semantic   incohesion.   C++  suffers  from  syntactic  obesity  and  semantic
emaciation. Does C++ at least offer simple means to a simplistic end? Does C++


                                                                           17
------------------------------------------------------------------------------

match  the  naivete' and impoverishment of its model with ease of learning and
ease  of  use?  Nothing could be farther from the truth. The paradox of C++ is
that it is too much and not enough.

C++  is  characterized  by  self-feeding  runaway complexity. C++ is not  help
but  hindrance.  C++ is medicine that kills the patient. C++'s recklessness is
most  apparent  in  the  molasses  of  its  impenetrable  spontaneous run-time
phenomena.  The  user  of C++ has to think with C++'s head about unpredictable
compiler-generated  idiosyncrasies. C++ exacts an exorbitant price of learning
for  the  privilege  of  complying  with  unnatural  standards.  C++ creates a
dysfunctional  world  and  makes  it accessible only through the gauntlet of a
perversely   overcomplicated,   complacently  exotic,  pompously  self-serving
run-time infrastructure.

C++  offers  an  autistic  coding  style arbitrarily  raised to the status  of
language  standard.  C++  is  a  haystack  of  hilarious hacks, a menagerie of
monstrous mechanisms, an assortment of arrogant adhockeries, an infestation of
incohesive  improvisations, a congeries of conflicting constructs, a bagful of
bleeding  bandaids.  C++  is a hodge-podge of solutions in search of problems.
C++   is  fraught  with  exotic  features,  gratuitous  acrobatics,  misplaced
emphases, baroque bric-a-brac.

A  good  program  is  a  highly readable story about synergistic abstractions,
told in a concise, clear and vivid style. Good programmers know what motivates
the  protagonists,  and  what  fuels  the  episodes,  of  their programs. Good
programmers  understand the fabric of the story they tell. Good languages help
good  story-telling  by  providing  simple  syntax and powerful semantics. C++
distracts  the  programmer's attention from the application domain by erecting
artificial  barriers  and setting wanton traps. C++ guarantees low quality and
low productivity.

The reader may question whether the act of pouring scorn on C++ contributes to
a serious analysis  of  object orientation. I  wish to forestall the erroneous
view  that  C++  is  an  imperfect implementation of a perfect model. I do not
believe  in  the existence of pure and corrupted object orientation. The flaws
of C++ are genetically foreordained in the flaws of object orientation itself.























                                                                           18
------------------------------------------------------------------------------

3.0 THE CRITIQUE OF GENERAL OBJECT TECHNOLOGY






3.1 INTRODUCTION


What  I refer to as general  object technology is  an alleged convergent trend
attributed to a number of software engineering disciplines. It is claimed that
the  waves of object orientation rush beyond the boundaries of object-oriented
programming  languages and permeate a number of fields of computing theory and
practice.  However,  the objectoplasm, a mysterious ether-like substance which
the  disciplines  grouped under general object technology partake of, is never
really  subjected  to  rigorous  analysis.  The  true nature of general object
technology  is  systematically  passed  over in silence. I carefully hedge the
definition  of  general object technology because I simply do not believe that
it exists. General object technology is a non-concept wrapped in the barnacles
of  hucksterism  enveloped  in  the  dense  fog  of  malarkey.  General object
technology is abject technology. I will rule it out of court and existence.

The  software  engineering  disciplines  that figure  most  prominently in the
context  of  general object technology are object-oriented desktop management,
object-oriented   database   management,   object-oriented   methodology   and
object-oriented  large-scale  interoperability. I will examine these areas and
show  that  not a shred of object orientation is detectable in them. They will
be consigned to the trash bin of irrelevance.



3.2 THE CRITIQUE OF OBJECT-ORIENTED DESKTOP MANAGEMENT


Conventional   graphic    desktops    are    iconized   container  hierarchies
functionally equivalent to character mode menu systems or shells. The terminal
nodes  of  conventional  graphic  desktop container hierarchies offer a single
terminal  icon  type,  viz. program or program masquerading as document, and a
single terminal icon behavior, viz. program launching.

Advanced graphic  desktops offer richly  generalized icon typology  and richly
generalized  icon  behavior.  Each icon type of an advanced graphic desktop is
governed  by a system-invoked mechanism that subsumes and generalizes all such
distinctions  as  terminal  icon  vs. non-terminal icon, document vs. program,
persistent  scope  vs.  transient  scope,  association  with  file  system vs.
association  with desktop registration database, etc. A mechanism is available
for  the  instantiation  of  icon types. The system has rich knowledge of what
each  icon  represents  and  reacts  in a richly differentiated manner to icon
manipulations.  Ultimately, programmers and users of advanced graphic desktops
can  create  any  imaginable entity and any imaginable behavior on the desktop
and  can,  in essence, turn the desktop into the equivalent of a client window
with open-ended application-like responses.

Flamboyantly  referring  to  icons  as objects does  not make  them objects in
the  object-oriented  sense.  Object  orientation  bears  as much relevance to
advanced  desktop  management  as  the  pretentious  display of heady chemical


                                                                           19
------------------------------------------------------------------------------

terminology to the enjoyment and grooming virtue of a shampoo.

1.  Icons  of  the advanced graphic desktop are not necessarily implemented as
    objects,  and  whether  they are should make no difference either from the
    end user's or the application programmer's viewpoint.

2.  There  is  no  reason  to  believe  that end users have positive cognitive
    response  to  a  complex  system-managed  or  application-managed  desktop
    icon taxonomy, and therefore exposing it is absurd.

3.  Application programmers need a mechanism through which they can respond to
    desktop  stimuli.  However,  there  is  no  reason  to  believe  that they
    are  interested  in becoming  tributaries  of  abstruse  operating  system
    internals,   in    developing   their   applications    in    a   narrowly
    circumscribed   style,   and  in  maintaining  continuity  with  a  highly
    specialized classification hierarchy alien to their concerns.

4.  Advocates  of  object-oriented  desktop management consider it politically
    correct  to  shroud  applications  in  the  metaphor  of  object behavior.
    Various guidelines  of  application  architecture  have  been devised  for
    creating the illusion  that  the  document itself  is an autonomous center
    of  processing. The autonomy  of  documents  is  vaguely  analogous to the
    autonomy  of  classes,  but   document-centered  application  architecture
    style  has  nothing  to  do with object-oriented programming.




3.3 THE CRITIQUE OF OBJECT-ORIENTED DATABASE MANAGEMENT


(Terminological note: API stands for application programming interface.)

The  relational  data  model  is  no  longer  considered 'the end of history'.
After roughly 15 years of absolute hegemony, the relational data model remains
dominant  in  traditional  business data processing but has begun to share the
DBMS  community's  attention  with  other emerging data models. The relational
data   model  has  limitations  that  are  no  longer  acceptable  in  certain
application  domains.  Thus  we witness the emergence of two new areas of DBMS
research and development:

1.  Non-row-oriented database management

    Non-row-oriented  data  structures  ('blobs')  have  come  into  their own
    in   several   important   areas.   Non-row-oriented   DBMSs   deal   with
    non-row-oriented  data  structures,  such  as  those  used  in  multimedia
    processing,  in   engineering   and  in  the  animate  sciences.  Bitmaps,
    graphs  and  self-describing  data  structures  are   some  of  the  newly
    discovered stars in the galaxy of database research.

2.  Extended-relational database management

    Relational  technology  is  found  wanting  even  in  certain areas  where
    row  orientation  remains  valid.  Extended-relational  DBMSs  attempt  to
    correct certain deficiencies of the traditional relational model:

    a.  The  relational  model ignores  the  importance of heterogeneous rows,


                                                                           20
------------------------------------------------------------------------------

        i.e.  of  entity  classification.  Newer   unconventional  DBMSs  deal
        with heterogeneous,  i.e.  classificational,  row-oriented  data.  Row
        declarations must  now  be allowed to  absorb  the  recursive  nesting
        of  STRUCTs  and  UNIONs,  i.e.,  STRUCTs  containing  multiple UNIONs
        containing multiple STRUCTs.

    b.  The  relational  model  ignores, or provides only half-hearted support
        for,   inter-row  semantic  phenomena,   such   as  those   found   in
        bill-of-materials processing and in unconstrained graphs.

    c.  The  relational  model ignores,  or provides only half-hearted support
        for, columns of unconventional data types.

    d.  The  relational  model ignores, or provides only half-hearted  support
        for, user-defined functions in selection clauses.

The  true  technical  aspects  of the relationship between  object orientation
and   non-traditional   database  management  are  covered  up  by  systematic
equivocation.  One  has  to  ask the question pointedly: what data structures,
what classification hierarchies, what methods and what method derivations does
object  orientation  really apply to in the context of DBMSs? This question is
not  susceptible  to a straightforward answer. Object orientation and database
management simply do not mix.

1.  We can eliminate the internal data structures and the metadata of the DBMS
    as loci of object orientation, since object-oriented  implementation alone
    does not confer object-oriented quality on a DBMS.

2.  Likewise,  whether the API of a DBMS is accessible only through a specific
    object-oriented  language  is  irrelevant  if  the API does not have other
    more  specific,    more    essential   object-oriented    characteristics.
    Besides,  a monolingual DBMS would not be a wise investment. The use of an
    object-oriented  programming language by the API's  client  can not  be an
    inherent requirement of a serious DBMS.

3.  The central characteristic of a DBMS is its data model, i.e., the array of
    generalized  data  structures and generalized operations it specializes in
    and caters  to. DBMSs create the illusion that the internal transient form
    of  data  is  a  shadow  of  its  external  persistent  form.   DBMSs  are
    one-level storage systems  in which the external persistent representation
    is  considered  primary  and  the  internal  transient  representation  is
    considered secondary. It  is difficult  to  see  what  data  encapsulation
    translates to in a framework where internal data structures are treated as
    hidden sewers,  operations  constitute  a  predefined  recursive  API  and
    operands are abstractions  beyond  the  syntactic  reach  of  conventional
    general-purpose programming languages.

4.  Database  management  and  object  orientation are antithetical because in
    object-oriented  thinking  the  external  persistent  data  is  considered
    merely a hardened object.

5.  It  is  difficult to see how the API of a DBMS can be regarded as a set of
    methods  if  it  does  not provide encapsulation for  any  data  structure
    either in the  implementation  or  in  the client  code.  Extensibility of
    the DBMS  through user-specified  island  code  is  a valuable capability,
    but it is difficult to see  how  user-specified  island  procedures can be
    regarded as  methods if the delivery  areas  are  not  user-specified  but


                                                                           21
------------------------------------------------------------------------------

    dictated by the data model and the metadata.

6.  A  DBMS  implemented  as an extensible sealed library would be an abstruse
    and outrageously costly extravaganza.

7.  A  radical  extended-relational  DBMS that caters to unrestricted multiple
    classification  hierarchies  both  on  the  external  persistent level and
    the internal  transient  level  would be extremely valuable but could  not
    be called object-oriented,  since  multiple  classification  runs  against
    the grain of object orientation.

Object-oriented     database    management   is   a    phantom   notion.   The
non-row-oriented and extended-relational data models are exciting new areas of
semantic  data modelling and of DBMS research. Object orientation, however, is
only  adventitious  verbal  flavoring  in  them.  Calling non-row-oriented and
extended-relational DBMSs object-oriented is sheer dilettantism.



3.4 THE CRITIQUE OF OBJECT-ORIENTED METHODOLOGY


What  I  refer  to  as software methodology is  a discipline that combines the
following activities:

1.  the study of conceptual models of software engineering

2.  the study of human procedures surrounding software engineering

3.  the study of CASE tools

The  position  put  forward  by  advocates  of object-oriented  methodology is
paraphrased  below.  Please  note the quotes of oblique speech surrounding the
paraphrase.

1.  'There   is   a   double  link  between  object-oriented  programming  and
    object-oriented methodology.

    a.  Classes  are  autonomous  units  of  synthesis  and analysis and  thus
        reinforce the autonomy of components and teams, on one hand.

    b.  Class   hierarchies  promote  incremental   development,  reuse,  fast
        prototyping and iterative development, on the other.

2.  The  double  link  between object-oriented programming and object-oriented
    methodology  creates  the  need  for  new  lines  of  methodology research
    and  a  methodological  reorientation  of  development  projects.   Object
    orientation is a critical factor in software engineering methodology.'

I  do  not  agree  with  this  position.  Object orientation  is a programming
style. Programming style and software engineering methodology are two distinct
domains  of  analysis.  The  domain  of  programming is the domain of language
issues,  such  as  the issue of data semantics or the issue of restrictiveness
vs. laxity. The domain of software engineering methodology, on the other hand,
deals with more sweeping economic, organizational and cognitive issues such as
prototyping,   iterative   and   stepwise   development  strategies,  language
independence  and  platform-independence  of  architecture products, levels of


                                                                           22
------------------------------------------------------------------------------

stepwise  refinement,  bond  between  code  and  logic narratives, milestones,
internal  and  external  orientation  of  testing,  feedback  between test and
development, CASE tools, code reuse, etc.

Of  course,  no  two  domains  of  analysis  can   be  considered   completely
isolated.  Nevertheless, the adoption of class and class hierarchy as units of
design  bears only limited relevance to methodology issues. Object orientation
colors  methodology  but  does not significantly affect it. Object orientation
gives  rise  to  new entities and relationships in CASE databases but does not
place CASE databases on new theoretical foundations. The pseudo-product of the
industry  of object-oriented methodology, consulting and education is old wine
in  new  bottle.  The  many  internal  tradeoffs and circularities of software
engineering have been in the focus of methodology studies for decades.



3.5 THE CRITIQUE OF OBJECT-ORIENTED LARGE-SCALE INTEROPERABILITY


Large-scale  interoperability  is  not  a  set  of precise requirements  but a
collection  of  emerging  principles.  Large-scale interoperability will cross
barriers  of  applications,  operating  systems,  network  standards, database
standards,  document  formats  and the like. And it is thanks to a programming
style  that this colossal architectural coup will be pulled off! Polymorphism,
invocation  by  message,  SWITCH-less  programming,  multiple inheritance, and
operator  overloading  are  the  ultimate weapons of the coming great software
revolution!



3.6 SUMMARY AND CONCLUSIONS


General   object   technology  is  pure  fiction   on  a   par  with  Marxism,
structuralism,  scientology  and  enneatypology.  Object  orientation,  once a
proposed semantic and stylistic standard for programming languages, has become
a  shibboleth bandied about with wild abandon in a number of areas of software
engineering.  General  object  technology  is  a  phenomenon  of marketing and
journalism. The evangelists of general object technology are parasites basking
in the prestige of object-oriented programming languages. The various segments
of  the  general  object  technology  market  sport object-oriented jargon and
profess  faithfulness to the object-oriented ideal but do not share, with each
other  or  with object-oriented programming, anything object-oriented beyond a
thin verbal veneer. A mysterious new particle, the objectron, is ballyhooed as
the fundamental building block of the software universe: its behavior displays
the  mind-numbing  counter-intuitiveness,  but  not  the explanatory power and
intrinsic  elegance, of quantum mechanics. General object technology is touted
as  the grand unification theory of software engineering but it is really just
a  world-class  hoax,  a  collage of technical hallucinations, an aggressively
imprecise ideology.









                                                                           23
------------------------------------------------------------------------------

4.0 THE MYTHS OF OBJECT ORIENTATION



The   literature   on   object  orientation  is   rife   with   false  claims,
half-truths,  non-sequiturs,  fallacies, non-concepts and hype. The culture of
object  orientation  feeds  on  myths.  The transition between misjudgment and
irresponsible statement in the area of object orientation is continuous. There
are  high-brow  and  low-brow texts on object orientation but even some of the
most reputable texts contain hair-raising claims. I divide the myths of object
orientation into four groups:

1.  technical myths

2.  journalistic myths

3.  mercantile myths

4.  junk myths




4.1 TECHNICAL MYTHS


1.  Myth:  Data  encapsulation  and  entity classification can be accomplished
    only by means of specialized object-oriented languages.

    Roll-your-own  object  orientation   has  a  better  chance   to   succeed
    than   codified    object-orientation  because   it  does  not   introduce
    self-serving  parasitic   features,   bizarre   limitations,  unmanageable
    over-generalizations  and   wanton   complexity.   In   fact,  specialized
    object-oriented  languages  do  not  accomplish  their  own  stated  goals
    because  client-based  data encapsulation is not  data  encapsulation  and
    simple  entity  classification  is  not  entity classification.

2.  Myth: Classes are possessed of autonomy. Autonomy imparts hegemony.

    It  is  true  that  encapsulated  data  structures  have greater  autonomy
    than unencapsulated  ones.  This  fact,  however,  does  not  constitute a
    license    to   treat     algorithms,     parameter     lists,     calling
    hierarchies,   inter-object   relationships  and   global   variables   as
    trivial, uninteresting, un-chic and politically incorrect.

3.  Myth:  Class  is  the  only  necessary  granule of analysis and synthesis.
    Entire  systems  can  be decomposed into classes. A stronger form  of this
    claim  is  that  entire  systems  can  be  built  step  by  step  from the
    LEGO set of off-the-shelf classes and class libraries.

    Reality  does not  feel  compelled  to  comply  with  language  designers'
    dogmas.  Data-intensive  and  algorithm-intensive  areas  alternate across
    the variable landscape  of  a  program.  Unattached  instruction sequences
    are as common  as routines  bound  by  class loyalty. Procedural additives
    and glue account for a large part of most programs' composition.

4.  Myth:   Object-oriented   programming   and   structured  programming  are


                                                                           24
------------------------------------------------------------------------------

    antithetical.   Object-oriented   programming    is    right,   structured
    programming is wrong.

    Structured   programming    emphasizes   the   importance   of   carefully
    designed   procedure   boundaries  and  calling  hierarchies  but  largely
    ignores  data encapsulation.  Object-oriented  programming does not negate
    the  importance of carefully  designed  procedure  boundaries  and calling
    hierarchies  but places  primary  emphasis  on  data  encapsulation.  Thus
    object-oriented   programming   and   structured   programming   are   not
    antithetical  but complementary. Neither is completely right or completely
    wrong.

5.  Myth: Method override and function overloading are related.

    Function  overloading  is  intentional  homonymy  resolved  on  the  basis
    of disparity of signatures;  method override is intentional homonymy  made
    possible  by  identity  of  signatures.  Function  overloading  can  cross
    classes  and  class  hierarchies  or  may  not  involve  any class at all;
    method override exists only within a class hierarchy.

6.  Myth:  Object-oriented  programming  is  the  key to document-centered, as
    opposed to application-centered, computing.

    Document-centered    computing    involves    a    specific    style    of
    application architecture  and  a  combination  of  two  advanced operating
    system  capabilities,  viz.  advanced  desktop   management  and  advanced
    application interoperability.  The language in which these  mechanisms are
    implemented is irrelevant.

7.  Myth:  Well  designed  methods  accept only parameters germane to the data
    structure they encapsulate.

    This  is  a  sadly  myopic  view. Methods  encapsulate data structures and
    call  other  methods.  The  calling  relationship  is as  important as the
    encapsulation  relationship.   Methods   must   accept   not  only   those
    parameters  that  are  germane to  their  own  data  structures  but  also
    those parameters that are germane to  data  structures  of  other  methods
    at  lower rungs of the calling hierarchy.  Besides, germaneness is in  the
    eyes of the beholder.

8.  Myth: Windows are objects.

    Windows  are  not  objects  but  multi-entry  procedures.   There   is  no
    data  structure   in  evidence  in   window  class   definitions   of  the
    Windows or OS/2 operating  systems.  One could argue that certain families
    of  windows, such as control   widgets,  are  hierarchically  classifiable
    and  can  therefore  be  considered  object-like  in  a  broad  figurative
    sense. This argument, although reasonable on the surface,  does  not  hold
    water even if we allow the  definition  of 'object'  to be  stretched. The
    vast  majority of windows, including documents and   dialog   boxes,   are
    client  windows,  and  are   subject  neither  to  classification  nor  to
    instantiation. If windows were objects, then the role of method would have
    to be  assigned  to the message-fielding procedures. Given  the fact  that
    the number of window  messages in major windowing  systems  is  upward  of
    500,  one can rightfully expect to find a monumental window classification
    scheme  and  a  monumental  method inheritance/override scheme. Nothing of
    the sort is observed. Windows are windows.


                                                                           25
------------------------------------------------------------------------------

9.  Myth:   Referential   network   definition   is   subsumed   under  entity
    classification. Entity classification is  the dominant subject of semantic
    data modelling.

    Please  refer  to  Section "2.2.1  A  lopsided  approach to semantic  data
    modelling" on page 3.

10. Myth: Simple classification has sufficient expressive power to capture the
    complexity  of  business   and  software.   Multiple   classification   is
    unnecessary or can be faked out through simple classification.

    Please refer to Section "2.2.2 Failure to support multiple classification"
    on page 4.

11. Myth: Multiple derivation is definable, implementable and usable.

    Please refer to Section "2.2.3 Delusion by the phantom concept of multiple
    derivation" on page 5.

12. Myth:  Procedural  monogamy,  i.e.  the  limitation  of  a method's access
    privilege to a single class, is natural.

    Please  refer   to   Section   "2.3.1   Distortion   of  the  class/method
    relationship" on page 8.

13. Myth: Abstinence from class-dependent SWITCH statements is natural.

    Please refer to Section "2.3.2 Dogmatic ban against class-dependent SWITCH
    statements" on page 10.

14. Myth: Indecent exposure of server's innards to client is natural.

    Please refer to  Sections "2.3.3 Conflict between data  encapsulation  and
    virtual derivation" on page 13 and "2.3.5 Naive optimism about incremental
    development" on page 14.

15. Myth:  The  construction  of extensible sealed libraries is the great hope
    and  ultimate  weapon  of  software  engineering.  The  extensible  sealed
    library is the foundation of code reuse.

    Please refer to Section "2.4 Flaws of  the  library construction model" on
    page 15.




4.2 JOURNALISTIC MYTHS


1.  Myth:  Object-oriented  programming is a revolutionary philosophy, a major
    paradigm  shift,  'the next thing', a higher plateau in language standards
    and development  methodology.  We  are  present at the creation  of  a new
    era  in  the  history  of  software.  'A  specter   haunts   the  software
    laboratories of the world, the specter of object orientation...'

    To  establish  its  originality,  the  ideology of object orientation uses
    a   blend   of   two   tactics:  hijacking  of  time-honored   ideas   and


                                                                           26
------------------------------------------------------------------------------

    exaltation  of   worthless   newfangled  ones.   Object   orientation  has
    claimed credit for such concepts  and  techniques  as  data encapsulation,
    stepwise    design    refinement,   isolation    of     interfaces    from
    implementation    details,    classification    hierarchies,   incremental
    development,  safe storage management  and  systematic  implementation  of
    finite  state  machinery.  Once  all  such false claims of originality are
    discounted, we are left with a hodge-podge of naively  dogmatic and flawed
    programming standards.

2.  Myth:   Object-oriented   programming   has  to  be  'gotten'.  Successful
    object-oriented  projects  employ  anointed  experts  of object technology
    and   create   an   environment   of   carefully   paced   object-oriented
    acculturation.

    This  claim  is  as insidious  as its language  is  indirect. Advocates of
    this claim  imply  that  the stuff objects  are made of is  not present in
    other   forms   of   software  engineering.   The   shroud  of   mysticism
    protects  the claim to uniqueness.  Software  engineering  has always been
    a  taxing  cognitive  process  and  has  always  been  confronted  by  the
    inherent  tensions and recalcitrance  of nature.  The  many  entities  and
    relationships  of  the  software  engineering  process  have  been  in the
    focus  of  intensive  studies for decades. Objects and  the  relationships
    surrounding them  underscore the  importance of  CASE  systems but  do not
    constitute a caesura in the epic progression of software.

3.  Myth: Encapsulation, inheritance and polymorphism are the three pillars of
    object-oriented programming.

    Object-oriented   programming  has  three  pillars:   data  encapsulation,
    entity classification  and  extensibility of sealed libraries. Inheritance
    is just one of  the chief patterns of method specification and is  not, in
    itself,  a pillar of  object  orientation.  Polymorphism used to  enjoy  a
    certain   popularity   in   the  early   object-oriented  literature   and
    continues to be  a great hit with  trade journals  but it has fallen  into
    well-deserved  oblivion in reputable  technical  texts. Polymorphism is  a
    useless  ambiguous  term:  it means  both  method  override  and  function
    overloading.

4.  Myth: Object-oriented programming can be exemplified by taxonomy.

    Taxonomy    is    the    most    commonly   used   example  in   texts  on
    entity  classification.  It is  also  the most pedagogically damaging. The
    complexity of the  animate world is beyond the reach of object orientation
    as well as of all semantic data models currently known to mankind.

5.  Myth: Classes are software integrated circuits.

    Translating  this  famous  dictum  from  the   register  of  post-prandial
    keynote  speeches  to a less solemn and more digestible idiom,  we  obtain
    the claim that classes  are  highly  reusable  autonomous  pieces of code.
    There are only two things  wrong with  this claim: it is not true that all
    classes are  intended to be  highly  reusable and  it is not true that all
    highly reusable pieces of code are necessarily classes.






                                                                           27
------------------------------------------------------------------------------

4.3 MERCANTILE MYTHS


1.  Myth:  Object-oriented  programming  fosters  quality,  productivity, fast
    prototyping, iterative development and reduced maintenance.

    Sound   data  encapsulation  and   sound  entity  classification   have  a
    positive   effect    on    software    engineering    projects.   However,
    full-blown  object  orientation  foists  a  flawed  semantic  model and  a
    flawed programming  model  on  the  developer.  The  software  industry is
    already beset  by  a severe  crisis and can ill  afford the self-inflicted
    plague of object-oriented dogmas and traps.

2.  Myth:  Everything  sold  as  part  of  an object-oriented bill of goods is
    object-oriented.

    Object-oriented  and  non-object-oriented  products  are  often engaged in
    a    relationship     of     interlocked     packaging      and     mutual
    reinforcement.  An  object-oriented  compiler  may  be  packaged  with   a
    non-object-oriented  library.  A  glamorous  object-oriented   product  of
    limited   functionality  and  a  useful  but  prosaic  non-object-oriented
    companion  product  will  augment  each  other's marketability.

3.  Myth:  Every  advanced construct offered by an object-oriented language is
    object-oriented.

    All    that    glitters    is    not    necessarily   object-oriented.   A
    useful  non-object-oriented  feature  diverts  attention  from  the  flaws
    of   object  orientation  and  is,  at  the  same  time,   illuminated  by
    the reflection of object-oriented glamor.

4.  Myth: The limitations of the relational data model license object-oriented
    database management.

    The  relational   data  model   may   very  well  have   limitations,  but
    nothing   licenses   a   non-concept.   There   is  no   such   thing   as
    object-oriented database  management.  Please  refer  to Section "3.3  The
    critique of object-oriented database management" on page 20.

5.  Myth: General object technology exists.

    General  object  technology  is  a  verbal  mirage.  No specific mechanism
    is   shared   by   object-oriented   desktop  management,  object-oriented
    database management,   object-oriented   methodology  and  object-oriented
    large-scale interoperability.  Please  refer  for  a  detailed  discussion
    to Section "3.0 The critique of general object technology" on page 19.




4.4 JUNK MYTHS


The  claims  in  this  category  were  culled from the lowest  reaches of  the
bargain   basement   of   object   orientation.  They  are  outrageous  beyond
refutability.



                                                                           28
------------------------------------------------------------------------------

1.  Myth:   Object-oriented   programming   is   non-procedural;  conventional
    programming  is  procedural.  Algorithmic  thinking  is  less important in
    the object-oriented  programming  environment  than  in  the  conventional
    programming environment.

2.  Myth:   Object-oriented  programming  operates  on  a  higher  level  than
    conventional  programming.  Objects  satisfy  problem  domains; algorithms
    satisfy solution domains.

3.  Myth: Conventional inter-program communication is based on parameter lists
    and  calling  hierarchies;  object-oriented inter-program communication is
    based on a novel mechanism called messaging.

4.  Myth: Objects in object-oriented programming are real-world entities, such
    as documents, physical variables or windows.

5.  Myth:  Objects are possessed of a unique kind of anthropomorphic behavior:
    they  respond  to  messages, they know themselves,  they paint themselves,
    etc.  Anthropomorphic  behavior  is   a   characteristic   not   found  in
    algorithms.

6.  Myth:  Nouns  can  be  equated  to  objects,  verbs  suggest  methods  and
    adjectives serve as the litmus of inheritance.

7.  Myth:   The   fact   that   a  particular  program  is  implemented  along
    object-oriented   lines   shines   through   the   end   user   interface.
    Object-oriented  implementations  are  friendlier,  more  intuitive,  less
    technical from the end user's viewpoint.

8.  Myth:   The   fact   that   a  particular  program  is  implemented  along
    object-oriented     lines      shines     through     the     installation
    interface.  Object-oriented   implementations    enable   end   users   to
    assemble  snap-on components into custom applications.

9.  Myth:  Objects  float  around  blissfully oblivious to their interactions,
    which  are  magically  sorted out by the  compiler. Object-oriented design
    does not  have  to  follow  rigid  and  antiquated principles  of top-down
    refinement.  Objects  enjoy  absolute  autonomy  and  are  filled  with  a
    free-wheeling  spirit.  Objects  are engaged in  an invocation protocol of
    uninhibited  random chit-chat.  Object-oriented programs are grown through
    carefree tinkering.


















                                                                           29
------------------------------------------------------------------------------

5.0 THE ANTHROPOLOGY OF OBJECT ORIENTATION



Ultimately, object orientation is a human phenomenon.

I  believe that software engineering  will stand or  fall  with the success of
code  reuse  and  that  radically new technologies will have to be espoused in
order  to  accomplish a significant increase in productivity and quality. I do
not  believe,  however,  that  object-oriented  languages  and  general object
technology  will  solve  today's  software engineering crisis. Object-oriented
programming  languages  do not have sufficient expressive power to capture the
complexity  of the world. General object technology is a verbal mirage. Object
orientation  is  a  paradigm in the worst sense of the word. I claim that both
the object-oriented programming style and the general object-oriented ideology
surrounding it are utterly devoid of intellectual and practical merit.

But  how  was the consensus  cemented regarding a naively dogmatic and  flawed
toy language and an inane pseudo-technological paradigm? How did the grotesque
travesty  called object orientation leap into existence? Can tens of thousands
of computer scientists and software practitioners, imbued with object-oriented
zeal and fervently carrying the torch of virtuous virtuality, all be wrong? My
answer is that they can. To solve the conundrum of object orientation, we have
to turn to the human sciences.

The  human  mind  gets  around  in  the  physical  and  animate environment by
manufacturing,  refining  and testing concepts without a moment's interruption
from the moment of birth until the moment of death. The mind's map of physical
and  animate  reality  is  a  network  of  concepts  in  a  state of permanent
kaleidoscopic  self-reorganization.  The  process  of concept production has a
high failure rate. Most of our concepts are parasitic, hollow, dead-ended. Two
factors  hamper the success of concept formation: belief systems and language.
Societal pressures and verbal biases cloud our thinking and interfere with our
subconscious  effort  of  conceptual adaptation to reality. Societal pressures
and verbal biases also underlie the story of object orientation.

It  can  be  said  without exaggeration that object orientation has become  an
aggressive  religious  ideology,  a  form  of collective messianic delusion, a
tidal    wave    of   mobilization   and   brainwash.   Object   orientation's
anti-intellectual  stranglehold  on  the  software  engineering  community has
created  an  atmosphere  in which programmers in some organizations spend more
time  verifying  their  programs'  political  correctness than their programs'
correctness. To explain the genesis of the object orientation movement I offer
a  conspiracy  theory.  Of  course,  conspiracy  is  to  be taken in the broad
systems-theoretical  sense.  The  object-oriented  programming paradigm simply
arose  as  a product of market forces. The demand for a new class of languages
came

1.  from idealistic software engineers yearning for better data encapsulation,
    better semantic data modelling and better code reuse,

2.  from  middle management concerned about executives' growing intolerance to
    low productivity and low customer satisfaction and

3.  from  a segment of the education and consulting industry constantly on the
    prowl for novelty and hype.



                                                                           30
------------------------------------------------------------------------------

The  supply  of  a new  class  of languages came from compiler developers who,
having  completed  the  job  of  C  standardization,  perfected  the  art of C
optimization and saturated the market of C compilers, became available for new
ventures.  The  market was in heat for a new class of languages and the market
was successfully penetrated with a powerful thrust. Interlocking market forces
created  a  solid  consensus.  This  is  a matter of psychology, sociology and
economics,  not  of  computer  science.  General  object  technology, i.e. the
collage  of  such  pseudo-technologies  as object-oriented desktop management,
object-oriented   database   management,   object-oriented   methodology   and
object-oriented  large-scale interoperability, rode into respectability on the
coattails of object-oriented programming languages.

The  primitive  mind  is  susceptible to word magic: naming instantly  imparts
unquestionable existence. Words can be nutrients that augment concept cells or
viruses that destroy them. Words can illuminate or obfuscate. But the greatest
danger  is  that  words  can  also masquerade as concepts and create a virtual
reality.  Messianic  ideologies,  such  as object orientation, are made out of
whole  verbal  cloth.  Objecto-babble  is  the junk food of software engineers
starved  for new ideas in an era of overwhelming change and uncertainties. The
mystagogues  of  object orientation lead their lemmings to an aquatic death in
the   murky   fjords   of   conceptual   deprivation.   The   sub-industry  of
object-oriented  publishing  produces a barrage of mumbo-jumbo and double-talk
without  parallel in any serious technical field and matched only by cosmetics
advertising.  Object-oriented  ideology  pollutes  computer  science  as  only
infomercials   degrade   television  programming.  Object-oriented  jargon  is
inflationary  paper currency unbacked by the golden reserve of sound concepts.
Bankruptcy of object orientation is impending.

In  their  quest after ultimate explanations,  philosophers  steer a dangerous
course  between  the  Scylla  and Charybdis of agnostic gloom and constructive
optimism.  American  philosophy  has  always  shown a penchant for the latter.
Positivism,  behaviorism,  physicalism,  reductionism,  generative  linguistic
theory and the strong theory of artificial intelligence are so many variations
on  the  theme  of  constructive  optimism. Humans, both as individuals and as
members  of society, thirst for easy answers, and philosophers are only human.
The smugness of object orientation is an extreme form of the smugness found in
many  20th  century  philosophical theories. The philosophical underpinning of
object-oriented  programming  is  reductionism.  The  world  according  to the
theorist  of  object  orientation  is  a single evergreen classification tree,
bountifully  bearing  predictable  fruits  on every branch and immune from the
arthropods  of  chaos and complexity. If Moliere's Would-be Gentleman had been
tutored  in C++, he would have been delighted to learn that he had unwittingly
joined the ranks of reductionists.
















                                                                           31
------------------------------------------------------------------------------

END OF THE DIATRIBE


























































                                                                           32
------------------------------------------------------------------------------





























































------------------------------------------------------------------------------
