From - Thu Feb 04 18:17:02 1999 Path: news.flash.net!nntp.flash.net!dca1-hub1.news.digex.net!digex!feed1.news.rcn.net!rcn!wn4feed!worldnet.att.net!135.173.83.225!attworldnet!newsadm From: "James Giles" Newsgroups: comp.lang.fortran Subject: Re: Fortran Myths & Disinformation Wanted Date: 4 Feb 1999 18:58:29 GMT Organization: AT&T WorldNet Services Lines: 235 Message-ID: <79cqkl$b4t@bgtnsc02.worldnet.att.net> References: <36B9B8FF.4E34BF22@mixcom.com> NNTP-Posting-Host: 12.74.2.65 X-Newsreader: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Xref: news.flash.net comp.lang.fortran:68776 Craig T. Dedo wrote in message <36B9B8FF.4E34BF22@mixcom.com>... >Dear Readers: > I am developing a list of popular myths and disinformation about the Fortran >programming language that are widely circulated in the programming community. >All of the following are beliefs I have heard personally. So far, I have >these: > 1. Fortran is 3 way IF statements and one-trip DO loops. > 2. Fortran encourages unstructured code and spaghetti-style control flow. > 3. Fortran can't do Windows. > 4. Fortran is unportable. If you really want portability, you should write >your program in C. > 5. Fortran is only for scientific and engineering applications. > 6. The only real fortran is FORTRAN 77 (or, FORTRAN 66). > 7. Fortran can't call system routines. > 8. You can't do character string operations easily in Fortran. > 9. Only Microsoft makes a PC-based Fortran compiler of any importance. > 10. Fortran is a dead language. No one uses it any more to write important >applications. I have been preparing such a list, with responses, but it's large and I haven't finished it. My list is called ECPK (Every C Progammer Knows). You left out a few (and here are some of my responses to some of those you mention). There are more (that I just haven't got to). Maybe someone else will fill-in where I've omitted. ------------------------------------------------------------------ ECPK that a major Venus probe (or some spacecraft) blew up because of a Fortran DO I=1.4 style error. Not true. A space probe was lost because of a single character error. But it was an error in transcribing a formula. Fortran wasn't involved (or even used). Most other programming languages have contexts which allow single character errors as well. C has many. The Fortran one expressed here is unlikely since most loops vary from 1 to a variable! ECPK (Every C Programmer Knows) that Fortran programs can only use uppercase. Well, this has not been true for many years. Prior to F90, the standard only mentioned one case, but as a practical matter most implementations have allowed both upper- and lowercase whenever both were available on the hardware/system the compiler was resident on. Fortran does have the specific advantage that its implementations are not case sensitive. Even before F90 (which specifically says that case is not significant if both cases are allowed), no Fortran I'm aware of made was case sensitive. (G77 now has an compiler option to allow case-sensitivity.) Case sensitive languages are generally more error prone. And, in the old days, many systems didn't have character sets that included both cases. I never saw a C implementation on the old CDC 60-bit machines, possibly because its 6-bit character set didn't have both cases. Most Fortran programs could be moved to such systems with little difficulty. ECPK that Fortran statements must begin in column seven. Not before and not after. This has never been true. You could always indent beyond column seven if you chose. I have worked in places where we weren't allowed to do so. On one Air Force contract, the captain decided that no extraneous spaces, blank lines, empty comments, or anything else were to be allowed. We also had to declare variables in alphabetical order - regardless of their mutual dependencies - and line up declarations in columns. All these rules were intended to make everyone's style consistent and increase legibility of "other people's code". The fact that all the rules were actually the worst decisions you could make didn't seem to phase him. This is not a valid reason to criticize the language, this guy would probably have done the same thing in any programming language. A related problem (that really is a language defect) that C programmers *don't* usually know is that Fortran (77 and before) silently ignores everything after column 71. This was fine when everyone used keypunches that could be set to automatically skip to the next card at that point. But with the advent of glass terminals and text editors is was a constant source of subtle errors. Now why is it that C programmers are never really aware of the *real* defects of Fortran? ECPK that Fortran's variables are limited to, at most, six characters. This is true as far as it goes. Of course, F90 allows variables, externals, essentially all names to be 31 characters in length (and permits underscores). Prior to F90, many implementations allowed more than six characters: most allowed eight, some allowed more than that. This made your code less portable (you'd have to systematically change all your long variables to shorter names). But, people used to expect rather more difficult work to port their codes than just renaming a few variables anyway. Anyone writing a code for a Cray (in those days) expected that it would probably never run on any other machine - too many machine specific features. This is not to defend short variable name limits - it should have been changed in F77 - but it's not as bad as all that. Especially considering: At the same time Fortran's standard limited variables to six characters, C had no standard yet at all and K&R (first edition) was considered the authority. Yet, K&R stated that only the first eight characters of an identifier were significant - even though identifiers of any length were allowed! This is an appallingly bad language design. Identifiers that were intended to be different, but which were the same in the first eight characters were silently treated as the same. Identifiers for external symbols were usually significant to fewer than eight characters (often six, since the linkers were designed for Fortran). This was much worse than the enforced Fortran limit because it wasn't enforced. It was not eliminated until the C standard (which was about the same time as f90). ECPK that you can't write structured programs in Fortran. This and the next two points are strongly related. Indeed, this comes in several dozen guises, so just three is already a simplification. Structured Programming was a phrase first popularized by E. W. Dijkstra (and others) in the late 60's and early 70's. It referred to a style of writing programs that most now generally call "iterative refinement". This is a technique that can be applied to any program and any programming language. Perhaps the most widely read introduction to this concept is the book "Structured Programming" [1]. I have had at least one C++ fanatic claim that iterative refinement was now obsolete and that object oriented design principles have superceeded it. This is not correct. Iterative refinement is the basic underlying principle of object oriented design. Indeed, the first widespread introduction most people had to Simula (the first OOP) was in the book "Structured Programming" mentioned above. In fact, if you know how it's done internally, you can do object oriented programming in any language (if you couldn't, it would be impossible to compile it to machine-code on non-OO hardware). What an OOP language does is make several of the activities considerably easier. Perhaps because Dijkstra was the principal proponent of structured programming and also was among the earliest to comment on the negative effects of GOTOs [2], the phrase "structured programming" has acquired the incorrect definition of "GOTO-less programming". This leads to the following point. ECPK that using GOTOs is an inherently bad thing that automatically makes spaghetti out of your program. In his article [3], Knuth addresses this issue point-blank. It isn't specifically a Fortran vs. C issue, but it often arises in that context. I think that [2] and [3] are the only references to the GOTO-less programming debate anyone should ever have to read. They pretty much say it all, except: In terms of programmer productivity, GOTOs are not *inherently* bad. They can be abused quite easily, and that's the real problem. But, there are things known from direct experiments which are worse. The "Hare" experiments in the 70's and related studies demonstrated that judicious use of GOTOs was actually better for programmer productivity than block structured languages using "begin..end" scoping rules for grouping statements for control. See articles [4], [5], [6], and [7]. The "Hare" experiments deserve to be famous (or infamous), but are instead known only by a few. The old-guard language design elite preferred the "elegant" solution of making begin - end tokens make a sequence of statements into a single one (syntactically) and then having control constructs only apply to single statements. The "Hare" experiments (and other papers and studies) demonstrated this was not a good idea. Hence the relatively unknown status of the work (the "gurus" didn't like the result). The authors of the "Hare" experiments clearly preferred the begin-end design themselves and repeatedly concluded that it was simpler psychologically than GOTOs (as you will see if you read the referenced articles). Still, some of the evidence tells against begin-end style. In [1], the test subjects in the second study made about 1.5 times as many errors (92 vs. 60, combining both syntax and logic errors) using Begin-end style vs. the users of a GOTO (JUMP) mechanism. Further, the errors were more persistent (1.5 times as long to correct them) using Begin-end style vs. GOTOs. Why were the users of Begin-end style less successful than the users of GOTOs in these simple tests? Because the 'begin' and 'end' are anonymous - any 'begin' can match any 'end' and it's not hard to lose track is a deeply nested program. GOTOs are the reverse, each one names the unique label to which it refers. Each label does not (necessarily) correspond to a unique GOTO, but you've at least got the specific identification one-way. The third mechanism tried in the "Hare" experiments was a nested, block structured syntax in which the statements were *not* delimited by the anonymous begin-end pairs, but were clearly identified. This mechanism was so clearly superior to either begin-end style constructs or GOTOs no language designed from scratch since then has used begin-end syntax. Several have been designed to be backward compatible to other begin-end style languages though. C is worse than even most other begin-end style languages in that it spells the delimiters with the slight "visibility challenging" characters {and}. This further aggravates the anonymity problem with legibility problems. F90 uses a variant on the other block nesting mechanism, DOs end with END DOs and never with END IFs; etc.. And F90 permits blocks to be named in order to further remove anonymity from the delimiters. (See, I did manage to make this directly relevant to C vs. Fortran.) ECPK that Fortran forces you to use GOTOs all the time. This is a fair characterization of F66. You could do counted iterations without GOTOs (you still needed a label) with the DO statement, but other than that you needed GOTOs. It's not quite as fair with respect to F77. At least F77 has block IFs. Still, to do CASE or WHILE constructs you need a GOTOs. It is certainly not a fair characterization of F90 or beyond. Even so, I heard people claim that Fortran had no block IF as recently as 1993! That's hardly a well researched position to take. ECPK that Fortran has no character manipulation capabilities. Since Fortran 77, Fortran has had better capabilities in this respect than C. It has, built into the language, the ability to extract substrings and concatenate. The whole standard C collection of character manipulation functions can be duplicated in Fortran (those that aren't already present) in an afternoon. Fortran is actually a pretty good language for text manipulation. ---------------------------------------------------------------------------------- [1] Structured Programming; Dijkstra, Dahl, and Hoare; Academic Press, 1972. [2] GOTO Statement Considered Harmful; Dijkstra; Communications of the ACM; March 1968; pp. 147-148. (widely reprinted) [3] Structured Programming with GOTO Statements; Knuth; Computing Surveys; December 1974; pp. 261-301. (widely reprinted) [4] Jumping to Some Purpose; Arblaster, Sime, Green; The Computer Journal; Vol. 22, No. 2, pp. 105-109. [5] Scope Marking in Computer conditionals - a Psychological Evaluation; Arblaster, Green, Guest; Int. Journal of Man-Machine Studies (1977) 9, 107-118. [6] "GOTO Considered Harmful" Considered Harmful; Communications of the ACM; March 1987, pp. 195-196. (Also see letters to Communications for the rest of that year for rebuttals and/or agreements.) [7] Modern Coding Practices and Programmer Performance; Sheppard, Curtis, Millman, and Love; IEEE Computer, December 1979; pp. 41-49.