Python and COBOL

[jurgen.defurne at philips.com]

pinard at iro.umontreal.ca@SMTP at python.org on 28/08/2000 16:33:45
Sent by:	python-list-admin at python.org
To:	python-list at python.org@SMTP
cc:	 
Subject:	Python and COBOL
Classification:	Restricted
Hi, people.  A few quick thoughts about Python and COBOL, while awakening!

A few languages have legibility as one of their primary goals, and before
Python, I think that only COBOL was so found about it.  Without being
aware of one another, these languages are brothers from this blood line.

>You would not say that if you had spent four years maintaining and
>debugging ten year old COBOL code from programmers which have
>disappeared. One thing no-one ever tought COBOL programmers where
>the principles of structured programming (as from Dijkstra).

One fun thing is that COBOL is _also_ found on indentation, rather than
braces and such nesting devices[1].  Oh, of course, indentation of COBOL
is much more primitive and limited than in Python, it cannot be deep,
but the idea of COBOL is trying to avoid deep thinking, anyway. :-) As a
proof of shallow thinking, COBOL does not even have `lambda's[2].

>Indentation rules in COBOL where invented when programs where still loaded
>from cards and have no real semantic meaning.

COBOL does not abuse of operator and other mathematical symbols.  If I
remember well, those dangerous things require to be introduced by a special
COMPUTE keywoard.  There is a PEP suggesting the introduction of a whole
flurry of new operators, I'm sad to say it really goes against COBOL spirit.

About new operators, there is some COBOL wisdom that could benefit Python,
especially in these times where augmented assignment is in the fashion.
Consider these two Python statements:

    total_municipal_tax = total_municipal_tax + citizen_contribution
    total_municipal_tax += citizen_contribution

The first being natural and widespread, the second being rather new and
slightly controversial.  COBOL teaches us that Python got it all backwards.
The second form, and only that one, should have made its way in Python right
from the start, and this is the first form that now should be considered
as a possible extension and subject to the hottest debates.  The normal,
natural, easy flowing COBOL statement for the above Python code is:

    ADD CITIZEN-CONTRIBUTION TO TOTAL-MUNICIPAL-TAX.

Simple, clear, straightforward.  Just compare the above with the convoluted:

    ADD CITIZEN-CONTRIBUTION TO TOTAL-MUNICIPAL-TAX GIVING TOTAL-MUNICIPAL-TAX.

> or 
> COMPUTE TOTAL-MUNICIPAL-TAX = TOTAL-MUNICIPAL-TAX + CITIZEN-CONTRIBUTION

It really looks like some awkward extension to the purity of COBOL,
that does not fit that well in the language.  It probably was added late
in the COBOL definition, to peace down a riot of lazy programmers, who
were reluctant to the simple effort of moving variables in and out of
accumulators for computations.  This compromise was a big loss in clarity!

Also consider this recent PEP about random spreading of doc-strings between
sentences, a bit everywhere: nothing more than simple comments, after all,
that Python can later introspect.  Some "IDENTIFICATION DIVISION." added
to the Python language would put some good order and discipline into this
wilderness, wouldn't it? :-) Python should take a closer look at COBOL!

> Aaargh! Spare me the red tape :-). If there is one thing my experience has
> taught me, then it is that such syntactic division of source code are
> horrible for writing easily maintable code.

> To summarize and put my answers in perspective, I do like COBOL, and it
> does excel for business programs. But it is a language from the dawn of
> ages, and I do not think that it should be used as an example for
> more recent programming languages.

Jurgen

--------------------
[1] COBOL never had `TAB' versus spaces debates like for Python, that
I've been aware of.  Maybe it is just that `TAB' was not invented yet...

[2] It looks like a cheap shot: while it is a mere, friendly tease to Guido!

--
François Pinard   http://www.iro.umontreal.ca/~pinard

--
http://www.python.org/mailman/listinfo/python-list