Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun!pitstop!sundc!seismo!uunet!jarthur!wilkins
From: wilkins@jarthur.Claremont.EDU (Mark Wilkins)
Newsgroups: comp.unix.wizards
Subject: Re: Structured Programming
Message-ID: <234@jarthur.Claremont.EDU>
Date: 17 Feb 89 11:24:28 GMT
References: <18291@adm.BRL.MIL> <9574@smoke.BRL.MIL> <226@algor2.UUCP> <5576@bsu-cs.UUCP> <26369@wlbr.EATON.COM> <89071@sun.uucp>
Reply-To: wilkins@jarthur.UUCP (Mark Wilkins)
Organization: Harvey Mudd College, Claremont, CA
Lines: 55

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