[TUHS] Comments on "C"

[clemc@ccc.com (Clem Cole)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4490 bytes --]

On Thu, Sep 1, 2016 at 5:17 AM, Norman Wilson <norman at oclsc.org> wrote:

> Flon's Axiom comes from a short note On Research
> in Structured Programming, published in SIGPLAN
> Notices in October 1975.  It's just as true today.
>
​+1  (a few times) - His axiom is also one of my favorites.   Flon was
brilliant and funny.​


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



​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160901/60d35c3d/attachment.html>