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: Fri, 11 Jun 2004 06:03:51 +0400 (MSD) Organization: Cuivre, Argent, Or Message-ID: References: <7_Sxc.8670$uX2.5497@newsread2.news.pas.earthlink.net> 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 1086919872 45202 212.85.156.195 (11 Jun 2004 02:11:12 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Fri, 11 Jun 2004 02:11:12 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: In-Reply-To: <7_Sxc.8670$uX2.5497@newsread2.news.pas.earthlink.net>; from Richard Riehle at Thu, 10 Jun 2004 06:13:23 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:1380 Date: 2004-06-11T06:03:51+04:00 Richard Riehle wrote: > > 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. First, not generally impossible - you had subroutines for that. Second, it was just good thing that that localization was not too easy - it would constantly confuse programmers and severely increase number of nasty mistakes. Please don't confuse abstraction skills of typical COBOL programmer (that time) with those of typical Algol-60 programmer (those of average FORTRAN IV programmer - "typical" was't applicable to FORTRANers - were somewhere in between). > 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. Again, it wasn't a defect - it was adequate for that reality. Well, if there were scopes in COBOL-66, I could use them, but probably I wouldn't - because it would be impossible to explain those "tricks" to almost all programmers around me, and I had no intention to maintain my production programs myself infinitely. And the same was often true for FORTRAN (but not so often as for COBOL). > PERFORM was never parameterized and still isn't. Well, begin-end blocks are non-paramerized also. If you needed parameters you had subroutines for that. > 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. Well, it is true that those rules required either training or experience for their good application, but I don't call then awkward for that - because their relative proximity to the language used by "analysts" (who composed problem specifications/requirements) that time was more important than any abstract clarity. > In either case, all data was global and that led to no end of maintenance > errors. In fact, the was a good opportunity to provide a kind of localization in COBOL-66: you could put you data into a structure even if that data does not participate in I/O and need not be structured for the algorithm. The data remains global, but nevertheless it becomes "localized" in some sense (well, if you wish an exact, abstract definition of this "localization" then here it is: the variables become localized in the space of identifiers). > 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. Nested IFs are evil (well, dangerous -:) anyway, and there can't be any cure. For me, END-IFs (in all languages that employ them, including Ada) bring little help when IFs are nested - the visibility decreases drastically and the code becomes error-prone. > 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. Well, that *need* came late to COBOL, not the *recognition* of that need. I hope you agree that 1) COBOL designers most probably were aware of Algol (58/60) and 2) there were no significant syntactic or semantic problems with introducing begin-end blocks into COBOL. > > > 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 pointed at the current programming "biblioware" for commercial data processing. I meant that those problems with early COBOL, which you mentioned, aren't bigger or more painful than current problems (associated with programming languages of various kinds) within the same application domain. > 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. Well, you were lucky in that you had opportunity to see and use COBOL-85. I had no such opportunity. Even COBOL-74 was far remote thing for me - I could only see some distorted (translated) documentation. Possibly this difference plays its role - you saw more advanced COBOL and therefore the previous one seems too bad for you, while I saw that old COBOL only, and remember that it was good enough. > 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. Excellent. Now realize that as I did not see later versions of COBOL, the time stopped for me at that point, regarding COBOL. And I'm quite sure that I was not stupid that time, and I definitely knew Algol-60 (and even tried to learn Algol-68 -:) . So if we have a disagreement on this issue, it seems more about of role of time in our opinions than about COBOL-66 itself. > > 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. But those people who created cave drawings probable weren't stupid. Moreover, I venture to think that if one of now-famous painters somehow appeared in those caves between those tribesmen then, perhaps, he would decide to create similar drawings - just because they could be understood by people around him. > 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. Programming language is a language - it must be understood by people who use it. If only 10% of users can properly understand sufficient part of the language then the language will fail. Therefore education of programmers and level of understanding of problems by analysts - matters for a programming language. Alexander Kopilovich aek@vib.usr.pu.ru Saint-Petersburg Russia