Feedback to "What Have The Romans Ever Done for Us?"-
Murphy's Law, September 2001
Read the original artilce at What
have the Romans Ever Done for Us?
return to Murphy's Law
I think that your article on OO and reliability is at best misleading;
your examples on code re-use affecting reliability actually make
the case for the benefits of OO. Had the Arianne 5 system used
OO programming the code for the Arianne 4 would not have been
executed. One of the biggest benefits of OO analysis, design and
programming is encapsulation which in turn hides complexity. A
simpler system is easier to change (and systems always have to
change) and this improves long-term reliability. Also, your example
of a system which is easier to test because all variables are
global sounds like a disaster waiting to happen. The potential
for catastrophe caused by a rogue piece of code is huge. At least
in languages that allow data encapsulation the programmer would
have to go out of his way to trash everything. I think your view
of OO is kewed by the drawbacks of C++ which just happens to be
the most (overly) complex OO languages around. Java and Smalltalk
give a much better OO experience, although I understand that their
use in embedded systems where performance is always an issue is
probably not nearly as widespread as C++. It's not OO that makes
things complex, just C++.
While I completely agree with you that Java resolves many
of the problems with C++, I would be less convinced in the case
of Smalltalk. In Smalltalk the message passing style allows for
too many run-time problems that should have been detected statically.
Having reexamined my article, it is true that the points about
templates and multiple inheritance do not apply to Java (though
they do apply to other OO languages). However templates are likely
to appear in Java soon - it seems to me that language designers
just do not know when to call a halt.
I would also concede that the point about Exceptions making
memory management a nightmare does not apply to Java - but the
rest of the piece applies to all OO languages. I used C++ as an
example because it is the most widely used.
As for the Ariane, I would not accept the assertion that an
OO style would have avoided the problem. It is far too fanciful
to assume that if the troublesome code would have been inside
of an object that would have been tidily removed from the Ariane
code. The fundamental problem was that the designers were not
considering, and could not have considered, the needs of Ariane
5, and this problem plays itself out in many projects. Ariane
did use Ada, a language touted for its safety features, and also
used formal methods for code verification, but still ultimately
got caught out by reuse. The reuse may have been an inescapable
business decision, but it was still a major contributing factor
to the loss of the rocket.
To: Niall Murphy
Since you said many things I like to hear, you must know your
stuff. The more direct reason for the Ariane 5 crash was a conversion
from floating point (FP) to integer that overlowed and raised
exception, which shut down the computer and cut in a backup that
did exactly the same thing. Ariane program used Ada. Both FP and
exception are restricted items in Ada-95 Annex H for Safety and
Security. A processor I designed over 25 years ago for digital
autopilot used saturation, i.e., max/min integer wheh overflow
instead of let a positive number roll over to a negative one.
There is nobody in the missile to take care of overflow exception.
The unwarranted complexities of C++ can also be said of Ada,
which I tried to apply to a missile in early 80s. I was also teaching
some Ada class and touted Ada Tasking as an advance but were chargrined
to find out that definitely Tasking was undesirable and unnecessary
for this active radar missile. I use the Annex H restricted Ada
to describe the design of a core processor based in the earlier
autopilot processor chip architecture. With Ada package, I can
define and encapsulate various logic cells from single transistors
to and/or type basic functions to adder/counter type more complicated
cells to the entire processor. They are most certainly objects.
Two good friends jumped on me when I called the subset object
oriented because I got rid of the inheritance part that were added
in Ada-95 along with FP, exception, tasking, etc, etc. One said
may be it is OK to call it object based. Computer science has
changed the dictionary meaning of object.
The reuse of building block logic cells is an established market
for hardware design. For example, you have to pay a hefty price
for PCI interface from FPGA vendors. Any hardware type that will
reuse a cell design without thoroughly examine its inards or test
its logic correctness deserved to be summarily executed.
The use of Ada package to encapsulate a building block cell has
advantages over the use of IEEE HDLs of Verilog/VHDL that stops
at RTL. The package body can initially be described with Boolean
expressions and tested by writing a program for the purpose. After
shown to be correct, the body can be replaced by a number of interconnected
building block cells. The same test program need only be relinked
and retested. Any difference in result puts the error on the improper
use of building block cells. The cells were previously tested
by themselves. This is different from current EDA practice that
depends on "synthesis" tools that generates the connected cells
from RTL. It is certainly cheaper to use an Ada compiler than
buying EDA tools that costs in the six figures.
You mentioned the first fly-by-wire autopilot. Besides a whole
bunch of coordinate transformations of the rate gyros, there is
also the need to filter the inertial measurement information for
mechanical noise during flight. That brings back the subject of
integer number representation which generally considered to be
2's complement. Most HOL allow the extra negative number (integer'min).
A-B may or may not overflow if A is negative and B=integer'min,
depending on the order of evaluation.
You are so right with "objects can do a lot for use, but be careful
not to buy into any more language complexity than you need" because
I have been practicing this for nearly 8 years. Alas, I cannot
convince SIGAda to form a working group to draft a proposal for
ISO for a safety subset of Ada that can also be used to design
hardware. CS types are still living in the mainframe & dumb terminal
era. C++ class is similar to Ada package but C++ suffers from
poor readability inherited from the heavy use of symbols from
Finally, you mentioned lines of code, a commonly used term. What
do you call a single curly bracket in C code, a line? or the entire
Too bad I cannot interest Michael Barr. He considered hardware
design is out of scope with ESP. He may not realize that today's
hardware design is really also generating software using HDL.
SY Wong, Tarzana CA
I agree with you the lines betwen hardware and software are
blurring and soon many hardware designers will require skills
that are currently in the software domain (like managing a modular,
maintainable design made up of tens of thousands of lines of logic,
rather than a diagram).
As far as lines of code goes, it does not matter whether curly
braces are included or not as long as you are consistent. Metrics
like LOC mean nothing as absolute numbers but are only meaningful
for comparison, So if one projet has twice as many LOC as another,
then that is a useful measure - as long as both were measures
the same way. The way I measure it myself is to count semi-colons
- fairly easy to do with the grep command, and if ignores comments,
blank lines etc.
Every once in a while, it helps to go back and review the assumptions
that lead to our shared conclusions. You did a fine job of reminding
your readers why object oriented programming is a good choice.
Its benefit, however, is not necessarily universal.
For the past couple of decades, I have been involved in programming
microcontrollers for computer peripherals. Most of my work employs
8-bit micros. I have found assembly language to be my tool of
choice until recently. It seems the producers of C compilers for
8-bitters have finally improved their languages to the point of
acceptability. OOP language support is not there yet, and my colleagues
and I won't waste time awaiting it.
A few comments about your article.
About the Ariane 5 rocket failure, you wrote, "the root cause
was the failure of an assertion..." It makes me wonder why an
assertion was still active in the code.
You wrote, "...reuse...is often not re-tested when it is reused
in an environment with different requirements." First, it's tough
to imagine that any two environments are going to have requirements
that are NOT different. Second, the cost of retesting begins to
compare very favorably with developing anew. Barry Boehm's research
group at USC rates modifying just 5% of a code module as costing
55% of the effort of a total rewrite. The big factor is understanding
how it works. Once you look under the hood, you have to account
for how the whole engine works. This, I think, is the big demotivator
for retesting. People, particularly project managers, feel comfortable
living with the lie that code "working" is a yes/no fact. Actually,
there is a continuum of "working" that runs from poorly to perfectly.
"Encapsulating code and data means hiding it from the rest of
the program." You really don't need OOP to encapsulate. It's just
that the language provides constructs that facilitate encapsulation.
You did a fine job of marshalling some anecdotal rebuttals for
some anecdotal advantages attributed to OOP. You might find it
amusing to browse the article "An Empirical Investigation of an
Object-Oriented Software System" in IEEE Transactions on Software
Engineering, August, 2000, volume 26, number 8, pp. 786-796. This
is the first attempt I have seen to quantify OOP performance.
Unfortunately, the attempt went bust. It turned out that modules
that employed inheritance or polymorphism were about 3 times as
defect-prone as those that didn't. The reason, in my opinion,
is that this was the first OO project undertaken by the programming
staff under study. Though they were all accomplished C programmers,
their expertise did not carry through to new features of C++.
I can tell you that as a competent embedded C programmer, I find
the learning curve for C++ very steep. It seems that texts for
structured analysis and structured design with procedural languages
are very heavy on analysis and very light on design, particularly
implementation. Texts on OOP, though, are just the opposite --
classes seem to just pop out of thin air without rationale. There
is almost no concentration on partitioning a problem into classes.
Well, that's my gripe anyway.
Thanks again for stirring the pot.
Jeff Sharp principal engineer, electronics Elo TouchSystems,
Thanks for your interesting response. You are right about
small changes requiring far more test than they generally receive.
On your point on assertions, you suggest that the assertions
should not have been in the Ariane code. It is worth noting that
while in many projects it is standard practice to take asserts
out for the shipped version of the code, many safety critical
applications leave them in, and have a well defined recovery path
for when an assertion fails (often to reset the system and start
over). In the case of the Ariane, that recovery path was 1) too
complex and 2) not well tested (because they did not have enough
(real or generated) failiures to exercise that code path well).
I discuss assertions in greater detail in one of my earlier
articles - see the list at http://www.panelsoft.com/murphyslaw.
I will also be publishing your mail at that site.
Ron Stickley writes:
Just wanted to say
I read your article in ESP and found it that most unusual of technical
articles...it held my interest. Of course, it helps that I too
am a Monty Python fanatic and am a convert to Object Oriented
Design. Anyway, it's nice to know that there are others who appreciate
fine humor (forgive the Yankee spelling...).
I don't consider myself
an object oriented programmer, because I don't know C++ very well.
My experience has been using Shlaer-Mellor methodology, Project
Technology Bridgepoint design tools, with the code being automatically
generated by the MC2012 Model Compiler. So, I know how to create
objects, relate them, etc. but I don't actually implement them
directly in C++. I have developed some programs using C with structures
and switch/case statement state machines, but not on anything
mission critical. However, the tools we use and object oriented
design have, for us, proven to be the most reliable and bug free
software this company has yet written (in my humble opinion).
I think the points
you bring up are important and I never considered them before.
Especially in the fields of transportation, medical, and military
systems you can't be too careful. I wonder if it's not so much
the programming language but the programmers? I've known people
who were brilliant minds who could write rings around me in C
or assembly as far as getting something out the door fast and
seemingly working, but the code was unmaintainable and, what I
call "brittle", in that if there was any change in the order or
even timing of i/o contacts, bits, the programs would fail, lock
Anyway, I'm not disagreeing
with what you wrote, just some thoughts.
It's been a difficult
road growing up here in the U.S. (especially rural America) where
humor is concerned. Many times the room has fallen silent with
blank stares after I've said something "pythonlike" or plagerized
from MP. Monty Python was and is the best comedy I've ever seen,
and most people I grew up with couldn't fathom it. It's also educational,
in that it is steeped in historical and social content. I am still
mining nuggets of info from the original series and movies and
(thanks to my friends overseas in the mother country) slowly learning
rich terms like "knackered" or what "right out on my uppers" implies.
Just two years ago I was exposed to the BlackAdder series by a
friend and it is hilariously funny as well. I wish I could think
of insults like that.
Marquip LLC Phillips,