I believe, however, that there is a deep reason why the approach is ``right'' that doesn't show up in the paper.
Folks all seem to remember the ``information hiding'' part of Dave Parnas's work and acknowledge that a lot of our notions of modularization/encapsulation come from him. They don't seem to remember - or maybe just don't understand the implications - of a second, equally important part of what Dave said, namely that the *order of decisions* in a design was critical.
What gave rise to all this was Dave's concern about maintenance of programs; information hiding was a tool to insulate the effect of changes. A proper order of decisions was also motivated by maintenance. He noted that making a decision has two effects - it limits the range of options for subsequent decisions, and it presumes prior decisions, locks them in, and thus makes them harder to change. In particular, he observed two things from this:
The deep problem with black box abstractions is that they bind implementation decision with knowledge of either zero or one uses of the abstraction. Thus, although the implementation decision may be right for some uses, its guaranteed to be wrong for others. It's the height of technical arrogance for a designer to think they know the right way to implement an abstraction for all future uses of it.
Maybe this wouldn't be so bad if it were ``only a matter of performance'' - but it isn't. It leads to poorly structured, far less maintainable code. The trivial example that Mary Shaw and I gave in [SW80] is the decision that all languages and/or compilers make to store arrays in either row-major or column-major order - a decision that is made with zero knowledge of the application, but forces programmers to either contort algorithms or to store the transpose of a matrix in order to get acceptable performance ('acceptable' here means two orders of magnitude difference on programs that runs for hours when optimized). I can't begin to count the number of bugs that I have found in scientific codes because of this one, completely unnecessary, premature binding!
Back to Alphabetical List of Responses
(Last Revised October 1994)