home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / alt / cobol / 339 < prev    next >
Encoding:
Internet Message Format  |  1992-07-28  |  6.7 KB

  1. Path: sparky!uunet!cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!ames!bionet!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!sobeco!alawrenc
  2. From: alawrenc@sobeco.com (a.lawrence)
  3. Newsgroups: alt.cobol
  4. Subject: Re: The inevitable question
  5. Message-ID: <1992Jul29.012052.2193@sobeco.com>
  6. Date: 29 Jul 92 01:20:52 GMT
  7. References: <1992Jul25.060022.9237@uwm.edu> <1992Jul25.154243.19607@cs.unca.edu> <EMERY.92Jul27111003@Dr_No.mitre.org> <Bs2r39.Hot@snuffy.wa.atk.com>
  8. Distribution: usa
  9. Organization: Sobeco Ernst & Young
  10. Lines: 128
  11.  
  12. WAIT A MINUTE!  Doesn't everyone involved in this discussion realize that
  13. they are comparing apples and oranges.  Just for the record.  I have been
  14. programming professionally in assembler and machine languages since 1967,
  15. COBOL since 1970, RPG-II, III & 400 since 1976, BASIC since 1981, C and PASCAL
  16. since 1984, not to mention the dozen or so other languages I used for various
  17. project.
  18.  
  19. COBOL is going to survive and continue to be used for business application
  20. simple because of its the best language for that environment.  After all 
  21. it is the COmon Business Oriented Language.  It is also the most portable of
  22. all languages I have ever encountered.  Probably because, thanks to Grace 
  23. Hopper, is was the first to be standardized.
  24.  
  25. For writing systems software for a cross platform environment, C is the best
  26. I have met to date.  I expect it to expand the almost monopoly is now has
  27. even more in the future.
  28.  
  29. For simple multilevel reports and will manipulation RPG (or some IV GL) will
  30. win every time.
  31.  
  32. etc. etc. etc.
  33.  
  34. My choice of a language for any development project depends first on what
  35. the system is (business, graphics, database, etc) and secondly what is
  36. supported on the platform or platforms the application is supposed to
  37. run on.
  38.  
  39. In <Bs2r39.Hot@snuffy.wa.atk.com> mluders@snuffy.wa.atk.com (Matthew_Luders) writes:
  40.  
  41. >emery@Dr_No.mitre.org (David Emery) writes:
  42.  
  43. >>The hallmark of COBOL systems is maintenance.  
  44.  
  45. Sorry, the hallmark of all *production* systems is maintenance.  To the
  46. order of 80% maintenance to 20% new development.  Whether the application
  47. is an operating system, accounts payable, a windowing environment,
  48. general ledger or a word processor.  The language the system is written
  49. only impacts the time necessary to develop the application.  Maintability
  50. is impacted by the quality of the documentation and how well the original
  51. design was structured and the programs written.  Again, irregardless of
  52. language.
  53.  
  54. >... I find that a well-written C program is
  55. >easier to maintain than a poorly-written COBOL program.  
  56.  
  57. Any well written program is easier to maintain that a poor written program.
  58. Again, the particular languages involved have very little to do with it.
  59. Seems kinda obvious to me.
  60.  
  61. >Why are the programs in such bad shape?  Three possible reasons spring to 
  62. >mind:
  63.  
  64. >(1) Many of them were written 15-20 years, before the importance or principles
  65. >    of stuctured coding and design were well known and accepted.
  66.  
  67. Structured programming has been with us 1972.  Before that we used a 
  68. technique called modular programming which was the same think defined
  69. less formally.  Before that smart programmers designed and wrote their
  70. code that way because it worked and was maintainable.
  71.  
  72. >(2) The people that wrote these programs had backgrounds in accounting or
  73. >    business management, not computer science or electrical engineering.
  74. >    Actually, this seems to be true even today.  
  75.  
  76. The computer "scientists" and engineers I have met who actually program 
  77. are the some worst *production* programmers I have ever met.  So are
  78. the accountants and managers.  Mostly because these people work alone
  79. on relatively small projects.  Give me professional programmers, who
  80. know about standards, walkthoughts, documentation and coding efficienty.
  81. In reality bad code is the result of bad system management.  The 
  82. project manager is the one who decides whether or not to adher to
  83. programming standards, not the programmer.  In the past I've sent
  84. more than one program back for a major rewrite because the programmer
  85. was sloppy and I've fired programmers who thought standards were for
  86. others.  Again the language involved has no importance.
  87.  
  88. >    In fact, this is probably why
  89. >    COBOL is under the alt heading instead of comp.lang with the other
  90. >    languages.  I wonder how many COBOL programmers even know of the existence
  91. >    of the Internet?
  92.  
  93. Very, very few.  Most programmers, not just COBOL, go to work in the
  94. morning, work at their assigned tasks throughout the day, and go home
  95. at the end of regular business hours.  alt.cobol vs comp.lang.cobol is
  96. not a function of the attitudes or COBOL programmers but rather who
  97. the subscribers to Internet are.
  98.  
  99. >(3) COBOL programmers (like programmers everywhere) are often under pressure
  100. >    to make changes to code quickly.  This can lead to "quick-and dirty"
  101. >    patches that are not well-integrated with the basic design of the program.
  102. >    Over time, this leads to code that is a convoluted mess of patches on top
  103. >    of patches on top of patches, ad nauseum.
  104.  
  105. Again, this applies to any programming environment.  Its a management
  106. problem, not a language or programmer problem.
  107.  
  108. >There is a bright side.  For all the criticism that COBOL gets from software
  109. >engineers, it is possible to write structured, readable, maintainable code with
  110. >it.  
  111.  
  112. It is possible to write structured, readable maintainable code in any language,
  113. possible exception APL.
  114.  
  115. >Its record and field handling capabilities make it well-suited for
  116. >creating reports, which is probably what it's used for the most.  But the fact
  117. >that a program is written in COBOL certainly does *not* guarantee (or even
  118. >improve the chances) that it's maintainable.  In fact, you could argue that
  119. >there are elements of COBOL that tend to make programs written in it *less*
  120. >maintainable (e.g. the lack of local variables).  Some of these problems were
  121. >addressed with the release of COBOL-85 (e.g. the addition of the end-if and
  122. >evaluate statements), but I don't know how widely COBOL-85 is being used yet.
  123.  
  124. Actually most COBOL code is involved in processing files.  One of COBOL's
  125. strong points is that sequential, random and indexed file access methods
  126. are built into the language standard.  Another advantage is decimal
  127. precision.  PIC S99999V99 COMP is just that in COBOL, guantanteed.
  128. Just as COMP is guaranteed to be the most efficient arithmetic format
  129. on the platform, and I know of one computer where that is *not*
  130. binary.
  131.  
  132. >I'd be curious to hear other people's opinions on these topics.
  133.  
  134. So you have.
  135. -- 
  136. On a clear disk you can seek forever.
  137. -------------------------------------------------------------------------
  138. Andrew Lawrence, Informaticien Conseil           |  alawrenc@sobeco.com
  139. 3605 St-Urbain, #1605                            |  uunet!sobeco!alawrenc
  140.