comments on comments 
Author Message
 comments on comments


Quote:
>     I use a tactic which essentially makes comments as inherent a part
>     of the code as possible: I make all package, procedure, function,
>     type, and variable names as descriptive as reasonably possible.

>     Examples:

>        procedure POSITION_AT_LAST_ITEM (SOME_LINKED_LIST);

I used to do that until I heard that the ANSI C standard will state
that external identifiers should not be equal in the first six
characters. Maybe POSIX says something else. I don't plan to port
my code to anything else than POSIX (and maybe PC-DOS, if I have to).

I also label each identifier with two to four characters that indentifies
a package. For example, the functions in my package for handling double-
linked lists in C has functions like "dlst_create_list" and
"dlst_next_item".
--
Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden
Tel: +46 (0)758-202 50  Fax: +46 (0)758-197 20




Mon, 20 Jul 1992 14:28:00 GMT  
 comments on comments

Quote:


>> The standard argument for top-down design is that design errors are caught
>> early.  A top level change could make all the work done at the bottom level
>> unnecessary and major rewriting or complete scrapping could occur.  That
>> is the advantage of top-down design with bottom-up implementation, the
>> overall design should be close to correct and the implementation is direct
>> and fast because the objects and procedures don't depend on anything not
>> yet implemented.  I think the advantage of "building blocks" should be
>> evident in any design since code which is designed to be easy to modify
>> will consist of reusable and parameterized components which correspond
>> to a loosly coupled and highly cohesive modular design.

>If you end up with "reusable and parameterized components ... loosely
>coupled... modular", then it doesn't matter how you got there.
>My argument is that in most cases, you are more likely to end up
>in such a software ecstacy if you use bottom-up design techniques,
>and you'll get there quicker.

Everyone involved in this discussion should get their hands on a copy
of Bertrand Meyer's book _Object-Oriented Software Construction_, Prentice-
Hall, 1988.  The design philosophy being discussed sounds virtually
identical to Meyer's exposition of the object-oriented design method.

Briefly, Meyer's summary of object-oriented design is as follows:

        Ask not what the system does, ask what it does it to.

In other words, the most important characteristic of the system is NOT
its overall "intended function".  The most important description of the
system is in terms of the objects, the data, that is manipulated by the
system.

This is more akin to bottom-up design than to top-down design, for sure,
although the emphasis is slightly different.

Quote:
>You say, "A top level change could make all the work done at the bottom level
>unnecessary and major rewriting or complete scrapping could occur."

>HATE IT when that happens!

>That is one reason why I design the low-level objects first.  If they are
>designed without knowledge of the specifics of the higher levels, high
>level changes cannot effect them.  The disaster happens when somebody
>"finishes" the high level design and then designs the bottom level around
>that, and then Ooops! -- it turns out that the high level design had a flaw
>in it. Then you discover that the change propogates right down through
>all the levels.

The typical top-down design spec is functionally oriented; i.e. "We want
the system to Do This, and in order to Do It, it'll have to do this, and
this, and this..." etc., etc.  When you change your mind about what you
want it to Do, you're hosed.  Object-oriented style avoids this, by focusing
the design effort on the structure of the data to be handled, rather than
on the design of the whole system.  A proper object-oriented design is
inherently modular, and seldom needs a complete revision; the modules are
organized in a network rather than in a hierarchical tree, which means
changes to the net can be made without affecting the whole system; whereas
if you need to change the root of a top-down tree, you're hosed.

Quote:
>I gave a case history of using the parts of a Pascal compiler in
>a mouse-clicky kind of editor. I'll reply to one comment.
>You said, "It sounds like the bottom-up implementation provided them
>with the working software early."

>I say, The bottom-up design provided them with software that didn't
>"know it was in a compiler".  Recall, I did not even know about that
>project when I started the compiler.

Exactly.  Your objects were general enough to be free from a specific
system.  This is reusability, and Meyer talks about how to get it.  A lot.

Quote:
>I have tried to use the parts of other production compilers
>to do things other than pre-runtime compilation. Not as an academic
>exercise, but to produce real commercial products.  That's why I'm
>writing this one!  I would rather buy the source for one off the self.
>Better yet, what I would really like is what I am writing: a library of
>low and mid level Pascal object Adt's. Then I wouldn't even need the
>source, except to fix bugs and port it to new platforms. But try to
>find such a thing: an open architecture compiler.  So far as I know, I
>am writing the first one.

You should definitely go out and take a look at this book.  One of Eiffel's
(Meyer's language) main selling points is its reusable object library,
with everything from arrays to hash tables to an Xwindows library already
coded.  (According to reports, lexical analysis and (someday) concurrency
libraries will be available too.)  Sounds right up your alley!

Rob Jellinghaus                | "Next time you see a lie being spread or a


{everyone}!decvax!yale!robertj |     -- K. Eric Drexler, _Engines of Creation_



Mon, 20 Jul 1992 19:34:00 GMT  
 comments on comments

Quote:
> Everyone involved in this discussion should get their hands on a copy
> of Bertrand Meyer's book _Object-Oriented Software Construction_, Prentice-
> Hall, 1988.  The design philosophy being discussed sounds virtually
> identical to Meyer's exposition of the object-oriented design method.

    I'd suggest Booch's coverage of object-oriented design in
    "Software Components with Ada" instead; Meyer's book comes
    bound up with a rather flaky programming language.

Quote:
> You should definitely go out and take a look at this book.  One of Eiffel's
> (Meyer's language) main selling points is its reusable object library,
> with everything from arrays to hash tables to an Xwindows library already
> coded.  (According to reports, lexical analysis and (someday) concurrency
> libraries will be available too.)  

    Ada has far more reuseable ADTs already coded.  I'm coding a concurrent
    ADT right now, in fact.  Vendors such as EVB, lib systems, Wizard Software,
    and so on, have entire catalogs of Ada components you can buy right off the
    shelf, and Ada's rigorous standardization ensures that they'll compile
    anywhere.  Booch's other book, "Software Engineering with Ada" is also
    worth reading, and I think it also contains something on object-oriented
    design.  ("Software Components" is more of an advanced text)

    Also, one can obtain a magtape copy of the Ada Software Repository from

        MACA
        Attn: Janet Mckellar
        P.O. Drawer 100 - Bldg T148
        White Sands Missile Rang, NM  88002

    It fills up an entire magtape at 6250 bpi in tar format, and costs
    essentially nothing; all they need is your magtape and enough postage
    to get it back to you.

    The Ada Information Clearinghouse Newsletter periodically summarizes major
    Ada software libraries and systems; it's free, and you can get on the
    mailing list by sending a postcard to

        Ada Information Clearinghouse
        c/o IIT Research Institute
        4600 Forbes Blvd., Second Floor
        Lanham, MD  20706-4312

    Also, the recent issue of ACM SIGADA Ada Letters contains several
    interesting articles on ADT design and object-oriented programming.  


    comp.sw.components Mailing List administrator



Mon, 20 Jul 1992 00:58:00 GMT  
 comments on comments

Quote:
>> Everyone involved in this discussion should get their hands on a copy
>> of Bertrand Meyer's book _Object-Oriented Software Construction_, Prentice-
>> Hall, 1988.  The design philosophy being discussed sounds virtually
>> identical to Meyer's exposition of the object-oriented design method.

>    I'd suggest Booch's coverage of object-oriented design in
>    "Software Components with Ada" instead; Meyer's book comes
>    bound up with a rather flaky programming language.

I don't want to start an Ada vs. Eiffel debate, but the view that
Eiffel is a flaky language is something Bill Wolfe have to stand for
himself.

What I like to stress is: Ada is *not* an object-oriented language.
I used to think that, but there are just to much missing. Particulary
inheritance and dynamic typing. And although this is a trivial fact to
realise, it still seems necessary that from time to time make a reminder
about this. Due to Gary Booch and others it is easy for the casual
reader to get the impression that Ada <=> object-oriented programming.

But it's true that Ada is better for applying object-oriented strategies
than most other "conventional" languages.

As for bottom-up vs. top-down, Meyer explains this very well in his
book, and it's certainly applicable to the recent discussion. One
drawback with top-down I haven't seen well covered, is the big risk
that you never see that two leaves are the same, or see it too late,
so you get the same code in two places. (Or even worse, you should
have two identical pieces of code, but in fact they are different.)
  The project I'm in right now was designed top-down, if it was designed
at all. (It's a real mess, but don't blame me I came in too late.)
And it is a clear mistake. OK, there is a set of library routines
for low-level objects like formatting routines and simple database
accesses. But very little for handling of high-order objects like
account statements and other application specific things. I have
tried to introduce it, but when you need more than a day for it,
you get in conflict with the time schedule, whichh of course give
no place for "luxury" like that.
--
Erland Sommarskog
ENEA Data, Stockholm              This signature is not to be quoted.



Mon, 20 Jul 1992 09:09:00 GMT  
 comments on comments

Quote:



>> Everyone involved in this discussion should get their hands on a copy
>> of Bertrand Meyer's book _Object-Oriented Software Construction_, ...
>>   [discussion of decomposition methods deleted]
>    I'd suggest Booch's coverage of object-oriented design in
>    "Software Components with Ada" instead; ...

IMHO, these ideas were more clearly expressed by people like
Parnas and Liskov back in the 70's.  For instance:

  D. Parnas, "On the criteria to be used in decomposing systems into
      modules," CACM, v15, Dec. 1972.

and more recently:

  B. Liskov and J. Guttag, _Abstraction_and_Specification_in_Program_
      _Development_, MIT Press and McGraw Hill, 1986.

Of course, the phrases "information hiding" and "ADT" don't sound
as high-tech as "object-oriented" :-)  (Comments about polymorphism
and inheritance unnecessary, and flames to /dev/null.).

John Baugh
--



Mon, 20 Jul 1992 15:29:00 GMT  
 comments on comments

Quote:
> I don't want to start an Ada vs. Eiffel debate, but the view that
> Eiffel is a flaky language is something Bill Wolfe have to stand for
> himself.

> What I like to stress is: Ada is *not* an object-oriented language.
> I used to think that, but there are just to much missing. Particulary
> inheritance and dynamic typing. And although this is a trivial fact to
> realise, it still seems necessary that from time to time make a reminder
> about this. Due to Gary Booch and others it is easy for the casual
> reader to get the impression that Ada <=> object-oriented programming.

    I quote from ACM SIGADA Ada Letters, March/April 1989, Volume IX,
    Number 2, Page 10:

      Software Productivity Solutions, Inc., has announced a new product,
      Classic-Ada (tm), which allows Ada software developers to use
      inheritance and dynamic binding in object-oriented Ada designs.
      The product runs on VAX/VMS and Sun/Unix systems.  For more
      information, contact:

         (407) 984-3370       Ms. Lois Valley
                              Vice President, Marketing
                              Software Productivity Solutions, Inc.
                              P.O. Box 361697
                              Melbourne, FL  32936-1697

   I stand by my statement regarding Eiffel's flakiness.  Obviously
   it's just my opinion, and others may differ, but I think it's a
   very well-founded opinion.




Mon, 20 Jul 1992 15:46:00 GMT  
 comments on comments

Quote:
>    I stand by my statement regarding Eiffel's flakiness.

Do you mean that the language design is flakey, or that an
implementation is flakey?  If the former, what is flakey about it?
--

Univ. of Ariz. Dept. of Comp. Sci.      {allegra,cmcl2}!arizona!mike
Tucson, AZ  85721                       (602)621-2858


Mon, 20 Jul 1992 17:07:00 GMT  
 comments on comments

   [Karl Nyberg e-mailed me some information regarding my recent
    article, which I believe to be of general interest...]  


Organization: Grebyn Corporation
Phone: +1 703 281 2104

Quote:
>    Ada has far more reuseable ADTs already coded.  I'm coding a concurrent
>    ADT right now, in fact.  Vendors such as EVB, lib systems, Wizard
>    Software, and so on, have entire catalogs of Ada components you can buy

That's pretty good.  You only missed about another half dozen to ten
vendors.

   [Editor's note: I did say "and so on"...]

Quote:
>    Also, one can obtain a magtape copy of the Ada Software Repository from

>        MACA
>        Attn: Janet Mckellar
>        P.O. Drawer 100 - Bldg T148
>        White Sands Missile Rang, NM  88002

About ten other people also provide this service.  Differing formats are
supported by others for varying fees.  Folks on the arpanet can get it via
anonymous FTP.

Quote:
>    The Ada Information Clearinghouse Newsletter periodically summarizes major
>    Ada software libraries and systems; it's free, and you can get on the
>    mailing list by sending a postcard to

>        Ada Information Clearinghouse
>        c/o IIT Research Institute
>        4600 Forbes Blvd., Second Floor
>        Lanham, MD  20706-4312

As does my newsletter and recent book.  In case you missed the Jan/Feb Ada
Letters issue in which a draft of this review was printed:

==================================================================

Ada: Sources and Resources, 1989 Edition
  by Karl A. Nyberg

A Capsule Review by Dave Emery

At one time or another, most of us have served as "resource people"
for our companies on Ada.  Ada: Sources and Resources serves as a
single point for answering most of those non-technical "I have an Ada
question" phone calls that we seem to get.  Karl Nyberg has collected
information on vendors, organizations, publications and conferences,
and other related sources of Ada information, and placed it all into a
single volume.

The book starts off with a capsule history (presented chronologically)
of the Ada program.  This is particularly useful for documenting the
order of events in the history of Ada. (Which came first, the ACVC
contract or the Preliminary Ada reference manual?)  The remaining
chapters cover compiler vendors, software tool vendors, groups and
organizations (both government and private), publications, electronic
services, consultants and trainers, conferences, professional
recruiters, books and finally a glossary of terms and acronyms.  Each
chapter covers the material alphabetically, with extensive
cross-referencing.

The best entries in the book include historical information on the
vendor or organization, as well as information on the product or
service provided.  The entries always include a point of contact.
Some entries are not as complete as others, and this lack of
consistency is one of the book's few shortcomings.

In his forward, Bob Mathis compares the book to a well-stocked
Rolodex.  This book has a tremendous advantage over a Rolodex, namely
the comprehensive indexes.  There are separate indexes for names of
individuals (points of contact), "items" (proper names, such as ACEC
and VADS), vendors, and organizations.  It would be nice if there
were an index to compilers and tools by computer, to answer questions
like "What tools run on a Sun?"

This is a valuable book.  I had a pre-publication draft that saved me
a lot of time going through back issues of Ada Letters and sales
brochures to find the name of a particular vendor or organizational
contact.  It deserves a place right next to your telephone, either to
answer questions, or to call someone to get an answer.

==================================================================

   [I have deleted Karl's standard advertising blurb]



P. O. Box 497                         {decuac,haven}!grebyn!karl
Vienna, VA 22183-0497                               703-281-2194



Mon, 20 Jul 1992 18:29:00 GMT  
 comments on comments

Quote:

>If you end up with "reusable and parameterized components ... loosely
>coupled... modular", then it doesn't matter how you got there.
>My argument is that in most cases, you are more likely to end up
>in such a software ecstacy if you use bottom-up design techniques,
>and you'll get there quicker.

We agree the components are desirable but a modular design should get you
there quickly too.   By breaking the system into smaller pieces with each
piece providing some well defined and more manageable part of the system,
the components should emerge.  Not only for the objects, but for the software
tools as well.  

Quote:
>I have tried to use the parts of other production compilers
>to do things other than pre-runtime compilation. Not as an academic
>exercise, but to produce real commercial products.  That's why I'm

Yes I have too.  I've taken a parser out of a 100,000 line compiler
and it wasn't pleasant.  I couldn't just take out the parser because
it was inextricable tied to the scanner and some semantics (typechecking)
was performed there too.  This undoubtable was due to efficiency reasons
and not top-down design.  If on the other hand the design had taken
reusable software tools into account the parser, scanner, and type system
would be separate entities with each providing a well defined interface.
It would be infeasible to reuse or add another scanner and much effort went
into taking the pieces out to the point where they were reusable.  They
finally did provide reusable components, the parser (and type-system)
generated an idl file representing the parsed functions and was used
immediately by two applications.  Someone recently asked to use the
parser/type-system and since yyparse (the parser) was modified to return
an object representing all the parsed declarations before passing them
to idl routines for output, he had exactly what he wanted in no time.
With just a little foresight on the part of the compiler designers and
with a greater priority given to software reuse the front-end of the
compiler would have provided the "software ecstasy" sought.  Of course,
Adts would have added greater potential for reuse of the data structures
involved but the tools were important too.

Quote:
>The argument for top-down design is based on some assumptions that are
>seldom met.  If the project has these properties, top-down design
>can be the best order of business.

>   1. Design and implementation are distinct and separate activities.

>      If they are not, you can't do one from one direction, and the
>      other from the other direction.

For projects which are not large, I think design will correspond
to recognizing the objects and major software components of the system,
and probably informal coding.  This isn't a major effort and can force
recognizing all issues involved very early.  For large projects, design and
implementation should be separate.

Quote:
>   2. A "correct design" can be identified without benefit of prototyping,
>      and it will inevitably be error free.

Aren't prototypes usually top-down and provide a skeletal framework to show
users so they can decide if the software is what they want, with each
function possibly stubbed out to provide simple or no service?   Or maybe
just a fast implementation to show the bottom level is even possible, but
I don't see what prototypability has to do with top-down design, to verify
the designs correctness?  I think prototyping can show the validity of a
"correct design", in other words top-down design with the benefit of
prototyping.

Quote:
>Or maybe somebody thinks up an entirely different kind of top-end that
>deals with the same kinds of objects.  Either way, you are likely SOL
>because those low level routines knew too much for their own good.  Now
>if the design at the low level is good, all is well.  Like I said, if you
>get there, it doesn't much matter how you got there. But which technique
>is less error-prone?

Good design will keep the low-level routines from knowing too much,
top-down or otherwise.  Just keep this in mind and you're SIL:-)

Quote:
>I say, The bottom-up design provided them with software that didn't
>"know it was in a compiler".  Recall, I did not even know about that
>project when I started the compiler.
>And I meant it literally when I said, "Try doing that with a Pascal
>compiler that was designed top-down to be a Pascal compiler."

>Actually try it.  

But with a modular design (top-down within modules) the tools are
functionally separate and they should not know they are a compiler, just
what their well defined function is to provide and an interface to meet.
I think keeping separate functionality separate is something thats really
important regardless of whether the encapsulation comes through packages,
processes, or whatever.  The same applies to objects, even when designed
top-down the lower level implementation of the Adt should be based on
components which are as generic as possible, I don't see how providing the
implementation calls for non-generic units since the recursive application
of good design will call for modular and generic components which are used
to implement the object.  I can see that if a designer throws away all
design principles after identifying the top level object he could end up
with an unstructured, data-structure oriented, special purpose implementation
but that should be easy to avoid.

Bob Hathaway



Mon, 20 Jul 1992 00:53:00 GMT  
 comments on comments

Quote:

>But it's true that Ada is better for applying object-oriented strategies
>than most other "conventional" languages.

I strongly agree, most other conventional languages are data-structure
oriented and not Adt/object oriented in programming constructs or
methodology.

Quote:
>As for bottom-up vs. top-down, Meyer explains this very well in his
>book, and it's certainly applicable to the recent discussion.

Could you elaborate on this, does he advocate top-down, bottom-up, ???
I haven't read Meyer's book.  

Bob Hathaway



Mon, 20 Jul 1992 01:16:00 GMT  
 comments on comments

Quote:

> > What I like to stress is: Ada is *not* an object-oriented language.
> > [it lacks] inheritance and dynamic typing.....

>       Software Productivity Solutions, Inc., has announced a new product,
>       Classic-Ada (tm), which allows Ada software developers to use
>       inheritance and dynamic binding in object-oriented Ada designs.

Lest anyone get the wrong impression about Classic-Ada, let me
clarify: The Classic-Ada language is *not* legal Ada.  It is a unique
dialect, which consists of Ada extended (nicely) with a new
construct--the class--with inheritance and dynamic binding.

SPS, Inc., is to be commended for attempting to improve Ada's support for
object oriented programming.  But the resulting Classic-Ada language
is not legal Ada.  Classic-Ada programs must be put thru SPS'
translator to generate legal Ada.

Mr. Sommarskog is quite correct.  Ada lacks any specific mechanism for
defining relationships among classes; the Classic-Ada language
provides just this mechanism.  

Eiffel does manage to provide inheritance in a reasonably
strongly-typed framework.  In their zeal to facilitate object-oriented
programming, SPS added both inheritance and dynamic binding to
Classic-Ada.  Was dynamic binding necessary?  It seems to entirely
defeat the safety and reliability that was a goal of Ada.

I believe that Eiffel tries to provide both separate compilation and
generics, just like Ada.  And, just like Ada, I would suspect that the
early Eiffel compilers will have "teething problems."  (At OOPSLA '88,
I recall that several Eiffel users reported problems with the Eiffel
library manager; a real case of deja vu for us veteran Ada
programmers.)

Steven Litvintchouk
MITRE Corporation
Burlington Road
Bedford, MA  01730

Fone:  (617)271-7753

UUCP:  ...{att,decvax,genrad,ll-xn,philabs,utzoo}!linus!sdl

        "Those who will be able to conquer software will be able to
         conquer the world."  -- Tadahiro Sekimoto, president, NEC Corp.



Mon, 20 Jul 1992 04:11:00 GMT  
 comments on comments

Quote:


> >    I stand by my statement regarding Eiffel's flakiness.

> Do you mean that the language design is flakey, or that an
> implementation is flakey?  If the former, what is flakey about it?

From what I was able to gather at OOPSLA '88, the current Eiffel
*implementations* are indeed flaky, but no more so than was any Ada
compiler developed prior to 1985.

I am extremely interested in finding out whether Eiffel compilers do a
better job compiling Eiffel generics, than Ada compilers do compiling
Ada generics.  I remain disappointed in how poorly Ada generics are
implemented by some Ada compilers.

Steven Litvintchouk
MITRE Corporation
Burlington Road
Bedford, MA  01730

Fone:  (617)271-7753

UUCP:  ...{att,decvax,genrad,ll-xn,philabs,utzoo}!linus!sdl

        "Those who will be able to conquer software will be able to
         conquer the world."  -- Tadahiro Sekimoto, president, NEC Corp.



Mon, 20 Jul 1992 04:16:00 GMT  
 
 [ 53 post ]  Go to page: [1] [2] [3] [4]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software