From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5faad1722103f6a7 X-Google-Attributes: gid103376,public Path: g2news1.google.com!news1.google.com!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!newsread2.news.pas.earthlink.net.POSTED!01cc3b7c!not-for-mail Reply-To: "Richard Riehle" From: "Richard Riehle" Newsgroups: comp.lang.ada References: Subject: Re: 7E7 Flight Controls Electronics X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-ID: <7_Sxc.8670$uX2.5497@newsread2.news.pas.earthlink.net> Date: Thu, 10 Jun 2004 06:13:23 GMT NNTP-Posting-Host: 66.81.216.253 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.news.pas.earthlink.net 1086848003 66.81.216.253 (Wed, 09 Jun 2004 23:13:23 PDT) NNTP-Posting-Date: Wed, 09 Jun 2004 23:13:23 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: g2news1.google.com comp.lang.ada:1356 Date: 2004-06-10T06:13:23+00:00 List-Id: "Alexander E. Kopilovich" wrote in message news:mailman.85.1086832128.391.comp.lang.ada@ada-france.org... > Richard Riehle wrote: > > > > There are other > > > ways for structured programming (in general sense), and COBOL was very well > > > suited for some of them. For example, if you have ever read "Principles of > > > Program Design" by Jackson, you may recall that JSP was quite happy with > > > COBOL. > > > > Sorry, but COBOL was totally ill-suited to support of well-formed structures > > of any kind prior to ANSI-85. > > COBOL (even 66) was very well suited to support of well-formed *data* > structures. As for control structures, oh yes, it did not provide blocks > (FORTRAN IV also did not provide them - was that FORTRAN stupid also?), and > I think it was right choice, PERFORM statements were better in those > circumstances. The data structures were consistently global, thereby making the notion of localization of data impossible. The fact that FORTRAN also failed to provide adequate scoping rules for conditional constructs does not make the same defect in COBOL any more acceptable. PERFORM was never parameterized and still isn't. In addition, there are somewhat awkward rules for the scope of a PERFORM. We would frequently do one of two things. PERFORM THROUGH where we had a dummy paragraph with an EXIT, or PERFORM by SECTION. In either case, all data was global and that led to no end of maintenance errors. > > > Take the horrible model for an IF statement as an example. > > Hm, what was so horrible there? I have no bad recollections of that IF. I have seen no end of trouble with nested IF statements in COBOL, many of which used the NEXT SENTENCE feature, or worse, a GO TO to escape from nested structure. The cure for this was the END-IF. > > > Those of us who had to use this half-baked conditional > > formation recall how easily it led to programming mistakes. > > Well, some people like to count mistakes, while others (including me) prefer > to consider real counsequences of those mistakes (on a production line). My > experience says that these two accounts lead to rather different results. The need for end of scope for control structures was recognized early in the design of most other programming languages. It came late to COBOL. > > > > The fact that Jackson "was quite happy with COBOL" is simply an indication > > of the widespread stupidity regarding the shortcomings of the earlier forms > > of the language. > > Is it a new fashion of political correctness to declare previous techniques > and tools that didn't become current mainstream - simply stupid? > > > No intelligent contemporary programmer would want to > > return to hideous mess of tangled code so typical of pre-ANSI-85. > > Well, I can't say for intelligent people (they are so mystically clever, they > so easily differentiate and recognize so many puzzling abbreviations -:), > but in my humble opinion, a hideos mess of tangled systems and products and > concepts and standards isn't much better, and leaves even less hope for > keeping things under control. > > > Structures, in the Dijkstra sense, was far more than "GO TO Considered > > Harmful." More important, though, are the elementary control structures > > of Jacopini and Bohm which, when properly formed, will include scope > > terminators such as ANSI-85, END-PERFORM, END-READ, END-IF, > > etc, without which the resulting code is usually a mess. > > Well, I prefer another "definition of scope" - that of H. Mills - a module > that fits into a page, that is, a scope is an amount of code which directly > fits into programmer's view. Well, that is also a rather inadequate definition of a module. I recall people using that definition where they would take a red pencil and simply start a new module every fifty-six lines. A module, properly defined, will adhere to the rules of cohesion and coupling, or follow the advice of Parnas, or Meyer. Certainly modules should be short, whenever that is appropriate, but arbitrary page length or screen length criteria will create more problems than it will solve. > > > I have written and > > maintained code written by others, in COBOL 68, 74, and 85. I would > > never want to do anything in 68 or 74 again. > > Well, if you prefer to deal with magnificient templates, XSSL, SOAP, ADO, > DRM, Java 1.m.n etc., etc. (at the same time, of course) then it is your taste, > Not sure why you make this comparison since it has nothing to do with COBOL. I am simply arguing that early versions of COBOL fell short of what was needed for creating well structured, maintainable code that provided support for good modularity (e.g., cohesion and coupling) and modern COBOL is much improved. > > In my view, COBOL, prior to the ANSI-85 standard was not "very well > > suited" for writing maintainable, dependable, well-structured code, > > Surely. It was just well suited to make programs which ran on production > lines - certainly with much pain, failures etc., but there was no other way > that time, in first place because of incomplete and often self-contradictory > specifications/requirements and unreliable hardware. I have written and maintained so much COBOL over my career that I have no difficulty remembering the problems with it. I have also used contemporary COBOL and it is lightyears ahead of the earlier versions of the language. It is interesting to me to realize that, when I was using those earlier versions of COBOL, I did not understand just how crippled the language was because I learned all the workarounds. > > > Since the ANSI-85 standard, COBOL has become one of the most interesting > > languages around. It has corrected the silliness of the earlier standards, > > There was no silliness to correct. COBOL just was adapted to changed > circumstances - more powerful and reliable hardware, more challenging tasks, > more educated/experienced programmers, and better understanding of the > processes by analysts. > Sorry. But when I compare old-time COBOL with contemporary COBOL, I see such vast improvements that the older versions look to me now like primitive cave drawings. This has nothing to do with improved hardware, improved programmers, or better processes. It has everything to do with a greatly enhanced language definition where I can more effectively create parameterized modules with call by value or reference, can create control structures that have well-defined scope, and can avoid excessive use of global data. Richard Riehle