mchinni@ardec.arpa (Michael J. Chinni, SMCAR-CCS-E) (02/03/89)
> > What REALLY happens when a group of structured programmers tries to > > develop a large program? Usually they argue about how the program should > > be indented, what the comments should be like, how the subroutines > > should be nested, ... etc. > I wish I could give you some "war stories" about unstructured vs. structured > programming, . . . One "war story" I can relate is the following. As an R&D computer facility we serve as what you might call a "job shop" for engineers at our site. One time an engineer came to us with a several thousand line program that he wanted us to put on our system (i.e. get it working). After accepting the job we found to our horror the the code was TOTALLY unstructured. It had NO comments; had no conection what-so-ever between variable names and their use; and frequently used system-specific code without mentioning that it was system-specific OR what the code did; and the entire program was replete with gotos. It took us about 2 man-months of work to get that monstrosity working. However, if the code had been "structured" it would have taken us no more that 2 man-weeks. The moral of the story is that had the code been structured we would have saved 1.5 man-months of work. And since we charge by time spent on a job, it would have saved much money. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Michael J. Chinni US Army Armament Research, Development, and Engineering Center User to skeleton sitting at cobweb () Picatinny Arsenal, New Jersey and dust covered terminal and desk () ARPA: mchinni@ardec.arpa "System been down long?" () UUCP: ...!uunet!ardec.arpa!mchinni /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
mike@ames.arc.nasa.gov (Mike Smithwick) (02/03/89)
In article <18291@adm.BRL.MIL> mchinni@ardec.arpa (Michael J. Chinni, SMCAR-CCS-E) writes: > >> > What REALLY happens when a group of structured programmers tries to >> > develop a large program? [delete. . .] >if the code had been "structured" it would have taken us no more that 2 >man-weeks. > This reminds me of a joke I just made up : Q: How many structured programmers does it take to screw in a light bulb? A: 10 - 1 to screw in the light bulb, but 9 to make sure he does it right the first time. Sorry. -- *** mike (cerbral GURU, insert M&Ms to restart) smithwick*** "The great thing about standards is that there are so many of them!" [disclaimer : nope, I don't work for NASA, I take full blame for my ideas]
gwyn@smoke.BRL.MIL (Doug Gwyn ) (02/03/89)
In article <18291@adm.BRL.MIL> mchinni@ardec.arpa (Michael J. Chinni, SMCAR-CCS-E) writes: >After accepting the job we found to our horror the the code was >TOTALLY unstructured. Usually in a case like that I'd suggest the effort be spent in developing a replacement, from scratch, instead of in trying to make the existing mess "work". It probably wasn't doing the right thing anyway.
jeffrey@algor2.UUCP (Jeffrey Kegler) (02/04/89)
(Michael J. Chinni, SMCAR-CCS-E) writes: >After accepting the job we found to our horror the the code was >TOTALLY unstructured. This structured controversy has me strongly agreeing with both sides. Code which can only be read by the programmer who wrote it for some weeks after he wrote it gives all us hackers a bad name (and, unfortunately, we do have a bad name). I think the structured versus unstructured controversy contains two controversies. The first is a important debate that will help us refine good programming standards. The second really is about the question of hacker "professionalism". Having once taught Structured Programming for Yourdon, Inc., I have frequently been asked to assist in advice about "structuring" code. This is on the borderline between hacking and management consulting--basically not a good place to be. Programming standards and code review committees attract all the jerks trying to angle their way from the ranks of us hackers into the Vice-Presidency of the Division. While these characters are deceiving themselves into believing they have a career path, they cause everyone else a good deal of trouble. (Has a programmer ever become a VP in a Fortune 500 company? Not that I know of, and if he did I bet it was not by being a star on the code review committee). "Professionalism" in our business is a double-edged term. When hackers use it they mean things like writing code according to standards agreed on by those of our fellows whose competence we respect. The word is often perverted to justify whatever rinky-dink rule has emanated from the top. While wearing blue jeans at work and never cleaning your coffee cup is not behavior I endorse, it does not reflect on the "professionalism" of the people doing it. In fact, in the area of professionalism, I have taken many a cue from people whose coffee cups I would only touch with rubber gloves. Professionalism would mean we hackers set our own standards of ethics and competence, and membership. That is what the professions (lawyers, MD's, CPA's) do. Professionalism in that sense would get you in big trouble in most organizations I know of--faster than blue jeans or a dirty coffee cup. I believe in Structured Programming in the sense that a programmer should write code to be read by others according to standards accepted by the best of the programmers. What goes on in this news group is part of that process (which process I fear this long posting may be delaying). But Structured Programming is often the buzzword for an attempt to routinize and deskill programming work to reinforce the control of hierarchy over the programming process--separate from and sometimes different from, improving quality. In terms of quality, innovation procedes from the bottom, and, alas, often from desks with dirty coffee cups. -- Jeffrey Kegler, President, Algorists, uunet!jeffrey@algor2.UU.NET 1788 Wainwright DR, Reston VA 22090, 703-471-1378
dhesi@bsu-cs.UUCP (Rahul Dhesi) (02/08/89)
Simplifying outrageously, we state:
The primary purpose of structured programming is to allow mediocre
programmers to create good software.
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
ARPA: bsu-cs!dhesi@iuvax.cs.indiana.edumh@wlbr.EATON.COM (Mike Hoegeman) (02/09/89)
In article <5576@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >Simplifying outrageously, we state: > > The primary purpose of structured programming is to allow mediocre > programmers to create good software. I always got the impression it allowed mediocre programmers to create mediocre software , the real value of it (at least in my experience) is that it kept any program from degenerating into a bag 'o worms during it's life cycle.
cm@yarra.UUCP (Charles Meo) (02/09/89)
In article <5576@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > The primary purpose of structured programming is to allow mediocre > programmers to create good software. And there is a corollary: A desirable byproduct of structured programming is to prevent good programmers from writing mediocre software. :-> chuck
lm@snafu.Sun.COM (Larry McVoy) (02/09/89)
In article <5576@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >Simplifying outrageously, we state: > > The primary purpose of structured programming is to allow mediocre > programmers to create good software. I'm jumping into this late but ... I've worked in those so called ``structured programming languages'' that are designed to let mediocre programmers do acceptable work. Examples that come to mind are Ada, Pascal, Modula, Modula II. My experience is that 1) No prgramming lanaguage in existance prevents bad code or bugs. I will predict that no prgramming language ever will. Prove me wrong and I'll switch tomorrow. 2) What these langauges do in reality is hide you from your environment, making it extremely difficult to get the job done. Examples: pascal I/O, modula command line args, etc. The fundemental problem with the approach of these languages is that they try and anticpate your needs. The result is that you are fine where the designer really did anticpate your needs but up the creek when you do something ``weird.'' Larry McVoy, Lachman Associates. ...!sun!lm or lm@sun.com
rsp@pbhyf.PacBell.COM (Steve Price) (02/11/89)
In article <226@algor2.UUCP> jeffrey@algor2.UUCP (Jeffrey Kegler) writes: [stuff omitted] >Programming standards and code >review committees attract all the jerks trying to angle their way from the >ranks of us hackers into the Vice-Presidency of the Division. While these >characters are deceiving themselves into believing they have a career path, >they cause everyone else a good deal of trouble. Unfortunately, this rings loudly of truth. >"Professionalism" in our business is a double-edged term. When hackers use it >they mean things like writing code according to standards agreed on by those >of our fellows whose competence we respect. The word is often perverted to >justify whatever rinky-dink rule has emanated from the top. And the "top" usually doesn't know anything about programming structured or un. But the push for code standards and professionalism is usually an honest effort by management to do good. In my corporate experiences, the upper management announces the need for quality and professional standards, but relies on the data processing professionals to set the standards for the various languages, operating system uses, etc. Since management is usually uninformed about this, they have no other choice. So when standards get abused and used as political clubs, it is not simply a case of "management" abusing DP professionals. As Jeff implies, there are traitors among us. >Professionalism would mean we hackers set our own standards of ethics and >competence, and membership. Sounds good to me. How do we do it? >I believe in Structured Programming in the sense that a programmer should >write code to be read by others according to standards accepted by the best of >the programmers. There is something of a logical circle here, since some pre-existing standards are implied. How else do we know who "the best of the programmers" are? Determining how to make this judgement might help us see what standards we really do use and whether they should be upgraded or scrapped. > Structured Programming >is often the buzzword for an attempt to routinize and deskill programming work >to reinforce the control of hierarchy over the programming process--separate >from and sometimes different from, improving quality. Correct. This is consistent with the needs of a hierarchical political and economic system (which we hackers serve). Deskilling workers at every level, starting at the factory floor and moving up to the middle-level managerial class, is the great force now at work in American business. The skill and talents of a few at the top are to control the desired outputs of those unskilled workers (or better yet, automated nonhuman systems) below. We programmers are the shock troops and engineering corp in this great war of deskilling. The plan is for us to automate ourselves last. (Some people think Utopia will result from this. Others don't.) >In terms of quality, >innovation procedes from the bottom, and, alas, often from desks with dirty >coffee cups. Yes and that is what keeps the managerial hierarchy from becoming Almighty. I wash my cup once a week, whether it needs.... Steve Price pacbell!pbhyf!rsp (415)823-1951 =========================================================================== The opinions expressed are not necessarily those of the expressor. ===========================================================================
campbell@redsox.UUCP (Larry Campbell) (02/12/89)
[I've redirected followups to comp.software-eng, since this has nothing to do with unix per se.] In article <4677@pbhyf.PacBell.COM> rsp@pbhyf.PacBell.COM (Steve Price) writes: }In article <226@algor2.UUCP> jeffrey@algor2.UUCP (Jeffrey Kegler) writes: }> Structured Programming }>is often the buzzword for an attempt to routinize and deskill programming work }>to reinforce the control of hierarchy over the programming process--separate }>from and sometimes different from, improving quality. }Correct. This is consistent with the needs of a hierarchical political and }economic system (which we hackers serve). Deskilling workers at every level, }starting at the factory floor and moving up to the middle-level managerial }class, is the great force now at work in American business. The skill }and talents of a few at the top are to control the desired outputs of those }unskilled workers (or better yet, automated nonhuman systems) below. The main reason for the desire to deskill programming is that skill is so scarce. America is raising generations of idiots. It is difficult to find Americans who can write their own native language fluently, let alone write good code in one or more computer languages. Skill is scarce but the work must be done; one solution is to deskill the work so as to enlarge the pool of potential workers. Another solution -- my preferred one -- would be to abolish television and get really serious about education and intellect. But that's not likely to happen any time soon, and even if it did, the improvements would come over several decades, while structured development can yield results in a year or two. One last point -- another goal of structured development (a more encompassing term than structured programming) which has not yet been mentioned here is to improve our ability to predict how long a project will take, and thus how much it will cost. I believe this is at least as important a goal as that of deskilling software development. -- Larry Campbell The Boston Software Works, Inc. campbell@bsw.com 120 Fulton Street wjh12!redsox!campbell Boston, MA 02146
wilkins@jarthur.Claremont.EDU (Mark Wilkins) (02/17/89)
In article <89071@sun.uucp> lm@sun.UUCP (Larry McVoy) writes: >In article <5576@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >>Simplifying outrageously, we state: >> >> The primary purpose of structured programming is to allow mediocre >> programmers to create good software. > >I'm jumping into this late but ... > >I've worked in those so called ``structured programming languages'' ... [stuff deleted] BUT: The purpose of structured programming is neither to make mediocre programmers good or to make low-level manipulation difficult (as I have heard some people state.) The purpose of structured programming is to allow large, complex projects to become manageable and to reduce the likelihood of creating code which is buggy due to side-effects. The languages you mention, of which Pascal and Ada are most familiar to me, were not intended for low-level work. Pascal was only intended as a teaching tool. Ada has capabilites for low-level fiddling but the specification for the language is still in a state of flux anyway. The question I pose is this: If you were going to write an I/O and processing intensive real-time simulation in C, perhaps 500,000 lines of code, would you honestly throw aside any conception of modularity? Or would you develop a hierarchy of tasks to be performed and keep them well within a structured programming model except for a few, distinct and clearly marked routines for I/O and signal processing? If you choose the second, you can not only spread the work among many people and minimize the necessity for their interaction, you can minimize the effort necessary to keep side-effect bugs from creeping into all of your low-level routines. If you choose the first, sooner or later your programmers will get confused and start having to decipher each others' code to do their own work. And when that happens, I guarantee that your project will take too much time and be over budget, which is what we all want to avoid. >The fundemental problem with the approach of these languages is that they >try and anticpate your needs. The result is that you are fine where the >designer really did anticpate your needs but up the creek when you do >something ``weird.'' True, if one is doing a real world project in one of the languages you mentioned, one will be hard pressed to make do. But there is no reason you can't write efficient, structured code in a low-level language and then call those routines from a higher-level language. And there is no reason to assume that using a low-level language for efficiency implies throwing away a clear conception of modularity. IN SHORT: If you don't need structured programming because your program is really small, then great. But very little is that easy to program in an unstructured way. Ever try writing 10,000 line program that works in Applesoft BASIC? THAT will make you a believer. -- Mark Wilkins wilkins@jarthur.claremont.edu
bill@twwells.uucp (T. William Wells) (02/19/89)
My two cents:
Structured programming is the art of making the physical
structure of the program mirror the logical structure of the
problem to be solved.
This entails:
1) Knowing the logical structure of the problem to be solved.
2) Arranging the program to reflect that.
This helps to provide:
1) A more correct program.
The program is designed to do the right thing.
2) A less buggy program.
The program does what it is designed to do.
3) A more easily understood program.
Since form mirrors function, knowing either makes
understanding the other easier. Also, there is the
synergy of considering both why and how
simultaneously.
4) A more easily maintained program.
A change in the function of the program translates
directly into a change in the program since the
program structure reflects its function.
These are common misconceptions:
1) Structured programming requires a HLL.
Oddly enough, it is easier to write structured
programs in assembler than BASIC. Though you can do
it in BASIC. Masochisticly.
2) Structured programming means rigidly following one style.
Structured programming means following the structure
of your problem. Since problem types are unbounded
(consider Goedel's theorem), so are the styles that
will be appropriate to solving them.
3) Structured programming makes better programmers.
Cart before horse time: structured programming is a
tool. Just as a better hammer makes properly driving a
nail easier, so does structured programming make
writing a good program easier; however, a hammer
won't turn an all-thumbs into a carpenter, nor will
structured programming turn a routineer into a
competent programmer. The all time worst program I've
seen was in 8085 assembler, but the number two spot
goes to a properly structured (according to the
mechanicalist school of structured programming)
Modula II program.
---
Bill
{ uunet!proxftl | novavax } !twwells!billmirk@warwick.UUCP (Mike Taylor) (02/25/89)
In article <234@jarthur.UUCP> wilkins@jarthur.UUCP (Mark Wilkins) writes: > > IN SHORT: If you don't need structured programming because your > program is really small, then great. But very little is that easy to > program in an unstructured way. Ever try writing 10,000 line program > that works in Applesoft BASIC? THAT will make you a believer. Hmmm ... A few years ago BASIC was all I had, structured programming was a closed book to me, and yet I seemed to get by without any of the sorts of problems that Structured Programming is supposed to alleviate. I will admit I never wrote a 10000-line BASIC program, but I certainly got into the 1000s. I think that you get by with what you have, there is a danger (maybe) of people being "spoiled" by having environments that do it all for them. I dunno. It doesn't make much sense put like that, and when I look back on it, I can't *believe* I ever wrote anything of substance in a language that doesn't even have local variables. But looking at it objectively, I never had as much difficulty debugging my huge, sprawling unstructured BASIC programs as I do now debugging my huge, sprawling, but structured, C programs. (Only 1/2 a :-) Disclaimer: I love C! I *know* it's better than BASIC. OK. ______________________________________________________________________________ Mike Taylor - {Christ,M{athemat,us}ic}ian ... Email to: mirk@uk.ac.warwick.cs "Can't say my name's well-known, you don't see my face in Rolling Stone (yet)" ------------------------------------------------------------------------------
btcx@vax5.CIT.CORNELL.EDU (02/25/89)
In article <234@jarthur.Claremont.EDU> wilkins@jarthur.UUCP (Mark Wilkins) writes: >In article <89071@sun.uucp> lm@sun.UUCP (Larry McVoy) writes: ... >>I've worked in those so called ``structured programming languages'' ... "so-called" - Amen! ... > > IN SHORT: If you don't need structured programming because your >program is really small, then great. But very little is that easy to >program in an unstructured way. Ever try writing 10,000 line program that >works in Applesoft BASIC? THAT will make you a believer. No prob IF you "structure" it. Difficult, but possible. My Soap box follows - press n or be bored! Theorem: There's no such thing as a structured programming language, only structured programmers. Does anybody remember that the original bias against goto's came from a paper that associated PROGRAMMERs' use of the goto inversely with their ability i.e. it's the programmers' use, NOT the language's posession, of the goto that is the problem. You can write a crummy program in ANY language. Fancy constructs like dowhile, repeat, break, etc are nice, but they are ONLY cosmetic, as indeed all HLL's are. Witness the past discussion in .lang.c where they were arguing about loops in ("portable" -ha!) c and saying you should count some loops up and some loops down for performance because of differences in compilers and instruction sets on different cpu types. And how many times have we been burned because we forgot whether a loop construct will always execute once or not; and how many compiler bugs were based on misunderstandings like that? Mistakes of that sort are few when you do the loop counting in the HLL and use goto's. That said, I am no great fan of goto, or antagonist of all those handy constructs, I just like to say that The fault, dear Brutus, lies not in our programming languages, but in ourselves! brian carcich
gwyn@smoke.BRL.MIL (Doug Gwyn ) (02/25/89)
In article <18012@vax5.CIT.CORNELL.EDU> btcx@vax5.cit.cornell.edu (PUT YOUR NAME HERE) writes: >And how many times have we been burned because we forgot whether a >loop construct will always execute once or not; and how many compiler >bugs were based on misunderstandings like that? Mistakes of that sort >are few when you do the loop counting in the HLL and use goto's. Anyone who doesn't familiarize himself with his tools can get hurt using them. Software engineers are almost universally in agreement that proper control constructs reduce error, and chief among these constructs is while...do...done in various guises.
chris@mimsy.UUCP (Chris Torek) (02/27/89)
[discussion redirected to comp.misc] >In article <234@jarthur.UUCP> wilkins@jarthur.UUCP (Mark Wilkins) writes: >>... Ever try writing 10,000 line program that works in Applesoft BASIC? >>THAT will make you a believer. In article <1348@ubu.warwick.UUCP> mirk@warwick.UUCP (Mike Taylor) writes: >Hmmm ... A few years ago BASIC was all I had, structured programming >was a closed book to me, and yet I seemed to get by without any of the >sorts of problems that Structured Programming is supposed to alleviate. >I will admit I never wrote a 10000-line BASIC program, but I certainly >got into the 1000s .... But looking at it objectively, I never had as >much difficulty debugging my huge, sprawling unstructured BASIC programs >as I do now debugging my huge, sprawling, but structured, C programs. >(Only 1/2 a :-) When it comes to debugging, BASIC has two big advantages over C: First, it is interpreted (usually). You can use `printf-style' debugging quite freely. C systems usually force you to recompile everything with a special `debug' flag, and run under a special debugger, and even then the debugger often does not match the language, so that you cannot print or set variables properly. Second, BASIC is a much simpler language: there are not as many ways for you to hang yourself. The rope is simply too short. Despite the near-necessities missing from most BASICs---local variables, for instance---it is possible to write large programs in them. I once (in 1979 or 1980, I suppose) wrote a Z80 assembler in TRS-80 Model I Level II BASIC. The line count was certainly greater than 1000. The system I used was to keep a large sheet of paper covered with entry points and variable use. In fact, I still have that paper (curious what one finds in the desk drawers under the H19): ... 10200 - Line input & parsing ... 11200 - O1$: "BC" RP <- 0, "DE" RP <- 1, "HL" RP <- 2, "AF" RP <- 3, "IX" 4, "IY" 5, else -1 ... 12100 - Label table search, FI = `subscr' for label (*not* mod 25) ... 12400 - write 1 disk record, C bytes ... (many of these comments now seem unutterably cryptic; but some of it comes back to me now). The input, output, and labels were all stored on floppy disk. This was necessary as the assembler itself used most of the available RAM (48 kB, minus the sizes of the various patches needed to use lowercase, fix the keyboard, and so forth---about 35 or 40 k left, I think). The assembler was a conventional two-pass job, and ran at the blinding speed of 15 lines per minute. Per pass. I used to start it assembling, then go eat lunch or something. I did add a `buzz' assembler directive that made use of the cassette recorder relay to alert me when the assembly was done. But somehow I never got around to rewriting the assembler in assembly.... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
orn@rsp.is (Orn E. Hansen) (03/01/89)
In article <1348@ubu.warwick.UUCP>, mirk@warwick.UUCP (Mike Taylor) writes: > In article <234@jarthur.UUCP> wilkins@jarthur.UUCP (Mark Wilkins) writes: > > > > IN SHORT: If you don't need structured programming because your > > program is really small, then great. But very little is that easy to > > program in an unstructured way. Ever try writing 10,000 line program > > that works in Applesoft BASIC? THAT will make you a believer. > > Hmmm ... A few years ago BASIC was all I had, structured programming > was a closed book to me, and yet I seemed to get by without any of the > sorts of problems that Structured Programming is supposed to alleviate. > I will admit I never wrote a 10000-line BASIC program, but I certainly > got into the 1000s. I think that you get by with what you have, there > is a danger (maybe) of people being "spoiled" by having environments > that do it all for them. > I agree with Mike, but in those days it was very common to include a lot more then a single instruction on a single line. You don't do that in a C program (or any other structured language). But have you ever wondered how long your BASIC programs would have been Mike, if you'd put a single instruction on a single line??????? Maybe I'm wrong, but I think programs and programmers have become sluggier by time. A program doing "wery little" needs at least 256K to run!!! Pheew! Orn Hanen @ National Hospital of Iceland, Computer Department. Internet: orn@rsp.is UUCP: ..!mcvax!hafro!krafla!rispa2!orn
cmf@cisunx.UUCP (Carl M. Fongheiser) (03/02/89)
In article <112@.rsp.is> orn@rsp.is (Orn E. Hansen) writes: >Maybe I'm wrong, but I think programs and programmers have become >sluggier by time. A program doing "wery little" needs at least 256K >to run!!! Pheew! Well, to be absolutely fair to the programs and programmers, one has to realize that the contributions from the system libraries have grown considerably as well, especially in the vendor system releases, like SunOS or Ultrix. For example, anytime I do a getpwent() or gethostent() (or anything which calls those), I have to pull in a whole lot of Yellow Pages and RPC code. I had any number of programs grow by 30K or so, just for being recompiled under Ultrix 2.0 instead of Ultrix 1.2. This isn't necessarily bad (though I'm no Yellow Pages fanatic); it really is doing a lot more. Try getting rid of it if you don't need it, though! Carl Fongheiser University of Pittsburgh ...!pitt!cisunx!cmf cmf@unix.cis.pittsburgh.edu
jc@minya.UUCP (John Chambers) (03/03/89)
> >And how many times have we been burned because we forgot whether a > >loop construct will always execute once or not; and how many compiler > >bugs were based on misunderstandings like that? Mistakes of that sort > >are few when you do the loop counting in the HLL and use goto's. > > Anyone who doesn't familiarize himself with his tools can get hurt > using them. Software engineers are almost universally in agreement > that proper control constructs reduce error, and chief among these > constructs is while...do...done in various guises. True, but it's still easy enough to get burned. And at the risk of being guilty of the sin of preaching to the choir, I'd like to remark that, while I have been burned by this in many languages, so far I've never had such problems in C. C is one of the few languages that does loops right, i.e., iterates exactly when the terminating test is true. Most languages' standards/specs/whatever allow the compiler writer to handle the null case in a way that makes the non-null case the fastest; C compiler writers aren't allowed such trickiness. It's a real help to know that the code will loop just as many times as I tell it, no more, and no less. It's also a big help to know that the "control variable(s)" are guaranteed to keep their final value, and that the compiler can't play efficiency games that work differently on different systems. I like the idea of a program that does exactly what I say, even (especially) when there's a "better" way. Now if we could only do something about the occasional (about once a month in my case) wasted time due to typing "=" when "==" was intended. Oh, well, nobody ever claimed that C was perfect {;-} I could also make some nasty remarks about the leeway in the order of evaluation in C, but I'll leave that as an exercise for the reader... -- John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393) [Any errors in the above are due to failures in the logic of the keyboard, not in the fingers that did the typing.]
gp@ist.CO.UK (GP Saxena) (03/04/89)
Summary: Structured Programming is an attitude/approach. Structured programming is a misnomer. I think what we should be talking about is a Structured Approach to Programming. One can write structured programs in any language, including microprogram languages, assembly langauages. Therefore, it does not make sense to talk of "structured programming languages" and the like. Just as a bad carpenter blames his tools, so a badly structured program can be written in a high level language like Ada (haven't we all seen one!). The fact that structured programming is more of a matter of approach can be seen by the way lots of people use languages like C++. They write vanilla C programs in C++, without sitting back and planning the program out first, and try to use the C++ facilities in a more "object oriented" fashion. What I am trying to say, is that again, the approach to using an object oriented language is very different from that used for a language without the OOP features.( This does not mean that you cannot do OOP in C, only C++ is more suitable for it.) --------------------------------------------------------------- The opinions expressed above are, mine and mine alone, mined. GP Saxena -------------------------------------------------------------
Kemp@dockmaster.arpa (03/06/89)
> From: John Chambers <jc@minya.uucp> > Most languages' standards/specs/whatever allow the compiler writer to > handle the null case in a way that makes the non-null case the fastest; > C compiler writers aren't allowed such trickiness. It's a real help to > know that the code will loop just as many times as I tell it, no more, > and no less. It's also a big help to know that the "control variable(s)" > are guaranteed to keep their final value, and that the compiler can't > play efficiency games that work differently on different systems. I > like the idea of a program that does exactly what I say, even (especially) > when there's a "better" way. The fortran-77 standard doesn't allow "trickiness" that affects the number of times a loop will be executed based on the whims of the compiler writer. The exit condition is checked at the beginning of the loop to allow zero or more executions; and the control variable is guaranteed to retain it's current value (if you break out of the loop) or the value that caused the test to fail (if the loop terminates normally). What could be more deterministic or explicit? (Of course fortran-66 one-trip loops were a botch, but 1966 was a LONG time ago). Disclaimer: I write mostly in C, I only use fortran for signal processing. Honest. --------------------- btw, what is the address for submissions to the unix-wizards digest? I believe that if this is sent to unix-wizards@sem.brl.mil, it will go out as its own little message. Dave Kemp
orn@rsp.is (Orn E. Hansen) (03/14/89)
In article <16325@cisunx.UUCP>, cmf@cisunx.UUCP (Carl M. Fongheiser) writes: > > Well, to be absolutely fair to the programs and programmers, one has to > realize that the contributions from the system libraries have grown > considerably as well, especially in the vendor system releases, like > SunOS or Ultrix. > That's true. Libraries have grown a great deal as they are covering a bigger material, and systems do differ so a different code is needed for a different system, which in turn gives bigger (or smaller) code. But sometimes we tend to use a library, that's actually doing a lot more than is needed. As a result, the program is slow and uses a lot more memory than it otherwise would. Later, as the pressure on the program increases, users start to complain about the slowness of the program. Now, as in most cases I know off, we get a bigger machine to run the program. I personally don't agree on that. We should re-analyse to see if we can cover the problem soft first. Otherwise, we'll propably end by using a MOON-SIZED-MACHINE to run it. This is what I referred to as 'sluggy' (Saving the penny for the dime). Orn Hansen System Analyst at | Internet: orn@rsp.is National Hospital of Iceland, | UUCP: +!mcvax!hafro!krafla!rispa2!orn Computer Department. | ------------------------------+-------------------------------------------