From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,2afac1a4161c7f35
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Distinguishing type names from other identifiers
Date: 1998/01/16
Message-ID: <dewar.884996184@merv>#1/1
X-Deja-AN: 316693438
References: <884736089.2104295427@dejanews.com> <69lael$90o@top.mitre.org>
 <01bd2207$18f3fac0$95fc82c1@xhv46.dial.pipex.com> <dewar.884945034@merv>
 <69nt40$q7n@top.mitre.org>
X-Complaints-To: usenet@news.nyu.edu
X-Trace: news.nyu.edu 884996297 22247 (None) 128.122.140.58
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1998-01-16T00:00:00+00:00
List-Id: <comp.lang.ada>


<<It is okay to espouse your beliefs, but it would be better to permit
  the existence of other beliefs to co-exist with yours, and not be
  so absolute as in the above quote phrase.

  There is a certain level of project where it becomes essential to
  stop measuring regimentation and volume, and instead measure the
  things that make software maintenance more expensive. That is,
  those things that cause the maintainer to spend more time analyzing
  the impact of changes.>>

Well I disagree, and as I say, as a software manager, I simply would
not tolerate anyone who had this kind of attitude. I find this kind
of chafing under rules to be very damaging to group productivity.
But I am just telling you what my experience is. You certainly will
not persuade me to change my views. At the same time, I am not saying
everyone else has to share these views. There are obviously a lot of
people around who prefer the let-me-hack-away-using-my-own-style
school of thought. All I am saying is that I don't want such people
around my projects.

For example, if someone chafed at using the standard indentation prescribed
by a project, and used there own standard, grudgingly using some tool to
change to the standard rules, I would regard this as evidence of EXACTLY
the kind of attitude that I would want to weed out right away. Avoiding
the evils of code ownership and idiosyncratic styles is for me a key
part of software management

<<As proof that gnat has evolved past the level where regimentation
  can make it maintainable, we have the decision of ACT that is too
  expensive to upgrade the current version of gnat for DOS, gnat 3.07,
  to a later version. Specifically, rather than becoming cheaper and
  cheaper gnat is becoming more expensive to maintain.>>

Chuckle, chuckle, Michael manages to climb on his DOS hobby horse in
very surprising ways :-)

The claim of course is complete nonsense. gnat has not become unmaintainable.
The reason there is no new update of the DOS versoin is that we have invested
zero effort in producting a new version. I am afraid that we have not been
able to manage to make GNAT so maintainable that it maintains itself. As I
have many times pointed out, updating GNAT to current sources is not a big
task, but we have no interest in spending any time at all doing it, since
we see no customer interest in DOS at all. Michael sounding off on CLA
does not generate revenue :-)

<<How much of the increase in the maintenance expense of gnat is
  attributable to the philosophy of regimentation of SYNTAX,
  rather than measuring the semantic problems?>>

There is no such increase, and it is absolutely clear to us that what
worries you as "regimentation of syntax" is one of the reasons that we
are able to be as productive as we are in the continued development
and maintenance of GNAT.

<<Certainly, enforcing syntax rules is trivial with the right tools.
  But reducing the number of references to global variables, making
  more types limited private, making more variables local, and
  making more packages pure might take away more bugs in the gnat
  code than continuing to enforce those syntax rules. It is worth
  an experiment or two.>>

This is apples and oranges. Of course everyone agrees that code should
be written in a clear manner avoiding nasty things etc etc, but you cannot
legislate good code by automatic rules.

On the other hand, uniformity of syntax is NOT about reducing bugs. It is
about creating a code base that everyone in the group feels comfortable
with, so that you avoid the phenomenon, all too common I am afraid in many
large projects, of individuals "owning" pieces of the code and (a) not
wanting anyone else to mess with their parts and (b) not being willing to
mess with other peoples code.

The bottom line here is that of course opinions differ. I find Michael's
contributions on this issue constructive because they form a nice example
of *exactly* the attitudes that I think are important to avoid!