Why these original FORTRAN quirks?
in [Fortran]
|
From: jmfbahciv on 27 Oct 2006 07:28 In article <1749.519T2884T5046549(a)kltpzyxm.invalid>, "Charlie Gibbs" <cgibbs(a)kltpzyxm.invalid> wrote: >In article <12jfi8k2tjgel7c(a)corp.supernews.com>, lfw(a)airmail.net >(Larry__Weiss) writes: > >> Rostyslaw J. Lewyckyj wrote: >> >>> Keypunchers, unless summer interns from a technical school or such >>> like, are not expected to be the Fortran pre compiler syntax checking >>> phase. Similarly we instructed our student help staffing the >>> input-output window (i.e. accepting job decks & handing out the >>> printed outputs) not to hand out programming advice, i.e. not play >>> at being consultants, even if they were seniors with some programming >>> courses under their belts. >> >> Plus, learning to code benefits from a "school of hard-knocks" >> experience. You don't really want to take that away from someone >> who is serious about learning the art (or is forced to become so >> because of job expectations). >> >> The proper place for such feedback is in a mentoring partnership >> or in a formal code-review. > >Still, we did have a help desk at school. Occasionally I'd get >stuck on a bug bad enough to make me stand in line to see whether >the volunteer staffer could help me. One day, while in line, I >happened to peek over the shoulder of the person in front of me. >I spotted his bug, pointed it out, and found myself clearing the >line from the back end while the official help desk person cleared >it from the front. Burning the linked list from both ends. > Thus I got to the head of the line much more >quickly - only to find that the help desk person couldn't figure >out my bug either. That was the beginning of my "hard knocks" >experience. Did he have to eyeball it or was there something very nice like a FORDDT? /BAH
From: jmfbahciv on 27 Oct 2006 08:09 In article <vBr_g.14795$GR.13058(a)newssvr29.news.prodigy.net>, Gary Scott <garylscott(a)sbcglobal.net> wrote: >Richard Steiner wrote: >> Here in alt.folklore.computers, >> nospam(a)see.signature (Richard Maine) spake unto us, saying: >> >> >>><jmfbahciv(a)aol.com> wrote: >>> >>> >>>>Yes that is a problem. One way to avoid that is to design >>>>your naming procedures to ensure exlclusivity. This is not >>>>difficult. >>> >>>It wasn't so easy in the days of 6-character name length limits. It was >>>hard enough to do comprehensible names without special conventions for >>>uniqueness. >> >> >> Not that hard, actually. You simply adopt a logical naming procedure >> for variables and source files. >> >> We used to (and still) assume that all 6-character identifiers were >> external in nature (that is, were DEFINEs or PARAMETERs located in an >> external file (named SOMETHING-F) which was later INCLUDED by programs >> that wanted to use that set of definitions. >> >> All local variables were either five characters or one character (the >> latter was reserved for local loop counters only and was usually I, J, >> K, etc.). >> >> For external parameters/defines, we tend to use the USAS convention of >> using the first two characters for the filename and the last four for >> the variable itself. This works well because USAS freespace files tend >> to have two-character names. >> >> Thus, the length of the file AP would be something like APLGTH or maybe >> APFLEN, an IATA city code stored in AP would be APCITY, etc. We try to >> be fairly consistent across different files in our applications, so a >> record length is always xxLGTH regardless of file, etc. >> >> At NWA, using a non-USAS environment, we tended to use the following >> conventions: >> >> (1) The first two characters were always the two-character application >> code (e.g., "WX" for weather, "GW" for Gross Weights, etc.). >> >> (2) The third letter tended to be unique for each file the define or >> parameter was being used for. >> >> This way, one knew that "WXSxxx" was always a define of a data element >> inside the Weather Station File, "WXGxxx" was always a define of a data >> element inside the Weather Grid file, etc. Thus, the length of the >> Weather Grid file would be WXGLEN, the time stored for a METAR in the >> WX Station file might be WXSTIM and its text might be WXSTXT, etc. >> >> I've worked with the 6-character limit since 1988, and I still find it >> easier to read the variable names in those older FORTRAN programs than >> I do in the newer C++ code I have to support because the FORTRAN folks >> were *far* more disciplined in their variable naming conventions. >> > >I tend to agree in that I never had much difficulty with 6 character >names because there was considerable discipline used in the naming >conventions we used. However, moderately increasing the lengths beyond >6 does provide a modest improvement in readability and you can still use >a disciplined approach to your naming convention with increased >flexibility. It used to be common to name OS/macro/JCL commands with >two letter mnemonics: CO for copy, PR for print, ED for edit. You >quickly run into the situation where the same two "obvious" characters >could mean multiple things. Once you expand the limit, you'll always end up with bit leak which rapidly becomes bit rot. Six was sufficient. We used the characters dot and percent and their position within the six-char field to have meaning. You could at a glance whether the variable name was an error code, a word index, a field, an address, a bit mask or a bit definition. /BAH
From: jmfbahciv on 27 Oct 2006 08:12 In article <_7ydnT5op4lYbqfYnZ2dnUVZ_rOdnZ2d(a)comcast.com>, "William J. Leary Jr." <Bill_Leary(a)msn.com> wrote: >"Terence" <tbwright(a)cantv.net> wrote in message >news:1161472385.953880.177910(a)m73g2000cwd.googlegroups.com... >> My memory is that at least one of the earlier Fortran compilers >> I worked with allowed SIX-letter variable names only in the main >> program.And FIVE-letter names as variables in subroutines and >> functions. > >This sounds vaguely familiar to me. I used FORTRAN (when it was still all >uppercase) on DG, DEC and [[some other]] computers back in the late 70's and >early 80's. One of them, I can't recall which, had some limitation like that. >Specifically, some short length in the main program, and that length minus one >in either subroutines or separately compiled modules. > The label put on the subroutine would have a character appended to the end. hmm...maybe that a way of flagging externs. /BAH
From: jmfbahciv on 27 Oct 2006 08:22 In article <1161796701.620075.134910(a)k70g2000cwa.googlegroups.com>, wclodius(a)lanl.gov wrote: > >Gene Wirchenko wrote: >> nospam(a)see.signature (Richard E Maine) wrote: >> >> >Rostyslaw J. Lewyckyj <urjlew(a)bellsouth.net> wrote: >> >> [snip] >> >> >> purely Fortran? But I'd consider that to be rather unrealistic in a >> >> production environment. Linkers, loaders, libraries etc. are a fact >> >> of life. >> > >> >I think we are not communicating here. The linkers, loaders, etc, are >> >part of the Fortran environment. That's why the Fortran standard (like >> >> They are? I used FORTRAN, back in the capitals days. The linker >> and loader were part of the OS. Many language systems used them. > >Of course they are part of the Fortran environment. They were also part >of the environment of any other language system that relied on them. A >(viable) (fortran) compiler must (be designed to) deal with their >conditions and influences (it is in effect surrounded by them) and the >result of using the linkers and loaders must be a code that must be be >usable within the system (including the OS) it is used in. CAreful. The linkers and loaders aren't separate. What is even worse is that the kiddies who think they know how machines work, are not aware of the reasons for linkers and loaders; they assume, rightly from their experience, that it is all one procedural step. This is a loss of knowledge that is happening right now. /BAH
From: Charlie Gibbs on 27 Oct 2006 12:44
In article <ehsqhr$8qk_011(a)s834.apx1.sbo.ma.dialup.rcn.com>, jmfbahciv(a)aol.com (jmfbahciv) writes: > In article <1749.519T2884T5046549(a)kltpzyxm.invalid>, > "Charlie Gibbs" <cgibbs(a)kltpzyxm.invalid> wrote: > >> In article <12jfi8k2tjgel7c(a)corp.supernews.com>, lfw(a)airmail.net >> (Larry__Weiss) writes: >> >>> The proper place for such feedback is in a mentoring partnership >>> or in a formal code-review. >> >> Still, we did have a help desk at school. Occasionally I'd get >> stuck on a bug bad enough to make me stand in line to see whether >> the volunteer staffer could help me. One day, while in line, I >> happened to peek over the shoulder of the person in front of me. >> I spotted his bug, pointed it out, and found myself clearing the >> line from the back end while the official help desk person cleared >> it from the front. > > Burning the linked list from both ends. :-) >> Thus I got to the head of the line much more quickly - only to find >> that the help desk person couldn't figure out my bug either. That >> was the beginning of my "hard knocks" experience. > > Did he have to eyeball it or was there something very nice > like a FORDDT? Strictly eyeballs. Hardware was far too expensive to waste on us undergrads. -- /~\ cgibbs(a)kltpzyxm.invalid (Charlie Gibbs) \ / I'm really at ac.dekanfrus if you read it the right way. X Top-posted messages will probably be ignored. See RFC1855. / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign! |