Re: [Python-Dev] an alternative language for CP4E, perhaps?
The whole site sort-of makes me wonder whether this is one big elaborate joke. But if it is somebody put an incredible amount of work in it. The funny thing is that the idea of using Cobol for web-programming _did_ initially strike me as a neat idea: because of the elaborate data descriptions and report generation facilities you could conceivably use all that info to automatically generate all the input forms and such. But they have apparently done no such thing... The timesheet example is, uhm, interesting. 1500 lines of code, with many parameters hardcoded in the source. I'd be surprised if it would take more than 100 lines in Python, with a lot more customizability too. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
Ach! Wish I was there!
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. --Guido van Rossum (home page: http://www.python.org/~guido/)
[Guido, on http://www.cobolscript.com/]
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
Now I'm confused... I typed in the comment box: Very good joke. ROFL. Where do you guys find the time and energy to do this! :-) and got this back: Mr. van Rossum Glad you took the time out of your busy schedule to berate us. We must be doing something right! ;) Chuck Shereda Deskware, Inc. www.deskware.com www.cobolscript.com --Guido van Rossum (home page: http://www.python.org/~guido/)
On Wed, 6 Oct 1999, Guido van Rossum wrote:
Apparently deskware is a known, bona fide organization. Considering the massive number of cobol programmers around, and despite how cumbersome the prospect is (and with the advantage of factoring in the things gordon said), i guess someone thinks there's leverage in making cobol a scripting language. I think it's not so different than making interpreted versions of C (but i'm not very C friendly). Ken klm@digicool.com
Ach! Wish I was there!
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. --Guido van Rossum (home page: http://www.python.org/~guido/)
[Guido, on http://www.cobolscript.com/]
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
Now I'm confused... I typed in the comment box: Very good joke. ROFL. Where do you guys find the time and energy to do this! :-) and got this back: Mr. van Rossum Glad you took the time out of your busy schedule to berate us. We must be doing something right! ;) Chuck Shereda Deskware, Inc. www.deskware.com www.cobolscript.com --Guido van Rossum (home page: http://www.python.org/~guido/)
On Wed, 6 Oct 1999, Guido van Rossum wrote:
Apparently deskware is a known, bona fide organization. Considering the massive number of cobol programmers around, and despite how cumbersome the prospect is (and with the advantage of factoring in the things gordon said), i guess someone thinks there's leverage in making cobol a scripting language. I think it's not so different than making interpreted versions of C (but i'm not very C friendly). Ken klm@digicool.com
participants (4)
-
Gordon McMillan -
Guido van Rossum -
Jack Jansen -
klm