[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