* Re: software engineering and the notion of authorship
[not found] <01BB6E34.8313FAA0@idc213.rb.icl.co.uk>
@ 1996-07-10 0:00 ` Robert Dewar
1996-07-10 0:00 ` Robert Dewar
1996-07-11 0:00 ` Hugh Dunne
2 siblings, 0 replies; 18+ messages in thread
From: Robert Dewar @ 1996-07-10 0:00 UTC (permalink / raw)
Simon says
"We have a similar story here, a well known and extremely good assembler =
programmer wrote a large (>800 line) assembler package with one comment, =
next to a Jump-If-Equal statement he wrote the single comment "Jump here =
if not equal" - Wonderful!"
Of course, the fault lies here not with the programmer, but with the
environment and management which allowed this code to be placed into
the system. The programmer should have been forced to write in a reasonable
style or gotten rid of. There is no such thing as an "extremely good
assembler programmer" who would write a package of this size with no
comments. The real fault lies with a manager who did not realize this
and who tolerated such nonsense.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: software engineering and the notion of authorship
[not found] <01BB6E34.8313FAA0@idc213.rb.icl.co.uk>
1996-07-10 0:00 ` software engineering and the notion of authorship Robert Dewar
@ 1996-07-10 0:00 ` Robert Dewar
1996-07-11 0:00 ` Hugh Dunne
2 siblings, 0 replies; 18+ messages in thread
From: Robert Dewar @ 1996-07-10 0:00 UTC (permalink / raw)
"We have a similar story here, a well known and extremely good assembler =
programmer wrote a large (>800 line) assembler package with one comment, =
next to a Jump-If-Equal statement he wrote the single comment "Jump here =
if not equal" - Wonderful!"
Of course, the fault lies here not with the programmer, but with he
environment and management which allowed this code to be placed into
the system. The programmer should have been forced to write in a reasonable
style or gotten rid of. There is no such thing as an "extremely god
a
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: software engineering and the notion of authorship
[not found] <01BB6E34.8313FAA0@idc213.rb.icl.co.uk>
1996-07-10 0:00 ` software engineering and the notion of authorship Robert Dewar
1996-07-10 0:00 ` Robert Dewar
@ 1996-07-11 0:00 ` Hugh Dunne
2 siblings, 0 replies; 18+ messages in thread
From: Hugh Dunne @ 1996-07-11 0:00 UTC (permalink / raw)
Simon Johnston <skj@ACM.ORG> wrote:
>I had to maintain a large chunk of code which had only one comment =
>(well,
>I tell a lie, there were two: a commented out chunk of code -- with no
>reason -- and the copyright notice) and a lot of one or two letter
>identifiers. And code reviews were not a political practicality with
>that piece of code: it had been written by the _founder_ of the
>company before I joined. And he had left.
>
>We have a similar story here, a well known and extremely good assembler =
>programmer wrote a large (>800 line) assembler package with one comment, =
>next to a Jump-If-Equal statement he wrote the single comment "Jump here =
>if not equal" - Wonderful!
Some of the (few) comments seen in the source code of a certain
Ada compiler vendor's run time system:
"Go backwards or die!!!"
"Stupid Ada!"
--
--------------- http://www.vjf.com/PUBLIC/86/27186.html ---------------
Hugh Dunne/Logica UK Ltd/Stephenson House/75 Hampstead Rd/London NW1 2PL
The above are strictly my own personal opinions | dunneh@lhd.logica.com
and in no way reflect the opinions of Logica. | +44 171 446-1608
^ permalink raw reply [flat|nested] 18+ messages in thread
* Language Choice and Coding style
@ 1996-06-21 0:00 Nasser Abbasi
1996-06-27 0:00 ` Adam Beneschan
0 siblings, 1 reply; 18+ messages in thread
From: Nasser Abbasi @ 1996-06-21 0:00 UTC (permalink / raw)
Tonight I'd like to ask a question I've always been afraid to ask.
I'd like to know why do C and C++ programmer
pchWriteInThisStargeAndHardToReadWayLikeThis while the Ada programmers
Write_In_Clear_And_Nice_Way_Like_This ??
Is this a cultural thing? I don't want to get into case sensitive
or not case senstive issue here, since I don't see why this way of
writing has anything to do with it.
My own personal analysis of the situation after long thought is that
it is a cultural thing.
Most C and C++ programmers are more hippy , 1960's type, type of people,
the anti-establishment crowd, who just want to be different, and so
they adjust the code more so by WritingItLikeTHis so that the unique
personality of the C/C++ programmer comes out in distinctive way from
the rest of the programmer community at large.
While the Ada programmers seem to be more of the conservative type,
the type who would never go faster than 55 mph even in the middle of dead
valley where there is no traffic for miles on stretch, the type who
would never color their hair or do something anti-establisment and so
this reflect in the Long_And_Slow_But_Sure_Way_They_Write_The_Code.
I must admit that I myself, on a bad day, when I am mad about something,
(like a bug that is hard to find) that IdoStartWritingLikeThisAndRightlySo,
but most days I_Like_To_Write_Like_This, and my code as a result is very
easy to read.
I don't think I've seen Ada code written the C/C++ way, and I dont
think I've seen C/C++ code writeen the Ada way. I've seen code
written like_this_with_no_upper_case which is C/C++ code, but that
was very rare.
SO, why do you think this difference exist between the 2 groups of
programmers? It seems to be getting worse with time. I remmember
starting to first see ThisTypeOfWritingOfCode around 1985-1986 time
frame, I dont think I saw this before but I can be wrong. So the
question is really, what did happen in 1985-1986 to cause this?
It can't be just a random thing. This time frame seems to coinside
with C++ becomming more populare and starting out, but there is
nothing in the C++ language manual that SaysOneMustWriteLikeThis , and
also there is nothing in the Ada manual that says one Must_Write_Like_This,
so what is the deal here?
I'd like to research this further and find out how do Cobol and PLi and
Basic and other programmer write, and see if there is a correlation
between the emotional/cultural profile of the programmer and between
the tyep of the language they use and the manner of which they write
in it.
Well, thank you in advance for your opinion on this subject.
nasser
--
Nasser Abbasi. C/C++/Ada Solaris. GeneAssist - A client/server application
for Nucleic acid and protein sequence search and analysis.
PE-Applied BioSystem division. email: nasser@apldbio.com
MSEE(control), MSCS, MSCE, FM(Fide Chess Master 2305 ELO 1.e4 !!)
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Language Choice and Coding style
@ 1996-06-27 0:00 ` Adam Beneschan
1996-06-28 0:00 ` Peter Hermann
1996-07-19 0:00 ` Andrew Gierth
0 siblings, 2 replies; 18+ messages in thread
From: Adam Beneschan @ 1996-06-27 0:00 UTC (permalink / raw)
In article <dewar.835537168@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:
>James said
>
>" Except for the "Hungarian notation" silliness, the idea of
>spellingVariableNamesLikeThis was originally a Smalltalk and/or Pascal
>idiom, and it has become nearly universal in GUI libraries (again I
>think because of Smalltalk's influence). C programmers use variable names
>
>
>I really think this is Pascal influence rather than Smalltalk influence,
>since it predates the Smalltalk craze. Remember that Pascal had an
>out-of-proportion influence on PC's because of Turbo-Pascal. The Microsoft
>interfaces, on which many C programmers grow up, are Pascal derived (they
>even used Pascal calling sequences, and needed special treatment from C
>to get the calling sequence right). As I said in an earlier message, I
>trace the StyleOfSmashingWordsTogetherWhichIDoNotLike to UCSD Pascal.
UCSD Pascal had a TURTLEGRAPHICS package for teaching graphics to
beginning programmers. (We called it TURKEYGRAPHICS because it
gobbled up memory.) It was very simple conceptually; you could move a
cursor around the screen, and you had a "pen" that you could raise or
lower--if the pen was down, moving the cursor would cause lines to be
drawn along the screen.
Lore has it that the UCSD Pascal code for TURTLEGRAPHICS had a Boolean
variable that would, in Ada, be written as Pen_Is_Down. Another
variable was called Go_On. Neither one looks very appealing when
written in all-capital letters with no underscores. This might have
been one reason UCSD adopted the smashed-together mixed-case style
(also called "pseudo-Germanic", probably because the German language
sometimes forms nouns by smashing several words together). This was
the best they could do, since Pascal doesn't allow underscores in
identifiers (UCSD Pascal actually did, but it was a non-standard
extension nobody used).
-- Adam
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Language Choice and Coding style
1996-06-27 0:00 ` Adam Beneschan
@ 1996-06-28 0:00 ` Peter Hermann
1996-06-28 0:00 ` Robert A Duff
1996-07-19 0:00 ` Andrew Gierth
1 sibling, 1 reply; 18+ messages in thread
From: Peter Hermann @ 1996-06-28 0:00 UTC (permalink / raw)
Adam Beneschan (adam@irvine.com) wrote:
: Lore has it that the UCSD Pascal code for TURTLEGRAPHICS had a Boolean
: variable that would, in Ada, be written as Pen_Is_Down. Another
: variable was called Go_On. Neither one looks very appealing when
: written in all-capital letters with no underscores. This might have
I wonder why people expose themselves to extra work.
Since a couple of years I even quit typing capital letters at all.
In former days I believed that typing the keywords in a different
style, for textbook purposes, but I have changed my mind: no big win.
It is much more comfortable to ignore the shift key on the keyboard.
What a blessing that Ada allows this!
If Ada had the Unix/C-malady of case-sensitivity
(imho a non-professional academic joke)
I never had accepted Ada, anyway, right from the beginning.
And I would reject an text editor which does not have
the non-case-sensitive search function as default.
I made the experience that lower case letters are faster to read.
: been one reason UCSD adopted the smashed-together mixed-case style
: (also called "pseudo-Germanic", probably because the German language
: ( sometimes forms nouns by smashing several words together). This was
We Germans are used to easily read combined nouns such as "pseudogermanic".
We even do not need a hyphen between the subcomponents when reading
"Adacompiler", "Gnatlinker", "Compilermanufacturer", etc..
Nevertheless I am a strong advocate of heavy use of underscores.
Therefore I would prefer e.g. turtle_grafics, pen_is_down, go_on, etc.
in "programcode" ;-).
for one thing i have an extreme antipathy:
the enforcement of rules which do not have a useful justification.
if someone chooses for himself to carve all in CAPS, he may
freely do so, but he should not bother me to request this from me.
--
Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Language Choice and Coding style
1996-06-28 0:00 ` Peter Hermann
@ 1996-06-28 0:00 ` Robert A Duff
1996-06-29 0:00 ` Samuel Mize
0 siblings, 1 reply; 18+ messages in thread
From: Robert A Duff @ 1996-06-28 0:00 UTC (permalink / raw)
In article <4r059t$2at0@info4.rus.uni-stuttgart.de>,
Peter Hermann <ucaa2385@alpha1.csv.ica.uni-stuttgart.de> wrote:
>for one thing i have an extreme antipathy:
>the enforcement of rules which do not have a useful justification.
>if someone chooses for himself to carve all in CAPS, he may
>freely do so, but he should not bother me to request this from me.
Software "engineering" is the only engineering discipline I know of
where the practitioners commonly take this "cowboy" attitude -- "you can
do things however you like; just let *me* do things *my* way." It works
OK on one-person projects, but as soon as two or more people have to
work together on the same program, it's a disaster.
There's no "useful justification" for making everybody drive on the
right-hand side of the road, either. But there *is* a useful
justification for making everybody drive on the same side of the road.
- Bob
P.S. I agree that the ALL_CAPS style is ugly.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Language Choice and Coding style
1996-06-28 0:00 ` Robert A Duff
@ 1996-06-29 0:00 ` Samuel Mize
1996-06-29 0:00 ` Robert Dewar
0 siblings, 1 reply; 18+ messages in thread
From: Samuel Mize @ 1996-06-29 0:00 UTC (permalink / raw)
In article <Dtprq5.4Dr@world.std.com>,
Robert A Duff <bobduff@world.std.com> wrote:
>In article <4r059t$2at0@info4.rus.uni-stuttgart.de>,
>Peter Hermann <ucaa2385@alpha1.csv.ica.uni-stuttgart.de> wrote:
>>for one thing i have an extreme antipathy:
>>the enforcement of rules which do not have a useful justification.
>>if someone chooses for himself to carve all in CAPS, he may
>>freely do so, but he should not bother me to request this from me.
>
>Software "engineering" is the only engineering discipline I know of
>where the practitioners commonly take this "cowboy" attitude -- "you can
>do things however you like; just let *me* do things *my* way." It works
>OK on one-person projects, but as soon as two or more people have to
>work together on the same program, it's a disaster.
This is true, and in keeping with Ada/Software Engineering philosophy.
(A lot of hackers call themselves "software engineers" -- they're
as truly "engineers" as are "sanitation engineers." There are also
people really trying to create an engineering discipline, and have
been for decades.)
Anyway, for this particular small area -- code formatting -- the best
approach is to use a formatting editor, so everybody can set up his
*own* preferences and see the code the way *he* finds most readable.
(Or she.)
Samuel Mize
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Language Choice and Coding style
1996-06-29 0:00 ` Samuel Mize
@ 1996-06-29 0:00 ` Robert Dewar
1996-07-04 0:00 ` Peter Hermann
0 siblings, 1 reply; 18+ messages in thread
From: Robert Dewar @ 1996-06-29 0:00 UTC (permalink / raw)
Samuel says
"Anyway, for this particular small area -- code formatting -- the best
approach is to use a formatting editor, so everybody can set up his
*own* preferences and see the code the way *he* finds most readable.
(Or she.)"
I strongly disagree. In theory this sounds OK, but style covers much more
than simple rules that can be messed around with by a formatting editor.
If a team is not willing to agree on unimportant little things, but insists
on going their own individual way, I think you have little hope of
achieving a high degree of coding style consistency, something I think
is vital for the success of software projects with more than one person
involved.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Language Choice and Coding style
1996-06-29 0:00 ` Robert Dewar
@ 1996-07-04 0:00 ` Peter Hermann
1996-07-04 0:00 ` Robert Dewar
0 siblings, 1 reply; 18+ messages in thread
From: Peter Hermann @ 1996-07-04 0:00 UTC (permalink / raw)
Robert Dewar (dewar@cs.nyu.edu) wrote:
: I strongly disagree. In theory this sounds OK, but style covers much more
: than simple rules that can be messed around with by a formatting editor.
: If a team is not willing to agree on unimportant little things, but insists
: on going their own individual way, I think you have little hope of
: achieving a high degree of coding style consistency, something I think
: is vital for the success of software projects with more than one person
: involved.
IMHO, you are going a bit too far.
I had to manage implementations on every existing (reasonable) hardware
of 2 very large Fortran-systems with contributions of more that 2 dozen
people, approx. 100 people over the time, of course.
For consistent development of code I wrote a "Fartran harter Standard"
(oh, nice typo :-) "Fortran harter Standard", of course.
In this guide, all contributors were obliged to follow a lot of rules.
People hated me first but later on they were grateful when they saw
that we had (nearly) push-button installations on different systems.
With the appearance of Ada I recognized that we would not have more the
need to impose extra rules on our own, a really great advantage.
Because: Every rule which can be dropped is a good rule.
The fewer rules we have the greater the acceptance.
I hate it to impose rules. In Ada this is very possible.
In Ada nobody can escape the useful language rules without being
punished by rejection (how practical ;_).
I like it to allow everyone to show his personal style.
This is even important because the motivation is very much higher.
They are and should keep to be individuals.
And I like it when I see at first glance "Oh that is the typical
style of Barbara". This holds for code production inside bodies.
If a team agrees on a specific shape of the interfacing stuff,
this must be accepted by the whole team. Agreements of that kind
can then be carried by everybody in the team (then they really like it).
--
Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Language Choice and Coding style
1996-07-04 0:00 ` Peter Hermann
@ 1996-07-04 0:00 ` Robert Dewar
1996-07-05 0:00 ` software engineering and the notion of authorship Fergus Henderson
0 siblings, 1 reply; 18+ messages in thread
From: Robert Dewar @ 1996-07-04 0:00 UTC (permalink / raw)
Peter Herman says
"I like it to allow everyone to show his personal style.
This is even important because the motivation is very much higher.
They are and should keep to be individuals.
And I like it when I see at first glance "Oh that is the typical
style of Barbara". This holds for code production inside bodies."
Fascinating to see this point of view expressed so directly (it is I am
sure shared in practice by many programmers).
To me this "ego-centered" style of programming is deadly. It promotes a
situation where in a big project code is owned by individuals. Clearly
if you see that some code is "typical Barbara" style, then the next step
is that only Barbara touches that code, and a consequence is that only
Barbara really looks at that code.
This is not team work, this is a collection of individuals working together,
and you lose the advantages of working as a team. In particular:
a) If Barbara starts polishing her resume, you can be in big trouble
b) Only one pair of eyes looks at Barbara's code (other people don't
because they have their own style they prefer to read).
Furthermore, anyone maintaining the system will find a collection of
different styles that will make it much harder to understand what is
going on.
It's certainly interesting that in the GNAT project, we work hard to achieve
the exact opposite of what Peter regards as acceptable or even desirable.
We work to get complete consistency of sources. This is partly done by
automatic tools (try turning on the -gnatg switch sometimes), and partly
by following a set of standards, which are then informally enforced by
modifications being read by multiple people. You absolutely cannot tell
who wrote code from its style, and indeed we strongly discourage the notion
of authorship (we never for example attach names to units). Sure in practice
certain people know certain code well and our informally the experts in
particular areas, but if you look at the revision histories, you will see
that all sorts of people work in all parts of the system.
In Peter's view of the world, I have too often seen the kind of code
ownership where the owner of the code resents anyone else looking at
their code, let alone modifying it. In GNAT, we strive for and generally
achieve an environment in which your reaction to someone fixing a problem
in code that you wrote is "great, one problem that *I* don't have to fix!"
As for motivation, I think Peter is quite wrong there too. We agree up
front to work as a team. We decide style rules by a vote, but once the
vote is taken that's that. Sometimes it takes a bit of time to get used
to rules. For example, I used to always WRITE_MY_IDENTIFIERS in Ada 83
upper case style (which was the Alsys coding standard), but everyone
else on the team preferred to Write_Their_Identifiers_This_Way, so I
had to change. It took a while to adjust, but now I HATE_THESE_CAPITALS
and Find_This_Style much more natural. The final result is that you
have a team that very much agrees on these style issues, and that
works together as a team. In my experience, as in sports, this team
spirit is a key factor in maintaining a high level of motivation.
Perhaps it is possible to operate a large complex project successfully
with Peter's view, but I have never seen it succeed. On the other hand,
I have seen the team view point work well, both in GNAT and other
projects I have worked on, though I have never seen a project where
the consistency of style achieved for GNAT was as pronounced.
Robert Dewar
^ permalink raw reply [flat|nested] 18+ messages in thread
* software engineering and the notion of authorship
1996-07-04 0:00 ` Robert Dewar
@ 1996-07-05 0:00 ` Fergus Henderson
1996-07-08 0:00 ` Peter Hermann
` (2 more replies)
0 siblings, 3 replies; 18+ messages in thread
From: Fergus Henderson @ 1996-07-05 0:00 UTC (permalink / raw)
In comp.lang.ada, dewar@cs.nyu.edu (Robert Dewar) writes:
>To me this "ego-centered" style of programming is deadly. It promotes a
>situation where in a big project code is owned by individuals.
I agree consistency is very important, as is maintainability.
It is essential to make sure that the overall design is consistent.
It is also essential that every part of the system is sufficiently
clear, well-documented, and so forth that any programmer could make
modifications to that part of the system, or take over responsibility
for that part of the system, and consistency of style is important
in facilitating this. But I'm not convinced that recording
authorship or assigning areas of responsibility is a bad idea.
>you lose the advantages of working as a team.
Teamwork has it's own disadvantages. In particular, productivity goes
way down! (See "The Mythical Man-Month".) If there is a problem
in a particular piece of code, it makes sense for the expert on
that subsystem to be the one to fix it. They'll be able to do
it quicker, and with less likelyhood of error, than someone who
is not an expert on that subsystem. It also makes sense for the
expert on a subsystem to be part of the code review team for any
changes to that subsystem, and assigning some degree of responsibility
to the expert can increase their motivation to do a good job of
code review. Of course you need to make sure that the code is
sufficiently consistent, well-documented, etc. that anyone can _become_
the expert, when and if necessary. But it's impossible for everyone
to be the expert on everything.
>in the GNAT project ... You absolutely cannot tell
>who wrote code from its style, and indeed we strongly discourage the notion
>of authorship (we never for example attach names to units). Sure in practice
>certain people know certain code well and our informally the experts in
>particular areas, but if you look at the revision histories, you will see
>that all sorts of people work in all parts of the system.
What's wrong with recognizing the role of these informal experts?
>In my experience, as in sports, this team
>spirit is a key factor in maintaining a high level of motivation.
As in sports, I think it is useful to assign individuals particulars
areas of responsibility. In Australian rules football, a team has
forwards, a backline, centers, and on-ball players (rovers, a ruckman
or two, and so forth). It's not just a mob.
And while team spirit is important, so is individual motivation, and
a little bit of competition between players is a good thing, so long
as they're competing for success in meeting the team's objectives,
not competing for the ball. A team plays better if they have a good
reserves team, with players competing for spots in the team. And
players within a team compete for the team's best-and-fairest awards.
The important thing, IMHO, is finding the right balance.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: software engineering and the notion of authorship
1996-07-05 0:00 ` software engineering and the notion of authorship Fergus Henderson
@ 1996-07-08 0:00 ` Peter Hermann
1996-07-08 0:00 ` Jakob Engblom
1996-07-15 0:00 ` Ralph Silverman
2 siblings, 0 replies; 18+ messages in thread
From: Peter Hermann @ 1996-07-08 0:00 UTC (permalink / raw)
Fergus Henderson (fjh@mundook.cs.mu.OZ.AU) wrote:
: In comp.lang.ada, dewar@cs.nyu.edu (Robert Dewar) writes:
: >To me this "ego-centered" style of programming is deadly. It promotes a
: >situation where in a big project code is owned by individuals.
: I agree consistency is very important, as is maintainability.
: It is essential to make sure that the overall design is consistent.
: It is also essential that every part of the system is sufficiently
: clear, well-documented, and so forth that any programmer could make
: modifications to that part of the system, or take over responsibility
: for that part of the system, and consistency of style is important
: in facilitating this. But I'm not convinced that recording
: authorship or assigning areas of responsibility is a bad idea.
Thank you for your contribution (you are saving my time ;-).
Special topic "authorship": this has revealed to be one of the
most important properties of our systems. Each routine has
short "date/author/topic"-comments of creation and all subsequent updates.
[snip]
: And while team spirit is important, so is individual motivation, and
[snip]
: The important thing, IMHO, is finding the right balance.
agree
I also agree to most of the rules given in "Ada Quality and Style"
and it is a fun to read this document because it is
spreading a feeling of deep SE-experience of its authors.
OTOH, "honny soit qui mal y pense", I think it is a bad idea
to impose EXTRA rules on human beings which do not have an important
justification.
E.g. it is of utmost importance to request variable names
which bear its exact meaning, it is not at all important
to force a programer to_type_in_any_capital_letters
when he chooses to be lazy like me ;-)
That's why Ada is so great with its minimum
consens of absolute necessities at the man-machine-interface.
--
Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: software engineering and the notion of authorship
1996-07-05 0:00 ` software engineering and the notion of authorship Fergus Henderson
1996-07-08 0:00 ` Peter Hermann
@ 1996-07-08 0:00 ` Jakob Engblom
1996-07-08 0:00 ` John Byerly
` (2 more replies)
1996-07-15 0:00 ` Ralph Silverman
2 siblings, 3 replies; 18+ messages in thread
From: Jakob Engblom @ 1996-07-08 0:00 UTC (permalink / raw)
Fergus Henderson wrote:
>
> In comp.lang.ada, dewar@cs.nyu.edu (Robert Dewar) writes:
>
> >To me this "ego-centered" style of programming is deadly. It promotes a
> >situation where in a big project code is owned by individuals.
Ego-less programming is absolutely necessary to produce large functioning
software. Or at least to maintain it later.
> If there is a problem
> in a particular piece of code, it makes sense for the expert on
> that subsystem to be the one to fix it. They'll be able to do
> it quicker, and with less likelyhood of error, than someone who
> is not an expert on that subsystem.
Yeah, but the real problem comes 10 years down the road, when the experts
have quit or died or moved to other projects and plain do not remember the
wonderfully complicated code they created back in '96...
Using a "just complicated enough to do the job", "ego-less" programming style,
makes it much easier for the new maintenance developer working with the
program in 2006... the savings in the long run far outweigh the lack of
"personal style" in the code.
> >in the GNAT project ... You absolutely cannot tell
> >who wrote code from its style, and indeed we strongly discourage the notion
> >of authorship (we never for example attach names to units). Sure in practice
> >certain people know certain code well and our informally the experts in
> >particular areas, but if you look at the revision histories, you will see
> >that all sorts of people work in all parts of the system.
!!!! SUPEr!!!!!
Only in software do we even think of accepting personal style like... it would
be quite devastating in any other industry if an engineer insisted on using
left-handed instead of right-handed bolts "because I feel creative today"..
things have to fit together, and TEAM WORK is the essential part of any
programming project.
/jakob
--
----------------------------------------------------------------------------
Jakob Engblom. Computer Science Student @ Uppsala University, Sweden
presently an ERASMUS exchange student in Stuttgart, Germany
email Uppsala: jakob@docs.uu.se
email Stuttgart: engblojb@tick.informatik.uni-stuttgart.de
homepage: http://www.csd.uu.se/~jakob
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: software engineering and the notion of authorship
1996-07-08 0:00 ` Jakob Engblom
@ 1996-07-08 0:00 ` John Byerly
1996-07-08 0:00 ` Fergus Henderson
1996-07-08 0:00 ` The Amorphous Mass
2 siblings, 0 replies; 18+ messages in thread
From: John Byerly @ 1996-07-08 0:00 UTC (permalink / raw)
Jakob Engblom wrote:
>
> Yeah, but the real problem comes 10 years down the road, when the experts
> have quit or died or moved to other projects and plain do not remember the
> wonderfully complicated code they created back in '96...
That's why we document code. Software engineering is the only engineering
discipline that considers documentation to be optional. And even when documents
are produced, they are almost never updated after the code is written.
Speaking as someone who always seems to get stuck maintaining code, I find that
something as simple as comments go a long way toward making my job easier.
> Using a "just complicated enough to do the job", "ego-less" programming style,
> makes it much easier for the new maintenance developer working with the
> program in 2006... the savings in the long run far outweigh the lack of
> "personal style" in the code.
I disagree. I started my software engineering career maintaining undocumented
FORTRAN code that was about as ego-less as you get and the thing was a nightmare.
More recently, I have maintained well commented, C++ code that was created using
a style that was unfamiliar. This experience was much less painful.
> Only in software do we even think of accepting personal style like... it would
> be quite devastating in any other industry if an engineer insisted on using
> left-handed instead of right-handed bolts "because I feel creative today"..
That is why this is called _soft_ware. To a certain extent, we have more
flexibility in creating our product than, say, a mechanical engineer. In a
strict sense, however, our deliverables are object files, libraries, executables,
etc., which had better match the specifications. This is the "right-handed bolt".
> things have to fit together, . . .
Quite true. That is what an Interface Specification is for.
__________________________________________________________________________
John A. Byerly Which way to Flower Mound, TX?
The Dalmatian Group, Inc.
User Interface Specialists Currently on site at:
jbyerly@dalmatian.com Motorola -- Chandler, AZ
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: software engineering and the notion of authorship
1996-07-08 0:00 ` Jakob Engblom
1996-07-08 0:00 ` John Byerly
@ 1996-07-08 0:00 ` Fergus Henderson
1996-07-09 0:00 ` Richard A. O'Keefe
1996-07-08 0:00 ` The Amorphous Mass
2 siblings, 1 reply; 18+ messages in thread
From: Fergus Henderson @ 1996-07-08 0:00 UTC (permalink / raw)
Jakob Engblom <engblojb@tick.infomatik.uni-stuttgart.de> writes:
>Ego-less programming is absolutely necessary to produce large functioning
>software. Or at least to maintain it later.
That's a slogan. If you have some justification for it, please state it.
>> If there is a problem
>> in a particular piece of code, it makes sense for the expert on
>> that subsystem to be the one to fix it. They'll be able to do
>> it quicker, and with less likelyhood of error, than someone who
>> is not an expert on that subsystem.
>
>Yeah, but the real problem comes 10 years down the road, when the experts
>have quit or died or moved to other projects and plain do not remember the
>wonderfully complicated code they created back in '96...
If the code is clear, well-written and well-documented -- you should
use code reviews to ensure this -- then I don't see why attaching
authorship labels or assigning clear areas of responsibility is going
to cause you problems 10 years down the road.
>Using a "just complicated enough to do the job", "ego-less" programming style,
>makes it much easier for the new maintenance developer working with the
>program in 2006... the savings in the long run far outweigh the lack of
>"personal style" in the code.
Of course you should not make the code more complicated than is necessary.
No self-respecting computer scientist or software engineer would
suggest otherwise. I'm not arguing for personal style -- I agree that
consistency makes maintenance easier. What I am arguing for is some
degree of personal responsibility.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: software engineering and the notion of authorship
1996-07-08 0:00 ` Fergus Henderson
@ 1996-07-09 0:00 ` Richard A. O'Keefe
1996-07-09 0:00 ` Fergus Henderson
1996-07-11 0:00 ` Paul Eggert
0 siblings, 2 replies; 18+ messages in thread
From: Richard A. O'Keefe @ 1996-07-09 0:00 UTC (permalink / raw)
fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) writes:
>>Yeah, but the real problem comes 10 years down the road, when the experts
>>have quit or died or moved to other projects and plain do not remember the
>>wonderfully complicated code they created back in '96...
>If the code is clear, well-written and well-documented -- you should
>use code reviews to ensure this -- then I don't see why attaching
>authorship labels or assigning clear areas of responsibility is going
>to cause you problems 10 years down the road.
Fergus and I see eye-to-eye on many points.
However, he is working in a project with a small number of brilliant
programmers who are good at writing comments.
I had to maintain a large chunk of code which had only one comment (well,
I tell a lie, there were two: a commented out chunk of code -- with no
reason -- and the copyright notice) and a lot of one or two letter
identifiers. And code reviews were not a political practicality with
that piece of code: it had been written by the _founder_ of the
company before I joined. And he had left.
The "ego-less culture" that allows programmers to adopt a common style
is the same culture that is needed to allow the founder to submit his
precious work to other people's judgement. I'm not arguing against
personal responsibility, only that the responsibility is responsibility
to *communicate*, and that adopting a common style in a project is one
of the things that *makes* the code clear.
--
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: software engineering and the notion of authorship
1996-07-09 0:00 ` Richard A. O'Keefe
@ 1996-07-09 0:00 ` Fergus Henderson
1996-07-11 0:00 ` Paul Eggert
1 sibling, 0 replies; 18+ messages in thread
From: Fergus Henderson @ 1996-07-09 0:00 UTC (permalink / raw)
ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
>Fergus and I see eye-to-eye on many points.
>However, he is working in a project with a small number of brilliant
>programmers who are good at writing comments.
Well, after that comment, our project is certainly going to have
trouble keeping the egos under control ;-) ;-) ;-)
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: software engineering and the notion of authorship
1996-07-09 0:00 ` Richard A. O'Keefe
1996-07-09 0:00 ` Fergus Henderson
@ 1996-07-11 0:00 ` Paul Eggert
1 sibling, 0 replies; 18+ messages in thread
From: Paul Eggert @ 1996-07-11 0:00 UTC (permalink / raw)
ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
> I had to maintain a large chunk of code which had only one comment ...
> and a lot of one or two letter identifiers. And code reviews were not
> a political practicality with that piece of code:
> it had been written by the _founder_ of the company before I joined.
> And he had left.
I had to maintain a similar batch of code, and if I'm not mistaken it
was written by the same guy for his previous company. It was a joy.
That guy really knew what he was doing, and his code taught me a lot of things.
But I had to write documentation describing the program so that
everybody else at our company could follow what was going on.
The documentation was considerably longer than the program that it described.
In extreme cases like this, the usual software engineering management
principles often don't work well. And extreme cases are often the
most profitable ones....
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: software engineering and the notion of authorship
1996-07-08 0:00 ` Jakob Engblom
1996-07-08 0:00 ` John Byerly
1996-07-08 0:00 ` Fergus Henderson
@ 1996-07-08 0:00 ` The Amorphous Mass
1996-07-08 0:00 ` Robert Dewar
2 siblings, 1 reply; 18+ messages in thread
From: The Amorphous Mass @ 1996-07-08 0:00 UTC (permalink / raw)
On Mon, 8 Jul 1996, Jakob Engblom wrote:
> !!!! SUPEr!!!!!
>
> Only in software do we even think of accepting personal style like... it would
> be quite devastating in any other industry if an engineer insisted on using
> left-handed instead of right-handed bolts "because I feel creative today"..
> things have to fit together, and TEAM WORK is the essential part of any
> programming project.
I have a simple question: Do we all mean the same thing by
"programming style?" It seems that the people supporting individual
style are assuming that there are *some* coding standards being followed,
and the "style" boils down to formatting idioms and whether they prefer
for, while, do-while, etc, or the _exact_ way they name variables (for
example, if the convention is To_Write_Variables_This_Way then one
person's List_Of_Items will be another person's Item_List, etc). The people
dissing it seem to think that it implies that no standard, or no
significant standard is being followed. Using a left-handed bolt one
day "because I feel creative" is like writing a module in SNOBOL one day
"because I feel creative." It doesn't have anything to do with the
particular coding idiom that a programmer uses (which should be
_consistent_: it is a means of expression, not a whim), and it doesn't mean
that the idioms can't be standardized to a certain extent, and it certainly
doesn't mean that one person cannot read another person's code. I
learned C from a textbook whose formatting style I immediately disliked,
but which I was nevertheless quite able to read. Now I can see both Mr.
Dewar's and Mr. Henderson's side of this issue -- I'm just getting the
feeling that not everyone is talking about the same thing.
If comments and documentation are counted as part of the code I would
be amazed to hear that there is a single project of any significant size
where it is impossible to tell who wrote the code, considering that
writing styles tend to be individual. Especially if the comments go into
any depth. :-)
James Robinson.........................................james-robinson@uiowa.edu
"To be prepared against surprise is to be /trained/. To be prepared for
surprise is to be /educated/." --James Carse, _Finite_and_Infinite_Games_
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: software engineering and the notion of authorship
1996-07-08 0:00 ` The Amorphous Mass
@ 1996-07-08 0:00 ` Robert Dewar
0 siblings, 0 replies; 18+ messages in thread
From: Robert Dewar @ 1996-07-08 0:00 UTC (permalink / raw)
James Robinson says
" If comments and documentation are counted as part of the code I would
be amazed to hear that there is a single project of any significant size
where it is impossible to tell who wrote the code, considering that
writing styles tend to be individual. Especially if the comments go into
any depth. :-)
"
Try looking at the GNAT souces, you may be amazed :-)
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: software engineering and the notion of authorship
1996-07-05 0:00 ` software engineering and the notion of authorship Fergus Henderson
1996-07-08 0:00 ` Peter Hermann
1996-07-08 0:00 ` Jakob Engblom
@ 1996-07-15 0:00 ` Ralph Silverman
1996-07-15 0:00 ` Fergus Henderson
1996-07-17 0:00 ` Robert Dewar
2 siblings, 2 replies; 18+ messages in thread
From: Ralph Silverman @ 1996-07-15 0:00 UTC (permalink / raw)
Fergus Henderson (fjh@mundook.cs.mu.OZ.AU) wrote:
: In comp.lang.ada, dewar@cs.nyu.edu (Robert Dewar) writes:
: >To me this "ego-centered" style of programming is deadly. It promotes a
: >situation where in a big project code is owned by individuals.
: I agree consistency is very important, as is maintainability.
: It is essential to make sure that the overall design is consistent.
: It is also essential that every part of the system is sufficiently
: clear, well-documented, and so forth that any programmer could make
: modifications to that part of the system, or take over responsibility
: for that part of the system, and consistency of style is important
: in facilitating this. But I'm not convinced that recording
: authorship or assigning areas of responsibility is a bad idea.
: >you lose the advantages of working as a team.
: Teamwork has it's own disadvantages. In particular, productivity goes
: way down! (See "The Mythical Man-Month".) If there is a problem
: in a particular piece of code, it makes sense for the expert on
: that subsystem to be the one to fix it. They'll be able to do
: it quicker, and with less likelyhood of error, than someone who
: is not an expert on that subsystem. It also makes sense for the
: expert on a subsystem to be part of the code review team for any
: changes to that subsystem, and assigning some degree of responsibility
: to the expert can increase their motivation to do a good job of
: code review. Of course you need to make sure that the code is
: sufficiently consistent, well-documented, etc. that anyone can _become_
: the expert, when and if necessary. But it's impossible for everyone
: to be the expert on everything.
: >in the GNAT project ... You absolutely cannot tell
: >who wrote code from its style, and indeed we strongly discourage the notion
: >of authorship (we never for example attach names to units). Sure in practice
: >certain people know certain code well and our informally the experts in
: >particular areas, but if you look at the revision histories, you will see
: >that all sorts of people work in all parts of the system.
: What's wrong with recognizing the role of these informal experts?
: >In my experience, as in sports, this team
: >spirit is a key factor in maintaining a high level of motivation.
: As in sports, I think it is useful to assign individuals particulars
: areas of responsibility. In Australian rules football, a team has
: forwards, a backline, centers, and on-ball players (rovers, a ruckman
: or two, and so forth). It's not just a mob.
: And while team spirit is important, so is individual motivation, and
: a little bit of competition between players is a good thing, so long
: as they're competing for success in meeting the team's objectives,
: not competing for the ball. A team plays better if they have a good
: reserves team, with players competing for spots in the team. And
: players within a team compete for the team's best-and-fairest awards.
: The important thing, IMHO, is finding the right balance.
: --
: Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
: WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
: PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
--
************begin r.s. response*************
a closely related question is:
if persons who are supposed to be
programmers
can usefully work in groups
or teams
were such persons not able
to program individually...
?
generally, one may suppose,
those capable of programming
individually would be accepting of
individuality
.
************end r.s. response***************
Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: software engineering and the notion of authorship
1996-07-15 0:00 ` Ralph Silverman
@ 1996-07-15 0:00 ` Fergus Henderson
1996-07-17 0:00 ` Robert Dewar
1 sibling, 0 replies; 18+ messages in thread
From: Fergus Henderson @ 1996-07-15 0:00 UTC (permalink / raw)
I got a useful reply from Scott Ellsworth <fuz@deltanet.com> via email;
he said he wouldn't mind if I posted it.
> Assuming the original poster is not a doof, what I assume he means by
> ego-less programming is simply programming for clarity, not cleverness.
> Often, if someone's name is atattched to a product, they get possessive,
> and try to do things in the most complex and clever way they know how.
> This does not actually give them a better rep in most other people's
> eyes, but inexperienced programmers often think it should.
>
> Proper training can break someone of this, just like it can break them of
> not commenting code that needs it, and proper code reviews can make
> overly clever code be rewritten for clarity. Of course, if the code is
> time critical and needs to be faster, then clever is good.
>
> Personally, I approve of pride of creation in most software projects, as
> long as that includes the stated assumption that your creation will
> become someone elses creation once you move to another project.
That reply explains to me some of the motivations behind ego-less programming
better than many of the other articles in this thread.
For the moment, I remain open-minded about whether or not recording authorship
is advantageous or disadvantageous overall. One thing is certain, and that
is that knowing the dangers helps one to avoid them.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: software engineering and the notion of authorship
1996-07-15 0:00 ` Ralph Silverman
1996-07-15 0:00 ` Fergus Henderson
@ 1996-07-17 0:00 ` Robert Dewar
1996-07-19 0:00 ` Mike Curtis
1 sibling, 1 reply; 18+ messages in thread
From: Robert Dewar @ 1996-07-17 0:00 UTC (permalink / raw)
Ralph Silverman asks
a closely related question is:
if persons who are supposed to be
programmers
can usefully work in groups
or teams
were such persons not able
to program individually...
?
generally, one may suppose,
those capable of programming
individually would be accepting of
individuality
I have worked completely on my own (e.g. several complete operating systems
written for Honeywell and the first version of Macro-SPITBOL), in small
teams (SPITBOL 370 was a 2-person effort, Realia COBOL was a 3-peson
effort), and in larger groups (GNAT is a several person effort).
I see no real differences. In each case, an absolute standard of consistency
is essential throughout the program. Remember that one of the major needs
for consistency is for maintenance, and how many people developed a project
is rather irrelevant when considering maintenance needs (all the programs
I mention abvove have been maintained by multiple people over the years).
When you are working alone, you can of course set your own standards of
consistency, but in fact I see many 1-person programs that are a mightmare
(oops typo, but rather nice one, I will leave it in :-) nightmare
of inconsistency. I couldn't possibly work that way myself.
When you are working together, you have first to agree on the standards
of consistency that you will use. That means you don't get to choose yourself
every detail, so what? For example, in the GNAT project, as I have mentioned
before, I was forced to change from ALL_UPPER_CASE_IDENTIFIERS to the more
usual Mixed_Case_Identifiers since that is what the team preferred. It was
awkward at first (you always find it easier to do what you are used to, and
to read code in the style you are used to), but it would never have occurred
to me to react to that awkwardness by insisting on continuing to SHOUT when
I wrote MY_IDENTIFIERS! Instead I conformed and quickly got used to the new
style (now it would be hard to go back).
However, I see many programmers for whom not only does it occur to them to
react in this situation by insisting on using their own style, but they do it
and their management permits it. I am certainly capable of programming
individually, but I am definitely NOT willing to accept this particular
brand of individuality, not for a moment!
The team effort issue of course only applies to groups, but there is another
factor that I think is important. Whether you are working alone or in a
group, an elegantly structured and consistently presented source code is
a source of pride, and that is definitely a positive dynamic in any project.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: software engineering and the notion of authorship
1996-07-17 0:00 ` Robert Dewar
@ 1996-07-19 0:00 ` Mike Curtis
0 siblings, 0 replies; 18+ messages in thread
From: Mike Curtis @ 1996-07-19 0:00 UTC (permalink / raw)
Robert Dewar wrote:
------ <snip> -------
> .... but it would never have occurred
> to me to react to that awkwardness by insisting on continuing to SHOUT when
> I wrote MY_IDENTIFIERS! Instead I conformed and quickly got used to the new
> style (now it would be hard to go back).
>
Ah Robert, but if you were insisting on writing the code in Ada and everyone else
wanted to use C would you fall in with them so readily.
Mike
--
Mike Curtis tel: +44 1753 679935
curmi02@unix9.ingres.com fax: +44 1734 442453
Computer Associates International
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: software engineering and the notion of authorship
1996-06-27 0:00 ` Adam Beneschan
1996-06-28 0:00 ` Peter Hermann
@ 1996-07-19 0:00 ` Andrew Gierth
1 sibling, 0 replies; 18+ messages in thread
From: Andrew Gierth @ 1996-07-19 0:00 UTC (permalink / raw)
[This thread should never have been injected into comp.unix.programmer.
Would all respondents *please* take that into account. Followups set.]
Mike Curtis <curmi02@unix9.ingres.com> wrote:
>Robert Dewar wrote:
>------ <snip> -------
>> .... but it would never have occurred
>> to me to react to that awkwardness by insisting on continuing to SHOUT when
>> I wrote MY_IDENTIFIERS! Instead I conformed and quickly got used to the new
>> style (now it would be hard to go back).
>>
>
>Ah Robert, but if you were insisting on writing the code in Ada and everyone else
>wanted to use C would you fall in with them so readily.
>
>Mike
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~1996-07-19 0:00 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <01BB6E34.8313FAA0@idc213.rb.icl.co.uk>
1996-07-10 0:00 ` software engineering and the notion of authorship Robert Dewar
1996-07-10 0:00 ` Robert Dewar
1996-07-11 0:00 ` Hugh Dunne
1996-06-21 0:00 Language Choice and Coding style Nasser Abbasi
1996-06-27 0:00 ` Adam Beneschan
1996-06-28 0:00 ` Peter Hermann
1996-06-28 0:00 ` Robert A Duff
1996-06-29 0:00 ` Samuel Mize
1996-06-29 0:00 ` Robert Dewar
1996-07-04 0:00 ` Peter Hermann
1996-07-04 0:00 ` Robert Dewar
1996-07-05 0:00 ` software engineering and the notion of authorship Fergus Henderson
1996-07-08 0:00 ` Peter Hermann
1996-07-08 0:00 ` Jakob Engblom
1996-07-08 0:00 ` John Byerly
1996-07-08 0:00 ` Fergus Henderson
1996-07-09 0:00 ` Richard A. O'Keefe
1996-07-09 0:00 ` Fergus Henderson
1996-07-11 0:00 ` Paul Eggert
1996-07-08 0:00 ` The Amorphous Mass
1996-07-08 0:00 ` Robert Dewar
1996-07-15 0:00 ` Ralph Silverman
1996-07-15 0:00 ` Fergus Henderson
1996-07-17 0:00 ` Robert Dewar
1996-07-19 0:00 ` Mike Curtis
1996-07-19 0:00 ` Andrew Gierth
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox