[Python-Dev] an alternative language for CP4E, perhaps?

Gordon McMillan gmcm@hypernet.com
Wed, 6 Oct 1999 12:55:18 -0400


[Guido, on http://www.cobolscript.com/]

> Definitely a joke.  Try
> 
> http://www.cobolscript.com/csfaq.htm#question9
> 
> "One of the other advantages of COBOL is that COBOL file
> processing statements are very simple, with no knowledge of disk
> head positioning required."
> 
> But yes, an incredibly good one!  Worth filling out the form on
> the "contact us page" and seeing what they send back.

While funny, I can virtually guaruntee these people are serious.

It is a common misperception among mainframe/COBOL 
types that C/Unix has *only* character I/O (which does not 
exist in the former environment at all - even terminals are 
block I/O). They regard this as a sign of their vast superiority. 
(And I dearly wish that born-again "Windoze" bashers be 
sentenced to work in this environment - they'll soon realize 
how closely related Windows and Unix are).

I did a number of stints introducing client / server to Big Blue 
shops. (Unix made it's entry *only* because RDBMS's ran on 
them, and all these shops claimed they would dump Unix as 
soon as these products worked right on big iron). I *always* 
had an endless fight with the people who wanted to use 
COBOL instead of C / C++ (on both the Unix boxes and the 
PCs). 

MicroFocus distributed a "white paper" comparing COBOL to 
C that I came to know very, very well. It came in 4 sections:
- the Executive Summary said COBOL was vastly superior in 
all respects
- the White Paper said COBOL was more maintainable 
(translation - you can hire brown-nosing dorks in suits, instead 
of geeks in T-shirts) and often had superior performance
- the Benchmark showed that C smoked COBOL in absolutely 
everything except binary search (a COBOL builtin)
- the Appendix showed that the C code for "binary search" 
was a very badly coded linear search.

But no shop had ever read past the Executive Summary.

And don't forget that there is probably more than one order-of-
magnitude more COBOL source out there than source in any 
other (or maybe all other) language(s). All with no built-in date 
type; and hardly ever using common date routines either 
(calling external programs in COBOL is expensive, and 
awkward, because all variables are global).

Y2K-compliant-by-omission-ly y'rs

- Gordon