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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable 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!news2.google.com!proxad.net!freenix!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: "Alexander E. Kopilovich" Newsgroups: comp.lang.ada Subject: Re: 7E7 Flight Controls Electronics Date: Thu, 10 Jun 2004 05:41:45 +0400 (MSD) Organization: Cuivre, Argent, Or Message-ID: References: NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: melchior.cuivre.fr.eu.org 1086832128 59308 212.85.156.195 (10 Jun 2004 01:48:48 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Thu, 10 Jun 2004 01:48:48 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: In-Reply-To: ; from Richard Riehle at Wed, 09 Jun 2004 06:23:25 GMT X-Mailer: Mail/@ [v2.44 MSDOS] X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Gateway to the comp.lang.ada Usenet newsgroup" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: g2news1.google.com comp.lang.ada:1342 Date: 2004-06-10T05:41:45+04:00 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. > 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. > 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. And anyway, all constructs easily lead to programming mistakes, without exceptions. Take for example those begin-end blocks. The following 3-step scenario I encountered many times: Step 1. Use the same identifier inside and outside of the block: declare i; i := ...; ... begin declare i; i := ...; ... ... := i; end; ... ... =:= i; Step 2. Reuse that variable inside the block: declare i; i := ...; ... begin declare i; i := ...; ... ... := i; ... i := ...; ... ... := i; end; ... ... =:= i; Step 3. Remove the first use of that variable inside the block along with its inner declaration (just forgetting about the second use of it): declare i; i := ...; ... begin ... i := ...; ... ... := i; end; ... ... =:= i; The final result is obvious, I hope. > 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. > 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, > 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. > 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. Alexander Kopilovich aek@vib.usr.pu.ru Saint-Petersburg Russia