Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!necntc!dandelion!ulowell!apollo!marc
From: marc@apollo.uucp (Marc Gibian)
Newsgroups: comp.software-eng
Subject: Re: Question Re: Configuration Management
Message-ID: <3a7488cf.fed5@apollo.uucp>
Date: 23 Feb 88 13:33:00 GMT
References: <497@aimt.UUCP> <2640@ihlpe.ATT.COM> <188@dinl.mmc.UUCP> <213@ritcv.UUCP>
Reply-To: marc@apollo.UUCP (Marc Gibian)
Organization: Apollo Computer, Chelmsford, MA
Lines: 27
Keywords: configuration management, software design

In article <213@ritcv.UUCP> mjl@ritcv.UUCP (Michael Lutz) writes:
>the details of the data organization I choose.  The natural package in C
>is one where the implementation "secrets" are kept as static global
>data structures (and internal support routines are static as well, to
>avoid name clashes with the client).  To do this, of course, the visible
>operations must be in the same file at compile time -- and I argue
>that they form a unified abstraction that *should* be in one file.  If

This is simply one of the limitations of the c language which should be
considered when going through the language selection process.  If
strict configuration management is highly valued in your project, then
this becomes a significant vote -AGAINST- c.

It seems that very few projects go through a language selection process.
Instead, a language is chosen because it is the -IN- language.  I believe
that if more attention were paid to this issue, there would be fewer
cases of people trying to make particular languages do what they just
plain can not do, or can not do well.

c is a good language for many projects.  But it tends to get into trouble
as the size of a project grows.  There have been many fine articles on
this subject and I do not intend to write my own here.  I simply want
to point out that there are many projects out there using c that
probably should be using some other language.  And this results in
a great deal of agony for the engineers working on these projects.

Marc S. Gibian
email:  marc@apollo.UUCP