carols@drilex.UUCP (Carol Springs) (01/23/88)
In article <2666@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >What I really hate is having the compiler *not* yell at me for mispelling >one of my variable names, and having to spend (sometimes) hours to find the >bug. The overlooked declaration can be fixed in a few minutes. It takes a >*lot* of those to make up for one six hour debugging effort. I agree. That's why it's a good idea for FORTRAN programmers to include the line IMPLICIT LOGICAL (A-Z) or IMPLICIT CHARACTER (A-Z) in each main program and subprogram. Even better, many compilers now make an IMPLICIT NONE available. I realize that the thought of being forced to declare one's variables is odious to most "traditional" FORTRAN programmers. I still remember students from my T.A. days who would look at me as though I were off my rocker for telling them to use IMPLICIT LOGICAL and declare all their variables. These kids' major, unsolvable problems always seemed to stem from some overlooked misspelling. Of course, in the professional world, such things never happen. ;-) -- Carol Springs "Programmers are allowed five extra years." Data Resources/McGraw-Hill {rutgers!ll-xn, ames!ll-xn, mit-eddie!ll-xn, 24 Hartwell Avenue husc6!harvard, gatech!harvard, Lexington, MA 02173 linus!axiom, necntc} !drilex!carols
mcdonald@uxe.cso.uiuc.edu (01/25/88)
>I agree. That's why it's a good idea for FORTRAN programmers to include >the line IMPLICIT LOGICAL (A-Z) or IMPLICIT CHARACTER (A-Z) in each main >program and subprogram. Even better, many compilers now make an >IMPLICIT NONE available. You must be kidding! Please, please, don't forget the smiley faces when saying things like that! The greatest feature of Fortran over languages like C or Pascal (well, C at least, Pascal has so many other stupids) is that you don't have to declare variables. One of the original goals of Fortran was to eliminate the drudge work from progamming, and variable declaration is one of the worst. Computers do a much better job of making lists than do people. The argument about mispelled variable names is a red herring that any REAL Fortran scientific programmer would recognize. An actual mistyped name is easily caught- it doesn't take any 6 hours. The computer (well, most) will give you a nice alphabetized list of variable names and all their references. Just look at it for extra names. The REAL nightmare of scientific programming, is typing a WRONG but legal variable name. Please, you computer science types, believe me. Scientific programming is my business. let's say that you are writing a program describing the vibrations of the molecule SF5 (sulfur pentafluoride). This thing has six atoms, each of which has three positions and three momenta. Fine, you number them 1 to six and use a two dimensional array. You can't declare each one separately, as you must feed the array to the integration routine. You also need all the various interatomic distances and there are 15 of these. You can't give them all different names, because then you can't use the symmetry properties in writing the potential surface. You have to use an array. You could use equivalence statements to give the array elements names, but computer science type probably would object to that. In any case, I and most of the real scientific programmers worry more about typing r(7) where we meant r(8) than typing o(8) where we meant p(8). Errors in the mind are much more difficult to find than errors of the fingers. Doug McDonald Professor of Chemistry University of Illinois P.S. In any case, even if a program is coded perfectly it may be WRONG. The fact that the whole IDEA behind a program may be wrong is something that computer types frequently forget. If I design my program assuming that F = MA instead of H* Psi = E * Psi it's going to give a "wrong" answer!
ok@quintus.UUCP (Richard A. O'Keefe) (01/28/88)
In article <50500018@uxe.cso.uiuc.edu>, mcdonald@uxe.cso.uiuc.edu writes: > >I agree. That's why it's a good idea for FORTRAN programmers to include > >the line IMPLICIT LOGICAL (A-Z) or IMPLICIT CHARACTER (A-Z) in each main > >program and subprogram. Even better, many compilers now make an > >IMPLICIT NONE available. > > You must be kidding! Please, please, don't forget the smiley faces when > saying things like that! The greatest feature of Fortran over languages > like C or Pascal (well, C at least, Pascal has so many other stupids) is that > you don't have to declare variables. I just got bitten by this today. Fortunately, I had decided to test a certain function, and noticed that the relative error was approximately 2.0, when I had hoped for 0.0. The point of IMPLICIT NONE (which you don't *have* to use) or UNIX's "-u" flag (which you don'y *have* to use) is to tell you about this mis-spelled identifiers you hadn't thought of yet. Cross-references are fine *IF* you already suspect the problem! {Best of all are compiler which warn "FOO may be used before it is set"...} > In any > case, I and most of the real scientific programmers worry more about > typing r(7) where we meant r(8) than typing o(8) where we meant p(8). > Errors in the mind are much more difficult to find than errors of the > fingers. That's why pretty well every programming language except Fortran has records, and why VAX/VMS Fortran and Fortran 8X *do* have records. It's also why I never believe the output of any Fortran program I haven't read. Come to that, why not use Fortran PARAMETER statements to help with the r(7) -vs- r(8) problem? IMPLICIT NONE is the best thing that happened to Fortran since Ratfor.
richard@calvin.EE.CORNELL.EDU (Richard Brittain) (01/28/88)
In article <50500018@uxe.cso.uiuc.edu>, mcdonald@uxe.cso.uiuc.edu writes: > >I agree. That's why it's a good idea for FORTRAN programmers to include > >the line IMPLICIT LOGICAL (A-Z) or IMPLICIT CHARACTER (A-Z) in each main > >program and subprogram. Even better, many compilers now make an > >IMPLICIT NONE available. > ... One of the original goals > of Fortran was to eliminate the drudge work from progamming, and variable > declaration is one of the worst..... > ... The argument about mispelled variable names is a red > herring that any REAL Fortran scientific programmer would recognize. An > actual mistyped name is easily caught- it doesn't take any 6 hours..... I agree that implicit type declarations are a useful feature, and certainly make for convenience on a "quick hack" and on large projects also. However, I think that "real" fortran programmers are all too often scientists first and programmers second, and it really shows in the style, and hinders understanding and modification later. Granted, old fortran was not an easy language in which to lay out structured, modular code, but that hardly excuses some of the "spaghetti" code one often finds in scientific programs (even code published as part of theses!). I write/use both "system" programs and "scientific" programs, using fortran for both, and I find that my system code looks like C (almost everything declared, very structured, very modular, and lower case). After learning (what I hope are) good programming skills, I became so aware of bad practises in a lot of the old code that I work with, that now I simply don't trust a lot of "working" code until I spend time checking it out. I am spoiled by having a very friendly compiler to work with (allows many structured extensions to f77, like while()...end while, do...until(), loop(n)...end loop etc. (not a goto is sight) but still, even with vanilla f77, I think it would make a big difference to the maintainance and portability of scientific code if the authors learned good programming style. Fortran is still, and will always be my language of choice for numerical work, (although I finally broke down and started learning C recently), but I would love it if some of my scientist colleagues were better programmers. Two books on the subject which made a big difference to me are "The elements of programming style" and "Software Tools" both by Kernighan and Plauger. These have been around for a while but are still worth mentioning. Richard Brittain, Cornell Space Plasma Physics Group ARPA: richard@calvin.ee.cornell.edu
trh@eagle.ukc.ac.uk (T.R.Hopkins) (01/28/88)
There are programs in the public domain which accept Fortran 77 source generated by lazy programmers who can't be bothered to type their variables and don't indent their code and who use random number generators to produce their labels and ..... and produce nicely laid out code with all variables typed etc.. One of these tools will also check all subprogram interfaces and perform a standard conformance check. It's called Toolpack, we have it on Vaxes running VMS and 4.3bsd Unix and on Suns, and it's found loads of errors in programs whose authors are too lazy to type ... Tim
kristjan@rhi.is (Kristjan Jonasson) (01/29/88)
In article <50500018@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: [someone else had written] >>... it's a good idea for FORTRAN programmers to include >>the line IMPLICIT LOGICAL (A-Z) or IMPLICIT CHARACTER (A-Z) in each main >>program and subprogram. Even better, many compilers now make an >>IMPLICIT NONE available. > >You must be kidding! Please, please, don't forget the smiley faces when >saying things like that! The greatest feature of Fortran over languages >like C or Pascal ... [is that] >you don't have to declare variables. ... >The argument about mispelled variable names is a red >herring that any REAL Fortran scientific programmer would recognize. ****FLAME ON**** Well Mr. "real Fortran scientific programmer" (I suppose you don't eat quiche either), what you have just said here is just so much rubbish that any "real" software engineer or serious programmer would recognise. Perhaps if you took more interest in Fortran language development you would have seen some things which might change your mind. **REDUCE FLAME LEVEL** In particular, you might have seen "M.A.T." (Maintainability Analysis Tool, I believe). This is a tool for analysing Fortran programs and reporting on anomalous situations (variables set but not referenced, referenced but never set, declared but never referenced or set, with the same names as those in a common block occurring in a different subprogram - you get the idea). This tool has been applied to millions of lines of Fortran code, AND IN EVERY LARGE SCALE PROGRAM IT HAS FOUND ERRORS. Moreover, MANY OF THESE WOULD HAVE BEEN DETECTED BY LACK OF IMPLICIT TYPING. You think it is easy to scan a list of variables to see what has been added/missed out eh? Obviously you have never seen/programmed/tried to fix a large (100000 lines+) program. FLAME OFF What is convenient and un-instrusive in a small program (e.g. <10 pages) turns out (not very surprisingly) to be a maintenance nightmare in larger programs. I cannot emphasise this enough: it is all very well to say "forced declaration is an unnecessary pain", but examination of the situation ***in reality*** shows that it is a NECESSARY pain (for large programs in particular). Notice that MAT did not find errors in 50% or whatever of large programs it was applied to: it found these errors IN ALL LARGE SYSTEMS!!! When the type of errors is examined, it is indeed a condemnation of the implicit typing system. ... >Errors in the mind are much more difficult to find than errors of the > fingers. I couldn't agree more. But on the other hand (as you said, computers are much better at keeping lists than people) I'd rather have the computer find at least my typing errors than find none of them at all! And when one is looking for a logic error it can be quite difficult to spot that it was a simple typing error. > >Doug McDonald, Professor of Chemistry, University of Illinois > Malcolm Cohen, "real scientific programmer", University of Iceland.
chris@metavax.UUCP ( PSA) (01/30/88)
In article <50500018@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > >>I agree. That's why it's a good idea for FORTRAN programmers to include >>the line IMPLICIT LOGICAL (A-Z) or IMPLICIT CHARACTER (A-Z) in each main >>program and subprogram. Even better, many compilers now make an >>IMPLICIT NONE available. > >You must be kidding! Please, please, don't forget the smiley faces when >saying things like that! > >Doug McDonald >Professor of Chemistry >University of Illinois > I am so, so, SO glad that smiley faces were NOT added on such a correct and _necessary_ statement. For the past 5 years or so, I have had the inglorious task of maintaining around 200,000 lines of Fortran which was written without the required declaration of variables. The failure of a variable to be declared was responsible for at least 30% of the errors which I corrected. It was only recently that I was able to make use of IMPLICIT to avoid these problems en masse in our recent new version of our software. Secondly, it is my experience that once software is completed, if in testing it appears to be working, cross reference listings generated by the compiler are ignored. Thus an apparently correct output would indeed be accepted by end users as correct. This type of error is particularly painful if some users come to depend upon the incorrectness and then it is removed (This happened to us, and those who depended on the error lost money because of it). It is my firm belief that the only reason that Fortran does not require variable declaration is that the original developers were developing one of the first compiled languages, and thus _didn't know any better_. There was no experience in the use of higher level programming languages to be had. Thirdly, the example Professor McDonald sites from his application does not show that variables shouldn't be declared, only that they should be declared correctly for the application involved. ------ /MM/\MM\ META SYSTEMS, LTD. /MM/ \MM\ 315 E. Eisenhower /MM/ /\ \MM\ Suite 200 === == === Ann Arbor, MI 48108 \SS\ \/ /SS/ \SS\ /SS/ Chris Collins, Senior Programmer \SS\/SS/ ------
mcdonald@uxe.cso.uiuc.edu (02/04/88)
>>The argument about mispelled variable names is a red >>herring that any REAL Fortran scientific programmer would recognize. >****FLAME ON**** >Well Mr. "real Fortran scientific programmer" (I suppose you don't eat >quiche either), what you have just said here is just so much rubbish that any >"real" software engineer or serious programmer would recognise. Perhaps if >you took more interest in Fortran language development you would have seen >some things which might change your mind. >**REDUCE FLAME LEVEL** >In particular, you might have seen "M.A.T." (Maintainability Analysis Tool, I >believe). This is a tool for analysing Fortran programs and reporting on >anomalous situations (variables set but not referenced, referenced but never >set, declared but never referenced or set, with the same names as those in a >common block occurring in a different subprogram - you get the idea). >I cannot emphasise this enough: it is all very well to say "forced declaration >is an unnecessary pain", but examination of the situation ***in reality*** >shows that it is a NECESSARY pain (for large programs in particular). Really? I am getting tired of other prople trying to force religion on me. It would seem that the answer would lie in the sort of program you mention above, M.A.T. I have heard about it but never seen it. I'd love to get a copy. Can you E-mail one to me? Actually, the question is moot as far as I am concerned. Despite all the pain, the Fortran 8x proposal and other difficulties in Fortran, particularly the rigid distinction between character and integer variables, have sent me to C. I don't like to have to declare variables, but do like the fact that integers, characters and logicals all can be used easily together. I find it hard to understand how someone could object to undeclared variables and not object to this. In fact, such people probably like Pascal, straightjackets :-) :-) and the Marquis de Sade :-) :-) :-) :-) :-). The best thing to do , which would unfortunately reduce the flame level in comp.lang.c and comp.lang.fortran, would be to recognize that programming style is a matter of taste. What is right for one is not right for another . (FLAME ON! SMILEY FACES OFF! I recognize this. Do you? That was my point when I said no smiles in my earlier posting. Flame OFF!)) Frankly, I find flames fun. Doug McDonald
gil@icus.UUCP (Gil Kloepfer Jr.) (02/08/88)
[Some irrelivant material removed from the following quote to keep followup size small] In article <50500026@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > >>>The argument about mispelled variable names is a red >>>herring that any REAL Fortran scientific programmer would recognize. > >>****FLAME ON**** > >>Well Mr. "real Fortran scientific programmer" (I suppose you don't eat >>quiche either), what you have just said here is just so much rubbish that any >>"real" software engineer or serious programmer would recognise. Perhaps if >>you took more interest in Fortran language development you would have seen >>some things which might change your mind. > >>I cannot emphasise this enough: it is all very well to say "forced declaration >>is an unnecessary pain", but examination of the situation ***in reality*** >>shows that it is a NECESSARY pain (for large programs in particular). > >Really? I am getting tired of other prople trying to force religion on me. >It would seem that the answer would lie in the sort of program you >mention above, M.A.T. I have heard about it but never seen it. I'd love >to get a copy. Can you E-mail one to me? [Is M.A.T. a public-domain program or is it a commercial software product?] > >Actually, the question is moot as far as I am concerned. Despite all >the pain, the Fortran 8x proposal and other difficulties in Fortran, >particularly the rigid distinction between character and integer >variables, have sent me to C. I don't like to have to declare variables, >but do like the fact that integers, characters and logicals all can be used >easily together. I find it hard to understand how someone could object >to undeclared variables and not object to this. In fact, such people >probably like Pascal, straightjackets :-) :-) and the Marquis de Sade >:-) :-) :-) :-) :-). [I hate Pascal, straightjackets, etc... Did you ever try running your C programs through lint????] > >The best thing to do , which would unfortunately reduce the flame level >in comp.lang.c and comp.lang.fortran, would be to recognize that programming >style is a matter of taste. What is right for one is not right for another >. (FLAME ON! SMILEY FACES OFF! I recognize this. Do you? That was my point >when I said no smiles in my earlier posting. Flame OFF!)) Frankly, I >find flames fun. [I hate flames...] > >Doug McDonald Doug, Perhaps you have not been part of a software development team as part of a company which manufactures software. (or maybe you have, but have not shown so in your followup) The truth of the matter is this: nobody is trying to force any "religious" beliefs about declaring variables down your throat. What I think is trying to be said is that when you work on a program as part of a large system (that is SOFTWARE system, not HARDWARE)...it is maintained by more than just one person (generally) and must be written in such a manner that it is simple and cost-effective to debug and maintain. This is from a software development company's standpoint, and not for the casual user, number-cruncher, or university hacker. To make a long story short, in order to make software maintainable by more than just one person, certain software standards are developed. Further, it is difficult to find a mistake such as spelling a variable incorrectly in the middle of a large program when variable declaration for everything is not enforced. If I didn't see this problem myself, I wouldn't care either. However, I can see now why some programmers push this concept so much. As for forcing it ALL the time... I think it would be nice to be able to revert-back to having the implicit declarations when desired. However, being the senior programmer (and in charge of the programming standards for myself and those under me), I have pushed the idea of declaring all variables in a FORTRAN program for both clarity and to reduce the number of unnoticed bugs that will undoubtably occur as a result of misspelling or misdeclaring a variable. BTW: Nobody where I work objects to this rule... +====================================+========================================+ | Gil Kloepfer, Jr. | Net-Address: | | Senior Programmer | {boulder,ihnp4,talcott}!icus!gil | | Bowne Management Systems, Inc. | Voice: Home: (516) 968-6860 | | 235 E. Jericho Turnpike | Office: (516) 248-6840 x796 | | Mineola, New York 11501 | Internet: gil@icus.UUCP | +====================================+========================================+ | Disclaimer: My employers know I'm right, but will never admit to it... | +=============================================================================+