Python and COBOL

François Pinard pinard at iro.umontreal.ca
Mon Aug 28 09:15:22 EDT 2000


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.

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

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.

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!

--------------------
[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




More information about the Python-list mailing list