lamonts@M5.Sdsc.EDU (Steve Lamont) (01/29/88)
Dave Sill <dsill@NSWC-OAS.ARPA> quotes me as saying: > In article <88012145556.2040246a@Sds.Sdsc.Edu> Steve Lamont > <lamonts@Sds.Sdsc.EDU> writes: > >I don't see the lack of indirection as a major disadvantage in the type of > >programs FORTRAN is suited to. Perhaps I am missing the point here. Can > >someone please illuminate the subject? > Perhaps you're missing the *pointer*. :-) Good point (:-)... but the key phrase is "the type of programs FORTRAN is suited to..." There are whole bunches of things that FORTRAN is suited to that C is not, and vice versa. I agree that it would be nice to have dynamically allocated arrays in FORTRAN but I think that, bearing in mind the gawdawful hassle handling multiply dimensioned arrays in C, (KEY PHRASE COMING UP...) that, for the purposes that it was designed to address, FORTRAN, by and large, has it right. (FLAME RETARDANT: THIS DOES NOT MEAN THAT C HAS IT WRONG.... IT JUST MEANS THAT THEY WERE DESIGNED TO DO TWO DIFFERENT THINGS) > >... In fact, in > >light of some other comments that I've seen on this group, the construction > > > > call bar > > > >is slightly more aestheticly pleasing than > > > > bar(); > To coin a phrase: beauty is in the eye of the beholder. I think > "bar();" is more in keeping with the philosophy of C, hence more > aesthetic. No argument (pun intended...), as long as we're talking about C. This was only a side comment, directed at the null statement discussion that has been going on for the past week. > >[my comments about named common and logical grouping of external data > >references] > That's funny, if you had asked me to list of what I think are > Fortran's 10 biggest mistakes, COMMON blocks would probably be at the > top. They are probably the single largest cause of suicide among > Fortran maintenance programmers, although implicit variable > declarations might be close. Howcome? I've been programming in FORTRAN for about 10 years, both writing my own code and maintaining others' and find it useful to know which program unit (subroutine or function) has the capability of diddling with what external variable and which program doesn't. Are you saying that lumping all externals into one pool is *more* maintainable? How so? How else do you suggest? I'm genuinely interested. But, then, again, I happen to like implicit declarations, too... ;-) <---- flamers... note smiley guy... spl ---------------------------------------- Internet: LAMONTS@SDS.SDSC.EDU Bitnet: LAMONTS@SDSC Span: SDSC::LAMONTS (27.1) USPS: Steve Lamont San Diego Supercomputer Center P.O. Box 85608 San Diego, CA 92138 AT&T: 619.534.5126
ok@quintus.UUCP (Richard A. O'Keefe) (01/29/88)
In article <11524@brl-adm.ARPA>, lamonts@M5.Sdsc.EDU (Steve Lamont) writes: > Howcome? I've been programming in FORTRAN for about 10 years, both writing > my own code and maintaining others' and find it useful to know which program > unit (subroutine or function) has the capability of diddling with what > external variable and which program doesn't. Are you saying that lumping > all externals into one pool is *more* maintainable? How so? How else do > you suggest? I'm genuinely interested. But, then, again, I happen to like > implicit declarations, too... ;-) <---- flamers... note smiley guy... I can't figure out whether he is arguing FOR common blocks (view: C's "extern" is one giant pool) or AGAINST them (view: a common block is a large pool). I heartily agree that it is useful to know which thing can change what. All you need is a C compiler or Lint which warns "inner declaration hides outer", and then word-mode search in your favourite editor tells you exactly what you know. (Have you ever tried looking through Fortran sources for PIDATA only to find that the key place wrote instead PI DATA (spaces are legal inside Fortran tokens...)?) Evidently the Fortran standards committee think something is wrong with common blocks too, because Fortran 8X puts COMMON on the don't-use-this-in-new-programs-because-it-is-going-away list; the replacement is an uncommonly ADA-like "USE". The traditional implementation of C was "each extern variable is a common block". What's the difference between a C program and a Fortran program where each common block contains one variable? Apart from the fact that the Fortran program has the chance to declare INTEGER FRED COMMON /FRED/ FRED in one place and CHARACTER*4 FRED COMMON /FRED/ FRED in another.... On the B6700 there was this neat symbolic debugger where you could ask "show me all the places where such-and-such a variable is assigned". Interlisp has this neat thing called Masterscope which you can ask "edit all the places where such-and-such a variable is changed". n Is anyone trying to put together an R -like environment for C?
sem@mitre-bedford.arpa (McQueen) (02/08/88)
In article <880126220237.2020019d@M5.Sdsc.Edu> Steve Lamont <lamonts@M5.Sdsc.EDU> writes: (about COMMON being considered harmful) >Howcome? I've been programming in FORTRAN for about 10 years, both writing >my own code and maintaining others' and find it useful to know which program >unit (subroutine or function) has the capability of diddling with what >external variable and which program doesn't. Are you saying that lumping >all externals into one pool is *more* maintainable? How so? How else do >you suggest? I'm genuinely interested. But, then, again, I happen to like >implicit declarations, too...;-) <---- flamers... note smiley guy... Actually, it's not COMMON itself that's bad, it's how it's used. For years, DoD projects that used FORTRAN were not allowed to pass subroutine arguments in the call itself, but were required (contractually) to use COMMON. Evidently there was some time cost involved in passing the arguments in the call, at least on some compilers/machines. This led, on large projects, to a proliferation of variables and COMMONs (usually, blank COMMON was prohibited and only named COMMON could be used). Naturally, every time somebody added a new variable to be passed via COMMON, everybody didn't get the word to recompile everything so that integration was always a nightmare. (I can still remember the chief programmer coming into the terminal room once or twice a day and shouting, "Everybody recompile, we just changed COMMON!" The result of using external variables at all is called "data coupling" and generally considered not to be a Good Thing (causes problems in maintenance later on) and should be discouraged. Note that I didn't say "prohibited" because the designer often has to make tradeoffs. It just shouldn't be done as a matter of course. Since you put the smiley in, I won't comment on implicit declarations. Stan