​Page 16 and 17.   Scanned from my copy and ocred - fair use declared ;-)

Its interesting... FORTRAN still pays my salary ;-) 

It's not banks & insurance company programmers.  It's the physicist, chemists et al running on my supercomputer that still use it.

But as Flon says, I see just as many bad Java, javascript, Python programs. 

==========  Sigplan Notices October 1975 -- pages 16 and part of 17.

On Research in Structured Programming

Lawrence Flon

Department of Computer Science

Carnegie-Mellon University

Pittsburgh, PA 15213

 

The August issue of SIGPLAN Notices contained a rather interesting collection of material.  Not suprisingly, I was struck with some humor at first upon noticing the rather glaring connection between Karp's letter on the one hand and examples of each of his objections on the other. The issue presented, in addition, a lampoon of what has become a somewhat limited, syntax for titles of structured programming articles, followed by yet another member of that very class.  My mirth, unfortunately, did not last long when I began to wonder about whether the whole thing was at all funny.  There has been a forum going on for quite some time in an effort to define structured programming. A number of articles have been written in the style of Dijkstra's original goto letter in an attempt to banish particular language constructs. Counter-articles have been written defending these constructs. I would like to present a statement which has needed presenting for a while.  I like to regard it as an axiom because I firmly believe both in the statement itself and the hopelessness of trying to prove it.

 

Axiom

There does not now, nor will there ever, exist a programming language in which it is the least bit hard to write bad programs.

 

Not only is it possible to misuse goto's, global variables, and conditionals, but the possibilities for misuse of block structure, procedures, macros, pointers, and everything else are endless. Too many textually nested blocks can make an ALGOL program hopelessly unreadable, as can procedures or macros with too many parameters. A set of procedures whose functions are badly partitioned are not only difficult to understand but hard to modify. Syntax macros which do not themselves parse to non-terminal or terminal symbols (e.g. those with unbalanced parentheses or begin-end pairs) are prone to causing hard-to-find syntax errors. Unrestricted pointers (as in PL/I) cause a proclivity of disastrous bugs. These are the seeds for at least four more "considered harmful" papers which I will not write and hope no one else does.

 

I would like to see the S.P. forum re-directed towards a less hopeless task than finding the perfect programming language or formally defining S.P. itself. If we take the definition to be simply the construction of efficient, readable, understandable, modifiable, and verifiable programs, we can then begin to discuss ways to globally reach these goals by educating the people who do the programming.  Since it follows from the axiom that no amount of construct-clipping will make the typical graduate of a "data processing" school even a potentially good programmer, we must find something that will: What can be said to be the proper use of goto's, conditionals, and global variables (and block structure, pointers, etc.)? What are the general guidelines to follow with respect to procedures? How does one go about modularizing a task, anyway?

 

Answering these questions and so many more is what structured programming research should be about. What good is debating the if-then-else construct when half the world is programming in (and will continue to program in) FORTRAN? Let us see articles on the-way-to-do-it-right in any language; articles which programming managers can show their programmers which will improve the quality of software where it is most needed - not in universities and research centers, but in banks and insurance companies.

 

​