From: Lawrence Dickson (tjoccam_at_email.domain.hidden)
Date: 1998-08-23 05:46:00
Dyke, Oyvind, and all,
Could the following paradigm fit Les Hatton's complexity data and
your (and my) experience: Knowledge-interdependent subdivision of a
program into small components results in defective programming and,
ultimately, knowledge failure (the program becomes too complex for
anyone to understand). Dyke Stiles said:
>A four-year comparison on a large project (at Hatton's firm - Oakwood
>Computing in Surrey) showed about 25% more faults/KLOC in the C++ OO
>version against C, and the time to fix the faults was about three
>times as great in C++. Components involved in inheritance were about
>six times more likely to have defects than those which were not -
>even though only single inheritance was used (this on a different
>project from another group). Objects using polymorphism seem to be
>more difficult to handle.
>
>Other points: Hatton quotes a study by Leach showing that few users
>felt they achieved more than 20% reusability - although Hatton's
>project reached about 40%. (He also notes that 20 years ago he
>had > 90% reusability in FORTRAN programs...not a surprise to some of
>us old FORTRAN programmers...)
Certainly OO creates knowledge entanglement between components, and
that is at its worst with inheritance and polymorphism. In vanilla C
the components are more independent (they tend to come in "families"
which you can use without knowledge of other "families"), although
the great numbers of INCLUDE .h files amount to global knowledge
variables. In ancient Fortran (as I remember it) there weren't
special types and structures and the related INCLUDEs, just the
(universal) system calls in a flat static memory model. This leads
to practical knowledge-independent components with the 90%
reusability that I remember too.
If you enforce knowledge independence (which is stricter than no side
effects) then Hatton's complexity overflow cannot occur. Consider the
automobile. The alternator and the windshield wiper each have a
definite function (each can work without the rest of the automobile)
which, practically, is all they do. So they can be included in the
car design with confidence. Where would we be if they (and all other
car parts) had to be treated as nodes on some knowledge descent tree
that enforced a massive skein of interrelations between their
functions?
I think that conventional code has already hit a wall due to this
effect. There has been very little qualitative progress in 10 years
except in areas related to HTML and the World Wide Web, both of which
have the flat "knowledge independent" structure. Another example is
SNMP, "Simple Network Management Protocol," a basic tree search
database which was supposed to be a temporary stopgap while the real
object oriented network management protocol was developed. It's been
ten years, SNMP has spread everywhere, and they haven't been able
even to define the OO protocol.
The occam style can lead to knowledge independence as well as
functional independence (if you control those darn INCLUDE files).
Oyvind Teig writes of Hatton that
>his big deal is that
>it is not the inherent safety in the basic language that
>counts, but how good it can be made.
>
>This is I think, an "excuse" for writing in C, and he makes
>his points very clear in the book.
But I admit to that too; it's an "excuse" for writing in Fortran,
Java, assembly or whatever as paid employment demands. I've had to
learn very quickly how to force them into knowledge black boxes to
maintain heterogeneous system flexibility: Java for pretty client
front end only, C for server peripheral control, assembly for
handmade peripherals themselves, C++ for nothing. Of course it's
all really coarse occam in disguise (using pipes, fifos, TCP/IP etc).
But I don't think I could ever do this stuff with confidence if I did
not have a foundation as an occam programmer. That surely means it
belongs in the schools. Can we make this point to Hatton and others?
He seems open minded from what you say.
Larry Dickson
This archive was generated by hypermail 2.1.7 on 2004-10-31 20:03:56 GMT
© Copyright WoTUG
All rights reserved