peters@cubsvax.UUCP (04/27/84)
Below are excerpts from fortune!crane's review of a new book on C programming.
I haven't seen the book, but the author's basic idea of how to program, which
crane shares, is the common textbook version that comes with the idea
of structured programming. I've reproduced crane's comments below.
Now, my question is, does anyone really program this way? I really want to
know! I certainly *mostly* do what the author (see below) calls BUGGING. When
I try to think everything out ahead of time, I find that before I get very far
I start being uncertain what the compiler, programming tools, etc., are
really going to do with the overall method I have in mind, and so I go in
and try it on elementary examples. Then I end up extending these elementary
examples over and over, and combining them with other extended elementary
examples, to make a program or package. Then I clean it up at the end. The
point is, it's an *iterative* process, not one in which I first plan, then
implement.
I'm sure that part of the reason I work this way is that I'm still not
completely comfortable with C and UNIX, but I tended to work this way even
in languages in which I felt very much at home.
{philabs,cmcl2!rocky2}!cubsvax!peters Dr. Peter S. Shenkin
Dept of Biol. Sci.; Columbia Univ.; New York, N. Y. 10027; 212-280-5517
>> From philabs!cmcl2!floyd!harpo!ihnp4!fortune!crane Wed Dec 31 19:00:00 1969
>>
>> This is a review of the book "C Programmer's Library" by Jack J. Pudrum
>> (author of "C Programming Guide"), Timothy C. Leslie (Dir. SWD @
>> Ecosoft), and Alan L. Stegemoller (coauthor of Ecosoft's Eco-C C
>> compiler), published by Que Corporation, Indianapolis, 1984.
>>
>> 0. Laying the Groundwork
>>
>> This chapter introduces the philosophy of the book and presents a
>> methodology for developing generalized C functions.
>>
>>* This chapter comes down heavy on people who, having been given the
>>* basic requirements for a program, immediately rush off to their
>>* terminals and start entering source code. The authors say: "These
>>* students are not programming; they are BUGGING. They will spend
>>* ten minutes bugging and another DEBUGGING (that is, correcting) the
>>* mess they will make in the first ten minutes." What you should do,
>>* they say, is to spend 10-15 minutes anayyzing the problem (the
>>* problem, by the way, is to write a program to sort 100 ZIP codes),
>>* then spend another 15 minutes coding and testing the program."
>>*
>>* (I agree with the above. I am not totally familiar with the term
>> "hacking", but to me hacking is analogous with "bugging". Somebody
>> correct me if I'm wrong. In my opinion, both are to be avoided in
>> favor of a planned, deliberate approach to solving a problem.)
>> dgary@ecsvax.UUCP (05/01/84)
The referenced article refers to the textbook approach to programming, i.e.
design, program, debug. The book in question even suggests that failing to
plan the program out carefully before writing is dangerous and bug-prone. The
author of the article asks if anyone actually programs that way, and what people
think of that approach.
Well, I for one subscribe to the notion of "stepwise refinement" or
(more poetically) "creeping elegance." The idea is to write a program that
(1) is small (2) does at least some of what you want the final program to
do, or shoots in that direction (3) works and (4) is easy to modify.
This makes it possible to program almost bug-free, and to catch bugs almost
as soon as they occur (so you don't have to go on a bug-hunt later on). The
idea is to keep adding to the program until you get what you want (or maybe
something better). A big plus to this approach is that the program remains
modifiable - one of the reasons for the high cost of software maintenance
(I suspect) is the tacit assumption that the program will never have to be
changed. If you know for a fact from the word go that mods are coming, you'll
write a better program most of the time. And certainly one that is easier to
fix and improve.
So no, I don't believe in plan-code-test. I believe in plan a little, code
a little, test a little, plan a little, code a little, test a little....
Long live Yourdon!
Best, D Gary Grady, Duke University
{decvax or whatever}!mcnc!ecsvax!dgarychenr@tilt.UUCP (Raymond Chen) (05/02/84)
>> The referenced article refers to the textbook approach to programming, i.e. >>design, program, debug. The book in question even suggests that failing to >>plan the program out carefully before writing is dangerous and bug-prone. The >>author of the article asks if anyone actually programs that way, and what >>people think of that approach. >> Well, I for one subscribe to the notion of "stepwise refinement" or >>(more poetically) "creeping elegance." The idea is to write a program that >>(1) is small (2) does at least some of what you want the final program to >>do, or shoots in that direction (3) works and (4) is easy to modify. >> This makes it possible to program almost bug-free, and to catch bugs almost >>as soon as they occur (so you don't have to go on a bug-hunt later on). The >>idea is to keep adding to the program until you get what you want (or maybe >>something better). A big plus to this approach is that the program remains >>modifiable - one of the reasons for the high cost of software maintenance >>(I suspect) is the tacit assumption that the program will never have to be >>changed. If you know for a fact from the word go that mods are coming, you'll >>write a better program most of the time. And certainly one that is easier to >>fix and improve. >> So no, I don't believe in plan-code-test. I believe in plan a little, code >>a little, test a little, plan a little, code a little, test a little.... >> Long live Yourdon! >> >> Best, D Gary Grady, Duke University >> {decvax or whatever}!mcnc!ecsvax!dgary Fine. Incremental programming can be a wonderful thing. I think, though, that you're missing the point of the book and that is that you don't start putting code into your computer until you know *exactly* what that code is going to do. After all, the idea behind programming incrementally is to do it in small steps so you can make sure that each step works. What that book was coming down on was what a lot of people tend to do and that is to sit down at a terminal with the specifications/goals and start typing a program without taking some time to make sure that what they're going to do will work, or even to make sure that they understand in toto, what the program is supposed to *do*. No matter how you write the system, the idea should be to avoid design/logic errors, and in most cases, make it extendable and maintainable. -- The preceding message was brought to you by -- Ray Chen princeton!tilt!chenr
mark@umcp-cs.UUCP (05/03/84)
> Well, I for one subscribe to the notion of "stepwise refinement" or > (more poetically) "creeping elegance." The idea is to write a program that > (1) is small (2) does at least some of what you want the final program to > do, or shoots in that direction (3) works and (4) is easy to modify. That is a wonderful way to program, and I am an advocate of it myself. However, it has an actual name in the computer science literature and it is NOT "stepwise refinement", which means something totally different. You are describing "iterative enhancement". [Basili and Turner. "Iterative Enhancement: a practical technique for software development". IEEE Transactions on Software Engineering. December 1975]. Stepwise refinement is Edgar Dijkstra's programming method, in which each refinement is a "pearl", and all the pearls together form a beautiful string of beads which (a) prove the program correct (b) explain why each refinement was made. The idea is to start with a program which is provably correct but inefficient (or not yet in an actual programming language) and refine it into final form, preserving correctness along the way. (And when Edgar says correctness, he means CORRECTNESS). For what its worth, I think stepwise refinement is only for programs that can fit in a couple of textbook pages, and iterative enhancement is for anything bigger. . -- Spoken: Mark Weiser ARPA: mark@maryland CSNet: mark@umcp-cs UUCP: {seismo,allegra}!umcp-cs!mark
mark@elsie.UUCP (05/04/84)
<> The most complicated program I ever wrote was conceived just before I went on a two week vacation to the north coast of Maine. The nearest terminal was 100 miles away (that I knew of). For two weeks I carefully planned the program and wrote out the code long hand. Raising before dawn, before wife and child, hacking, hacking hacking (no, I'm not divorced, at least not yet). Carefully, I packed pages and pages into by suitcase and could hardly wait till I got home. My daughter's teddy bear is still in the cabin -- a victim of scientia. I may have gotten as far as "main(argc,argv)" before I realized it wouldn't work. And the final product looks nothing like what I planned in the wilds of Maine. It was actually a good experience, and not all wasted time. There is such a thing as over planning. Now I sit down and work out a general plan for the program; make sure I have math right; have an idea of what my input should be and my output should look like; use LOTS of subroutines and VERY FEW globals; and proceed, more or less, by the interitive programming technique. Of course, not all my programming is like this and different people have different techniques. How you proceed also depends on how well you know the language and how good your memory is (mine's bad). There probably is no such thing as the best programming technique, just the best for you personally. -- Mark J. Miller NIH/NCI/DCE/LEC UUCP: decvax!harpo!seismo!rlgvax!cvl!elsie!mark Phone: (301) 496-5688
henry@utzoo.UUCP (Henry Spencer) (05/06/84)
John Crane comments:
If you built a house the way some of you seem to think you should build
a program, we'd be in trouble. The software sevelopment cycle is more
that just a textbook approach. It is a reality in the commercial world
of industrial-strength business software.
The contention that the software development cycle is more than just
a textbook approach is half true, but only half. If one defines "textbook
approach" as "a long and convoluted procedure that is unnecessarily
complex for any real purpose", then clearly the s.d.c. is more than
this. Advance planning is a real necessity.
Unfortunately, the s.d.c. is a "textbook approach" in another, related
but not identical, sense: "something that sounds good in the textbook
but ignores important real-world complications". Specifically, John
says:
You gotta plan ahead. If not how do you know what you are going to
build and how will you know when you've built it?
What we're going to build is "something that satisfies the customers".
We know we've built it when the customers are happy. Since the customers
*INVARIABLY* cannot specify exactly what they want in advance, the idea
of "plan first, then implement" is preposterous. An iterative approach
is inevitable and necessary. Places that claim to follow the s.d.c. but
still produce quality software are always REALLY following an iterative
approach, even if they don't admit it or recognize it.
The classic symptom of rigid adherence to the s.d.c. is that the first
release of the new software package is a piece of garbage, the second
release is starting to be useful, and by the third or fourth release
the thing is actually fit for humans. Note that what we have here is
the iterative approach in disguise, usually at far greater expense (to
both the suppliers and the customers) than if it had been done explicitly.
The prevalence of this approach within the industry is clearly indicated
by the intense reluctance of many organizations to be the first customers
for a new product.
Note that when I say "the customers *INVARIABLY* cannot specify exactly
what they want in advance", I don't mean that they have absolutely no
idea what they want. They generally do have a rough idea, and some
advance planning based on this is wise. But even if they are willing
to write exact specs for everything in advance, using the system will
change their perceptions of how they want the details to work. In the
prevailing s.d.c. approach, the result is major rework jobs before
subsequent releases, rendering obsolete much of the detailed advance
planning done during the "development" phase.
This is not to say that advance planning is futile for major software
packages. On the contrary, it remains very important. But the pretense
that every detail can be spec'ed in advance is silly. Advance planning
time is best spent identifying issues, gathering data, running experiments
with real users, exploring general approaches, and generally doing things
that will be valuable regardless of how the final details come out. There
is nothing wrong with trying to draw up a detailed spec in advance -- it
can be a very useful way to explore the problem -- provided you recognize
that it's unlikely to bear much relation to the final result.
I can hear the system-development-cycle folks lighting their afterburners
now. Just remember, folks: you, too, use the iterative approach. Your
users know that, even if you don't. And they wish you'd admit it.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henryrcd@opus.UUCP (05/06/84)
<> >If you built a house the way some of you seem to think you should build >a program, we'd be in trouble. The software sevelopment cycle is more >that just a textbook approach. It is a reality in the commercial world >of industrial-strength business software. If "a house" were no better defined than some of the problems for which we build software, it wouldn't be built the way it is. "Building a house" is not a problem at the state-of-the-art. -- ...Relax...don't worry...have a homebrew. Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303) 444-5710 x3086
gwyn@brl-vgr.UUCP (05/08/84)
It is the job of the analyst to properly define the problem to be solved, among other things. Perhaps there is simply not enough care being taken with problem definition before program design starts...
gwyn@brl-vgr.UUCP (05/08/84)
My favorite approach to large-scale software system design is DeMarco's Structured Design. It addresses all the issues raised by Henry, mainly through producing a design that is actually AMENABLE to iterative change.
per@erix.UUCP (Per Hedeland) (05/08/84)
>> If you built a house the way some of you seem to think you should build >> a program, we'd be in trouble. Sure. Everyone knows that the right way to build a house is to start with the roof. :-}
henry@utzoo.UUCP (Henry Spencer) (05/08/84)
While I agree with most of Mark Miller's comments (as anyone who saw
my comments on the same issue should know), I have minor reservations
about one thing:
Of course, not all my programming is like this and different people have
different techniques. How you proceed also depends on how well you know the
language and how good your memory is (mine's bad). There probably is no such
thing as the best programming technique, just the best for you personally.
The one aspect of this statement that I'm a bit unhappy about is the
implication (which may not have been there by intent) that it doesn't
really matter what technique you use, so long as it suits you. This
denies the possibility that there may be real differences in effectiveness
between different techniques, over and above individual variation among
the programmers using them.
I've heard too many people say "well, everybody knows that <THING> is
all just a matter of personal taste, so I'll do <THING> any way I damn
well please and you have no right to object". Admitting the importance
of personal factors does not imply admitting that they are the only
important factors.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henrycrane@fortune.UUCP (John Crane) (05/10/84)
If you built a house the way some of you seem to think you should build a program, we'd be in trouble. The software sevelopment cycle is more that just a textbook approach. It is a reality in the commercial world of industrial-strength business software. You gotta plan ahead. If not how do you know what you are going to build and how will you know when you've built it?
cwc@uw-june.UUCP (05/11/84)
/**/ Interesting that a Fortune employee would lecture on how to build software systems, when Fortune has unleashed some of the buggiest, trashiest software the world has ever seen ... Put thine own house in order, Mr. Crane.
henry@utzoo.UUCP (Henry Spencer) (05/11/84)
Doug Gwyn comments, in part:
It is the job of the analyst to properly define the problem to be
solved, among other things. Perhaps there is simply not enough
care being taken with problem definition before program design
starts...
Sorry, Doug, but to my mind the whole role of the "systems analyst" is
part of the "software development cycle" mythology: "of course we can
get it right the first time". Nonsense. The whole idea of "properly
defin[ing] the problem to be solved" implies that the nature of the
problem can be nailed down once and for all beforehand. For the main
reason why this doesn't work, see my previous comments about users'
views of the problem changing once they are exposed to a first-draft
solution.
Mind you, I agree that properly defining the problem to be solved is
important. Lack of effort towards this has led to a number of pieces
of software that "solve" important problems in thoroughly brain-damaged
ways; Berkeley job control comes to mind. [Before I get roasted from
all sides, let me urge job-control enthusiasts to re-read that last
sentence carefully: I'm not saying that job control isn't useful, but
that the importance of solving the problem (orderly interaction with
multiple simultaneous processes) has blinded people to the fact that
Berkeley solved it very poorly.] My point is that the insight needed
to understand problems comes from experimenting with solutions (with,
preferably, real users as the experimentees), not from abstract
contemplation of specifications.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henrygwyn@brl-vgr.ARPA (Doug Gwyn ) (05/14/84)
I suspect we are more in agreement than it appears. By suggesting that a professional software designer get involved in problem definition before the solution is designed, I do not mean ANY sort of irrelevant abstraction. Through good communication with the clients of the software system being designed, and after careful study of their current and expected methods and requirements, one should be able to ITERATIVELY present system designs (data flow diagrams and other documents that the clients can COMPREHEND) and work with the clients to make sure that what is going to be built is in fact what is really needed. Then later, when requirements change (as they will), the original design documents serve as the starting point for discussion of what to change in the system and how it affects the overall operation. The few times I have seen this tried it has been substantially more successful than either older traditional design approaches or hacker design. (MY definition of a hacker is a person whose attempt to solve a problem is to immediately start writing code.)
gwyn@brl-vgr.UUCP (05/14/84)
Relay-Version: version B 2.10.1 6/24/83; site decvax.UUCP Posting-Version: version B 2.10.1 6/24/83; site brl-vgr.ARPA Message-ID: <2003@brl-vgr.ARPA> Date: Mon, 14-May-84 11:16:22 EDT book review Organization: Ballistics Research Lab Lines: 18 I suspect we are more in agreement than it appears. By suggesting that a professional software designer get involved in problem definition before the solution is designed, I do not mean ANY sort of irrelevant abstraction. Through good communication with the clients of the software system being designed, and after careful study of their current and expected methods and requirements, one should be able to ITERATIVELY present system designs (data flow diagrams and other documents that the clients can COMPREHEND) and work with the clients to make sure that what is going to be built is in fact what is really needed. Then later, when requirements change (as they will), the original design documents serve as the starting point for discussion of what to change in the system and how it affects the overall operation. The few times I have seen this tried it has been substantially more successful than either older traditional design approaches or hacker design. (MY definition of a hacker is a person whose attempt to solve a problem is to immediately start writing code.)
robison@eosp1.UUCP (Tobias D. Robison) (05/15/84)
References: Many houses are built the way we write programs. I have listened to examples in painful detail. Consider the typical tract house -- the subcontracter assumes that the contracter has given him nice square corners to work with. As he builds and discovers the survey was not so precise, he starts to make changes, shortening roof trusses and the like, to make the house fit together. A friend of mine who went through this on his first subcontract job died of mortification thinking about the hacks he had made to make the house fit. Then he and his crew went and looked at the rest of the tract and decided they had built the house with the cleanest compromises! Then there is the fellow I know who was visting the site of a major rework to his house when one of the workers came over to the contractor to explain that two parts of flooring were an inch and a half apart in height where they met. The two of them spent ten minutes deciding what to do, and then the worker went on his way. My friend marveled to the contractor that such pains would be taken over such a small misfit. "Oh, he's well-trained,", said the contractor. "In front of the customer, he says 'inches' when he means 'feet'..." - Toby Robison (not Robinson!) allegra!eosp1!robison decvax!ittvax!eosp1!robison princeton!eosp1!robison
gmf@uvacs.UUCP (05/15/84)
Comment on analogy between house-building & programming:
I remember my sheet-metal-worker uncle speaking of the science of
"trimology", concerned with good changes during construction, arising
from necessary departures from specifications. This always concerned
his own changes. I also remember him shaking his head ruefully at
bad changes by others, and muttering "What an abortion!" One of
his favorite bits of humor was an imitation of a carpenter rushing
from one place to another on a building site, holding one arm up high,
and the other out from his side. "Out of my way," the carpenter says,
"I've got a measurement for a door!"
Gordon Fishermwm@ea.UUCP (05/16/84)
#R:cubsvax:-21900:ea:5700004:000:1685
ea!mwm May 15 20:15:00 1984
/***** ea:net.lang.c / utzoo!henry / 1:02 pm May 9, 1984 */
I've heard too many people say "well, everybody knows that <THING> is
all just a matter of personal taste, so I'll do <THING> any way I damn
well please and you have no right to object". Admitting the importance
of personal factors does not imply admitting that they are the only
important factors.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
/* ---------- */
Sorry, Henry, but in programming, the personal factor *is* the dominant
one. You should use whatever method gets the results you need, preferably
minimizing over pain to you.
However, you should consider one thing that nobody seems to have mentioned:
what do you want the code for? Is this an "I need it yesterday" program?
Is it a program to experiment with a language? Maybe to experiment with a
concept? Is it a tool you're going to use and probably modify later?
I use different styles for each of these type of programs (I tend to choose
different languages, too!). If I've got the time, I tend to design the user
interface, then choose the algorithm, choose the language, and code the
program using iterative refinement. I find that this leads to more
maintainable code than any other approach I've tried - including the
Yourdon Overplanning approach.
Of course, one of the times I worked with a team, I used the Yourdon
approach. I had to, as the other team members weren't capable of choosing
an algorithm, and just barely capable of coding it [I got code from team
members that wouldn't compile, for Finagle's sake!]. But this is just a
case of fitting the programming style to the individual.
<mikeron@brl-vgr.ARPA (Ron Natalie <ron>) (05/16/84)
Our favorite was when getting a piece of wood and and asked how long you wanted it, the reply was "A long time, we're building a house out of it." -Ron Thank you, Used to be round.
henry@utzoo.UUCP (Henry Spencer) (05/18/84)
To rephrase my previous statement: just because personal factors are
important does *NOT* mean they are the only important factors. It is
an objectively-verifiable fact that some peoples' preferred styles of
programming turn out code that is poorer, by almost any realistic
measure, than other peoples' preferred styles. It is true that personal
factors are important and programmers should have reasonable freedom
to work in the way that is most effective for them. This does *NOT*
imply that they should have freedom to produce unreadable, unmaintainable
swill rather than clean, high-quality code. And some people will do
exactly that if you let them.
.....You should use whatever method gets the results you need, preferably
minimizing over pain to you....
What about minimizing over pain to the other folks who are going to have
to maintain your code after you're gone, or maximizing over quality? If
I have to go out of my way and undergo pain to meet these objectives, I do.
To my mind this is one of the major differences between professional-quality
work and junk: concern for issues beyond personal convenience.
However, you should consider one thing that nobody seems to have mentioned:
what do you want the code for? Is this an "I need it yesterday" program?
Is it a program to experiment with a language? Maybe to experiment with a
concept? Is it a tool you're going to use and probably modify later?
Experiments and quick kludges are often in a different category from
production software, but I know of a good many kludges that have been
pressed into "production" service because the resources to do them
over again, right, weren't available. A professor of mine once commented
that quick kludges should be thrown out immediately once they have served
their original purpose. Not just marked "do not use", mind you, but
physically destroyed.
...........one of the times I worked with a team......................
.......................the other team members weren't capable of choosing
an algorithm, and just barely capable of coding it [I got code from team
members that wouldn't compile, for Finagle's sake!]. But this is just a
case of fitting the programming style to the individual.
On the contrary, this is a fine example of what I've been saying. I'm
sure some of those people thought their programming was just fine, thank
you, and any differences between you and them were all a matter of personal
style.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henrylaura@utzoo.UUCP (Laura Creighton) (05/19/84)
From Henry Spencer (utzoo!henry) I've heard too many people say "well, everybody knows that <THING> is all just a matter of personal taste, so I'll do <THING> any way I damn well please and you have no right to object". Admitting the importance of personal factors does not imply admitting that they are the only important factors. Reply from (ea!mwm) Sorry, Henry, but in programming, the personal factor *is* the dominant one. You should use whatever method gets the results you need, preferably minimizing over pain to you. Sorry mike. The assumption you are making is that everybody knows how to minimize pain, and that one isn't valid, though most people *think* they know how to minimize pain. Case in point, me: I used to write very ugly looking code (by the Henry Spencer look test, which looks like the Indian Hill C style guide in a great many ways) which passed lint. Now, this is to be preferred over code that doesn't pass lint, or do error checking, but passes the look test, and at the point in time when I was writing it I thought that it was the neatest thing to ever come down the pipe. (Otherwise I would have been doing it differently, you see.) Then, on one day, Henry handed me a copy of the Indian Hill Style Guide (with additions that he made) and let me know that my own code could look any way I liked, but anything installed on the system (utzoo) was going to look like that. Did I think that this was the greatest inconveninece since Income Tax? Yes. Did I think that Henry was an incosiderate, unnreasonable, perhaps even tyranical monster? Yes. Did I think there was a damn thing I could do about it? No. So after a few grumblings (to test and make sure that there was nothing I could do about it) my code looked like the Indian Hill Style sheet. The trick is: Henry was right, I was wrong, it saves me much more pain to write code the way I do now. It actually makes certain sorts of common logical bugs harder to write and easier to find. But I sure didn't know that before -- it is only after fixing miles of code that I now consider ugly that I realise *why* Henry was right. moral: being right is beyond all considerations of personal taste. -- Laura Creighton utzoo!laura "Not to perpetrate cowardice against one's own acts! Not to leave them in the lurch afterward! The bite of conscience is indecent" -- Nietzsche The Twilight of the Idols (maxim 10)
dgary@ecsvax.UUCP (05/21/84)
Where and how can one obtain this Indian Hill Style Guide? Would someone
care to post a summary of what it advises (perhaps some sample code)?
I'm sure I'm not the only one interested.
D Gary Grady Duke U Comp Cttr
Durham, NC 27706
{decvax,ihnp4,akgua}!mcnc!ecsvax!dgarygwyn@brl-vgr.ARPA (Doug Gwyn ) (05/23/84)
Can a copy of the Indian Hill C style guide (or Henry's adaptation of it) be made available to the public (me, mostly! :-) somehow? It may be helpful to lots of C programming projects. I have been using the Plum-Hall style guide, with adaptations. Better than nothing..
mwm@ea.UUCP (05/25/84)
#R:uvacs:-130500:ea:5700007:000:1741 ea!mwm May 25 15:58:00 1984 >To rephrase my previous statement: just because personal factors are >important does *NOT* mean they are the only important factors. It is >an objectively-verifiable fact that some peoples' preferred styles of >programming turn out code that is poorer, by almost any realistic >measure, than other peoples' preferred styles. Yes, but will those other people (the ones with the poorer code) turn out better code if you make them use your style of programming? I write better code using iterative refinement than I do when I try to do the design completely and totally from the ground up. For some reason, the designed code isn't as flexible as the refined code. The following quote from me (which you quoted out of context) sums it up: > .....You should use whatever method gets the results you need, preferably > minimizing over pain to you.... > >What about minimizing over pain to the other folks who are going to have >to maintain your code after you're gone, or maximizing over quality? If In that case, maintainability is part of "what you need". You dropped that when you dropped the context. If the code I wrote was unmaintainable and maintainability was part of what I needed (it almost invariably is), then I obviously chose the wrong method. >Experiments and quick kludges are often in a different category from >production software, but I know of a good many kludges that have been >pressed into "production" service because the resources to do them >over again, right, weren't available. This is all to true. This is why I spend a fair fraction of my time trying to convince the people on rug row to let me spend a little extra time doing it right the first time. It generally saves time (and money) later. <mike
mwm@ea.UUCP (05/26/84)
#R:utzoo:-387800:ea:5700008:000:763 ea!mwm May 25 16:07:00 1984 /***** ea:net.lang.c / utzoo!laura / 6:17 pm May 19, 1984 */ Sorry mike. The assumption you are making is that everybody knows how to minimize pain, and that one isn't valid, though most people *think* they know how to minimize pain. Case in point, me: -- Laura Creighton utzoo!laura /* ---------- */ You're right, I am making an invalid assumption - I'm assuming that people will try new things of their own free will, and use the one that works best. This isn't true - and I blasted well know it. Forcing people to use some style that may or may not work for them is not the solution. Allowing people to go on using whatever hackery they like without giving other things a chance may not work either. I don't have a good solution; does anybody? <mike
liberte@uiucdcs.UUCP (05/29/84)
#R:utzoo:-387800:uiucdcs:27600034:000:913
uiucdcs!liberte May 28 19:11:00 1984
/**** uiucdcs:net.lang.c / mwm@ea / 4:07 pm May 25, 1984 ****/
Forcing people to use some style that may or may not work for them is
not the solution. Allowing people to go on using whatever hackery they
like without giving other things a chance may not work either. I don't
have a good solution; does anybody?
<mike
/* ---------- */
Maybe the best solution is to find a style that does work for most people
and the teach the remaining incorrigibles how to live with it. Most
aspects of style hardly matter all that much and most people will go along
with whatever is choosen, if it is reasonable. But at the same time,
it is important to allow the freedom to explore new styles that just
might be better. The old innovation vs. standards tradeoff.
Daniel LaLiberte (ihnp4!uiucdcs!liberte)
U of Illinois, Urbana-Champaign, Computer Science
{moderation in all things - including moderation}mwm@ea.UUCP (05/30/84)
#R:utzoo:-387800:ea:5700009:000:916
ea!mwm May 30 11:10:00 1984
/***** ea:net.lang.c / uiucdcs!liberte / 7:11 pm May 28, 1984 */
Maybe the best solution is to find a style that does work for most people
and the teach the remaining incorrigibles how to live with it. Most
aspects of style hardly matter all that much and most people will go along
with whatever is choosen, if it is reasonable. But at the same time,
it is important to allow the freedom to explore new styles that just
might be better. The old innovation vs. standards tradeoff.
Daniel LaLiberte (ihnp4!uiucdcs!liberte)
U of Illinois, Urbana-Champaign, Computer Science
{moderation in all things - including moderation}
/* ---------- */
The trick, of course, is getting people to use the "standard"
style/methodology (We switched tracks somewhere in there). Given the
horror stories seen here recently, I suspect that getting people to
*teach* a style/methodology will be the hard part.
<mikejab@uokvax.UUCP (06/01/84)
#R:utzoo:-387800:uokvax:3000027:000:1791
uokvax!jab May 31 22:11:00 1984
uiucdcs!liberte writes:
Maybe the best solution is to find a style that does work for most people
and the teach the remaining incorrigibles how to live with it. Most
aspects of style hardly matter all that much and most people will go along
with whatever is choosen, if it is reasonable. But at the same time,
it is important to allow the freedom to explore new styles that just
might be better. The old innovation vs. standards tradeoff.
/* ---------- */
To which ea!mwm responds:
The trick, of course, is getting people to use the "standard"
style/methodology (We switched tracks somewhere in there). Given the
horror stories seen here recently, I suspect that getting people to
*teach* a style/methodology will be the hard part.
/* ---------- */
Having never been good at keeping quiet (as Mike well knows), I feel
compelled to add my thirty-six cents. (It takes thirty-six cents to
go as far as two cents used to.)
The suggestion of "define a standard and stick to it" is swell, within
some reason. To define a standard that is supposed to work in all situations
is fool-hardy, and gives us such beasts as PL/I, ADA, and eventually, a
"standard operating system" (shades of OS/360). It's almost as if you expect
all mathematicians to write proofs in the same manner, or might I say, to
produce results that conform to certain styles.
(You wouldn't Ives to have had to rewrite his works to sound more like
Mahler, would you?)
Ladies and gentlemen, we aren't talking about chemical engineering here.
The term "computing science" is as contradictory as "political science".
What you really want is a way to review a program (as well as its internal
and external documentation) while it's being designed, coded, and
tested, so that pain is minimized.
Jeff Bowles
Lisle, IL