vfm6066@dsacg3.UUCP (John A. Ebersold) (02/09/89)
Structured programming is currently being discussed in comp.unix.wizards. To summarize the various comments (with apologies to the original posters): Structured programming is a way for mediocre programmers to produce good code; a way to prevent code from deteriorating into a tangled mess, etc. Also, some programming environments or languages are good certain things but not good at others. Forcing a language to do something it doesn't "naturally" do may be more trouble that it worth. Pointers are not natural in Fortran - simulating them causes much work. Other languages that have the notion of procedures without parameters - simulating the parameters via global variables may impose some structure on the code - but at what cost? I did this once but it was NOT fun but I thought it was worth the trouble. These types of things are what Frederick Brooks calls the accidents of software engineering. In an article in IEEE Computer Magazine last year Brooks write of the search for the magic bullet that will slay the software development beast. He concludes that while many things can be done no "magic bullet" exists. No software engineering, program generation environment, etc currently exists that removes the need for humans to make requirements/design and design/coding trade when building software. We don't have a mind reader that figures out what people REALLY want and writes the code for us. I pose some questions? Some people think a good design is more important than the language of implementation. A good design is essential but the language is important also. Can a good programmer write a good program in a bad language? Yes. Can a bad programmer write a bad program in a good language? Yes. Can a bad programmer screw up a good design? Yes. Real case study (I was the project leader): In a large software system, a kludge cannot be avoided (the real world is often that way). Do you isolate the kludge in one or two modules that really don't (strictly speaking) need to know about the kludge or how to handle it? The alternative is to put the knowledge of the kludge in the twenty or so modules other modules. I choose the former. Stated another way: A well placed kludge can be considered elegant. If these things have been discussed before, sorry. If not, what are your thoughts? -- John A. Ebersold, Unify Corporation @ Defense System Automation Center osu-cis!dsacg1!dsacg3!vfm6066 Columbus, Ohio 1-614-238-5923 The trouble with the world is that the stupid are cocksure AV 850-5923 and the intelligent are full of doubt - Bertrand Russell.
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
wgd@bbt.UUCP (dixon) (02/16/89)
In article <1328@dsacg3.UUCP> vfm6066@dsacg3.UUCP (John A. Ebersold) writes: > >Structured programming is currently being discussed in comp.unix.wizards. > >To summarize the various comments (with apologies to the original posters): > etc. >Some people think a good design is more important than the language of >implementation. A good design is essential but the language is important >also. > >Can a good programmer write a good program in a bad language? Yes. > >Can a bad programmer write a bad program in a good language? Yes. > >Can a bad programmer screw up a good design? Yes. > >Stated another way: A well placed kludge can be considered elegant. > >If not, what are your thoughts? > I agree wholeheartedly. At the risk of sounding like *those* people in comp.unix.wizards (intolerant and with a "hacker" mentality), how can people in this day and age, with any amount of education, really feel the way some of them have expressed. My company would never knowingly hire someone with those attitudes. Yes, we feel that there's no substitute for good design and structured techniques; after all, this IS and engineering discipline (at least some of us are trying to take that approach). I only hope that the "hackers" that are afraid of "leaping" into the future and using modern SW engineering techniques are not an example of the calibre of people prevalent on the net (or in the industry). Walter Dixon Broadband Technologies, Inc. wgd@bbt.uucp {...}mcnc!rti!bbt!wgd