Dijkstra wrote his missive around 1968. Knuth made a meal of it and after reading his paper which was published 5 years later, it was too hard a read.
Around the same time Michael Jackson was distilling this information and produced his structured programming book "Principles of Program Design". I still have a copy and generally will approach program design using the same tried and tested techniques. At IBM in 1978 we had an advocate for the same methods, Tony Droar. Unfortunately, a lot of this good work seemed to miss a lot of organisations. Some places I worked in the 80's wouldn't allow a sort to make a program easier to write. Jackson explained go to was essential, particularly when performing validation....posit.....admit....quit. I've seen a Jackson structure design turned into a flowchart and the structure is lost. Flowcharts encouraged the use of GO TO. On Mon, Jun 8, 2020 at 4:45 PM David Crayford <dcrayf...@gmail.com> wrote: > On 2020-06-07 10:48 PM, Paul Gilmartin wrote: > >> I consider the out of line PERFORM to be far more dangerous. I have a > similar issue with REXX; it does not have lexical scope, and you can fall > into a procedure. > >> > > A noteworthy 1976 paper (behind a paywall): > > Software malpractice — a distasteful experience† > > https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380060303 > > > > ... describes the pitfall set by a (too) clever programmer's relying on > > optimization by falling into procedures. > > > > † In the day, I read it free in the University library. > > I'm sure that paper is an interesting read from a historical > perspective. It's referenced in Code Complete along with another > reference to Frank Rubin's letter to the ACM (March 1987) > in which he asserts that goto-less programming has cost business > "hundreds of millions of dollars". > > The original context of the "goto considered harmful" is lost on the > younger generation, as at the time there were large swaths of developers > who were trained before structured programming took off. > There are a handful of use cases where "goto" makes the code simpler, > cleaner and more readable. In these cases, you /should/ use goto > statements. A good programmer can recognize these cases and use goto > appropriately. > > > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
