NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/object/3218

Text File | 1992-08-15 | 5.4 KB | 111 lines

Newsgroups: comp.object
Path: sparky!uunet!mole-end!mat
From: [e-mail]
Subject: Re: Class methods (was: Re: How to design a data structure library)
Message-ID: <[e-mail]>
Organization: :
References: <[e-mail]> <[e-mail]>
Date: Sat, 15 Aug 1992 09:30:10 GMT
Lines: 100

In article <[e-mail]>, [e-mail] (Steve Mellor) writes:
> ...

(Please, everyone note that everyone has his own meaning for `architecture.'
It is one of the great `Humpty-Dumpty' words of all time, I think, and may
belong in Strunk & White.  I would characterize the Shlaer & Mellor use a
`solution architecture.'  They may disagree.)

Let's cut right to the heart of the matter--and perhaps the heart of
my understanding or misunderstanding:

> The concept is similar to (a) We wrote a program in a language,
> (b) we wrote the compiler for the language (c) we applied the compiler
> to the program. The language, of course, is OOA. (S/M OOA, that is.
> The others are not well enough defined to be able to do this!).  Step
> (a) corresponds to the application analysis. (b) to the architecture
> and the templates, and (c) to populating the templates.
            [I've un-justified the text to squeeze it a bit--mat]

In other words, you are programming (not just designing) above the
level you have at hand.  I see several problems with this.

> The obvious and beautiful economy is that once you have the compiler
> (architecture and templates), it is a low cost matter to recompile
> other programs, or to change the existing program (the analysis).

One minor problem is that your tool for programming above the language
is not a language but a CASE system (at best).  I'm not at all convinced
that these are appropriate, expressive tools for programming.

Another minor problem is that only one level of abstraction, that of
your `application,' is clearly visible.  Other levels are placed in
`domains' that are not in their true client-server DAG, or else
wholly subjugated into the `architecture,' which is, in fact, a
language without the expressive power of a real programming language.
            -------------------------------------
            Library design is language design.
                --Bell Labs Proverb

                and vice versa.
                A. R. Koenig
            -------------------------------------
                    --the chapter heading quotes
                      from Stroustrup II, ch 13

But I see a major engineering problem, too.

Your `architecture' or language embodies the solution abstractions
you need to achieve certain performance goals on a particular platform
(hardware, OS, file system, network, DBMS server, etc.).  For a system
written on Big Iron (or it's equivalent in networked superservers--
Big Ether or Big Driftnet), a system of which there will be relatively
few, like a power grid controller or an Air Traffic Control system,
this may be a good assumption.  The lifetime of the hardware and the
lifetime of the software are pretty much the same.

But when Tailfeather Aerodynamics stretches its AeroMansion-425 into the
AeroPalace-475, they'll want the plane to act the same and the cockpit
to look the same.  Unfortunately, they want to use the new Mk. XXIV
computer, with five times the CPU horsepower, sixteen times the memory,
four times the MTBF, one fourth the power dissipation, and an extra 15
years of supply at commodity prices over the old Mk. XVII.  Unfortunately,
to get the same control laws on the bigger plane with the new electro-
hydraulic actuators, they'll have to rewrite both the flight laws domain
_and_ large portions of the `low-level' (e.g. `architecture') in which
so much time was invested before.

Worse, all the assumptions about relative execution cost that were
built into the architecture (the higher-than-the-language-language) are
invalidated and all of the primitives (`templates') that were tuned to
the old assumptions are wrong.  Instead of multiple levels of abstraction,
each expressing one degree of freedom in the combined problem-solution
space, you have one level of abstraction in which you are really free
to program.

The problem is even worse for Bogus 5-4-3-2-1, the Killer App that
has people buying ever more powerful bizmicros, and Bogosity, Inc,
putting out version after version trying to wring every dram of
compute-juice from every processor on the market, 'cuz none of them
is powerful enough yet to get response times below 2 seconds, much
less 100 msec.  Unfortunately, every version includes the next 15 items
on the wish-list that 85% of the 5 million _registered_ users agree on,
which means that each version needs two-thirds again as much of that
compute-juice ...  They _need_ a good problem-based architecture (my
meaning of the word) that doesn't embody performance assumptions,
because every time they turn around, those assumptions are
defenstrated, as are assumptions about what the high-level abstractions
are.  The stable abstractions are the low ones in this software.

The `transformational' approach may make sense on Big Iron and Big
Driftnet, but I can't see it on systems that will become commodity.

On the other hand (said the ambivalent, ambidextrous prevaricator) I
have to admit that Macro Spitbol did run well on lots of machines.
But RBKD knew where the time would be taken, nowandforeveramen.
--
 (This man's opinions are his own.)
 From mole-end                Mark Terribile

 [e-mail], Somewhere in Matawan, NJ