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++.


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

Reply via email to