[Default] On 8 Jun 2020 01:55:52 -0700, in bit.listserv.ibm-main dcrayf...@gmail.com (David Crayford) wrote:
>I learned JSP back in the early 90's. It was popular in the UK (Jackson >was British) and most large mainframe companies adopted it. It was good. >There was even tooling that >could create code from charts. > >Dijkstra's paper is one of the most controversial CS papers ever >written. It was written before structured programming took off and >programming languages >like FORTRAN and COBOL were not well structured at the time. >Unfortunately, people drank the kool-aid and a whole generation of >programmers were brain-washed by dogma >that goto is inherently evil. I see code all the time that eschews goto >for error handling and the alternative is never better. In fact, it's >always crap! It's either deeply nested if-logic or extra status >flag checks. For languages that support try/finally, use groups, RAII >etc the problem doesn't exist but that's certainly not the case from >almost all mainstream languages that run on z/OS >other than Java and C++. > My avoidance of GO TO in COBOL is based on my understanding of IBM COBOL compiler optimization and not a computer theology that says all GO TO is bad. In the case of error clean up and blow up paragraphs, from a clarity point of view I would prefer to GO TO them but I believe this could adversely affect optimization. While I can't speak for other languages, VS COBOL 2.4 and later optimizations Enterprise COBOL 5.2 do PERFORM optimization where Paragraphs that can only be PERFORMed will cause a simplified generation of code for the related PERFORMs. In some cases the Paragraph is moved inline to replace the PERFORM statement which can bee a performance advantage for caching. I don't believe that PERFORM ... THRU statements are eligible for this optimization. I have avoided GO TO statements and even used PERFORM to execute the error abort Paragraphs accepting the warning message to make certain the optimization could take place. This is because in COBOL the same paragraph could be reached by PERFORM x, PERFORM x THRU exit-x1, PERFORM x THRU exit-x2 and GO TO x. The addition of EXIT PARAGRAPH and EXIT SECTION have eliminated most of the reasons for use of GO TO in COBOL. I would be interested in any corrections to my understanding by those responsible for the COBOL compiler. Clark Morris > >On 2020-06-08 4:28 PM, Wayne Bickerdike wrote: >> 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 >>> >> > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
