Why these original FORTRAN quirks?
in [Fortran]
|
From: Richard E Maine on 19 Oct 2006 19:39 Rostyslaw J. Lewyckyj <urjlew(a)bellsouth.net> wrote: > Richard E Maine wrote: > > When I was an obnoxious youngster (the young part has changed :-)) still > > in undergrad school doing keypunching for some of the senior engineers, > > I got my figurative hand slapped for "improving" some of the code on the > > fly as a typed. > > > > In retrospect, I realize that some of my "improvements" weren't.... > Keypunchers are supposed to quickly and accurately convert text written > on coding forms, or in some cases other forms, into machine readable > media. Anything that slows down this process, such as reading the > material for comprehension will tend to slow down the efficiency of the > transfer process. This is another reason that the keypuncher should not > play at being an editor, or filter. Although that might apply to a person whose job was to be a keypuncher, my job was to be an engineering trainee. Keypunching for the "real" engineers was just a piece of the job. As a trainee, it actually does help to pay attention to what one is doing instead of turning off the brain and operating by rote (unless one is training for a position that is purely to do the rote operations). Much like "optimizing" code, doing a good job of optimizing a work process requires one to stand back and understand what the larger objectives really are. Otherwise you end up optimzing the wrong things. In this case, optimizing my throughput as a keypuncher would have been detrimental to the most important part of my job as a trainee. Some of what I did was wrong, as elaborated in the parts I elided above, but thinking about what I was doing was not wrong. -- Richard Maine | Good judgment comes from experience; email: my first.last at org.domain| experience comes from bad judgment. org: nasa, domain: gov | -- Mark Twain
From: Rostyslaw J. Lewyckyj on 19 Oct 2006 23:33 Richard E Maine wrote: > Rostyslaw J. Lewyckyj <urjlew(a)bellsouth.net> wrote: > > >>Richard E Maine wrote: > > >>>When I was an obnoxious youngster (the young part has changed :-)) still >>>in undergrad school doing keypunching for some of the senior engineers, >>>I got my figurative hand slapped for "improving" some of the code on the >>>fly as a typed. >>> >>>In retrospect, I realize that some of my "improvements" weren't.... > > >>Keypunchers are supposed to quickly and accurately convert text written >>on coding forms, or in some cases other forms, into machine readable >>media. Anything that slows down this process, such as reading the >>material for comprehension will tend to slow down the efficiency of the >>transfer process. This is another reason that the keypuncher should not >>play at being an editor, or filter. > > > Although that might apply to a person whose job was to be a keypuncher, > my job was to be an engineering trainee. Keypunching for the "real" > engineers was just a piece of the job. As a trainee, it actually does > help to pay attention to what one is doing instead of turning off the > brain and operating by rote (unless one is training for a position that > is purely to do the rote operations). > > Much like "optimizing" code, doing a good job of optimizing a work > process requires one to stand back and understand what the larger > objectives really are. Otherwise you end up optimzing the wrong things. > In this case, optimizing my throughput as a keypuncher would have been > detrimental to the most important part of my job as a trainee. > > Some of what I did was wrong, as elaborated in the parts I elided above, > but thinking about what I was doing was not wrong. > Yes. As an engineering trainee, apprentice, acolyte, doing some incidental keypunching, my comments do not apply. However they apply to the kind of persons that Mizz Barbara was reminiscing about. What I can't figure out is what position she was officialy playing? keypunch operator?, ???. In various comingled posts she mentions doing programming in some and keypunching in others. -- Rostyk
From: Terence on 20 Oct 2006 00:00 Terence: > >And later used the Mercury STAR computer for De Havilland "Blue Streak" > >guidance simulations > Stan Barr: > There's a coincidence! > I was looking at a couple of photos of Blue Streak in a magazine yesterday: > The production line at Stevenage and the launch site at Spadeham. I worked at De-Havilland in London only for short while, till I was accepted for a PhD project at City and Guilds College. War story numer One: We had to take a box of triodes INTO this computer and look for missing filament glows, and plug in replacements, leave, restart, feed our paper tape in and cross fingers for a 20 minute fault-free run while watching the oscilloscope (very limited text generation). Then repeat... We predicted gravity" en route" to the target, so it was aimed ballistic rather than true guidance... War story Number Two: One friday in 1957 (I think) we all went home as usual, and over the weekend "someone" took out the outside street wall and brought in a real unloaded Blue Streak ICBM missile which almost filled the whole basement; then put the wall back on, so you couldn't tell. It certainly wouldn't go down the stairs! Mind you, this was in the centre of London.... So monday we were told what to find in the basement.... The missile was later test fired on the Woomera Range in Australia, where, funnily, I now live...
From: Brian Inglis on 20 Oct 2006 00:11 On Thu, 19 Oct 2006 16:39:03 -0700 in alt.folklore.computers, nospam(a)see.signature (Richard E Maine) wrote: >Rostyslaw J. Lewyckyj <urjlew(a)bellsouth.net> wrote: > >> Richard E Maine wrote: > >> > When I was an obnoxious youngster (the young part has changed :-)) still >> > in undergrad school doing keypunching for some of the senior engineers, >> > I got my figurative hand slapped for "improving" some of the code on the >> > fly as a typed. >> > >> > In retrospect, I realize that some of my "improvements" weren't.... > >> Keypunchers are supposed to quickly and accurately convert text written >> on coding forms, or in some cases other forms, into machine readable >> media. Anything that slows down this process, such as reading the >> material for comprehension will tend to slow down the efficiency of the >> transfer process. This is another reason that the keypuncher should not >> play at being an editor, or filter. > >Although that might apply to a person whose job was to be a keypuncher, >my job was to be an engineering trainee. Keypunching for the "real" >engineers was just a piece of the job. As a trainee, it actually does >help to pay attention to what one is doing instead of turning off the >brain and operating by rote (unless one is training for a position that >is purely to do the rote operations). > >Much like "optimizing" code, doing a good job of optimizing a work >process requires one to stand back and understand what the larger >objectives really are. Otherwise you end up optimzing the wrong things. >In this case, optimizing my throughput as a keypuncher would have been >detrimental to the most important part of my job as a trainee. > >Some of what I did was wrong, as elaborated in the parts I elided above, >but thinking about what I was doing was not wrong. You could have put the suggestions and corrected/improved code on comment cards: some guys I worked with really knew their numerical analysis and coding techniques to avoid numerical problems. I had a similar job as a trainee programmer in an engineering consultancy, but I also had to act as computer operator whenever (like 9pm, midnight, or 6am) they had managed to book a time slot on the machine: read in, compile and link the decks; run the jobs; save the sources, objects, and executables onto DECtape; print a DECtape directory listing; bundle directory with compiler listings and program output. So the engineers never /needed/ to waste their expensive time dealing with cards, except as hardcopy backup, operating the computer, or running jobs. That job included reading and fixing typos, correcting other compilation errors, fixing obvious bugs, making sure everything compiled, linked, and ran properly, (including inserting the 1X when the results ended up in the first, control character, column of output) and logging the time spent on each task. Some engineers liked to make changes to the card decks and redo everything from that basis, so they could use others to do the computer runs; others restored from DECtape to the fixed head per track scratch disk partition, and did their own further development interactively; both then resaved everything on disk to DECtape. -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis(a)CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply
From: jmfbahciv on 20 Oct 2006 09:40
In article <1hng38c.14ii6qa4exlwwN%nospam(a)see.signature>, nospam(a)see.signature (Richard Maine) wrote: ><jmfbahciv(a)aol.com> wrote: > >> In article <1hne8p2.vgiivpx9358gN%nospam(a)see.signature>, >> nospam(a)see.signature (Richard E Maine) wrote: >[about name conflicts with intrinsics] >> >Elsewhere in my post, I mentioned that one of the ways this comes up is >> >when new intrinsics are added to the language. >> >> 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. Of course it was. We did it. For instance, read UUOSYM.MAC and you'll see how, at a glance, we could tell if a variable name was a field, bit, word, or value. And we encoded a heirarchy so you could tell from the name at which level of the data format the name dealt with. (I wrote badly but I don't know how to describe it in English.) >Not until f90 was the 6-character limit formally lifted, though in the >later days of f77, most compilers allowed longer names. In the earlier >days of f77, not so at all. There were plenty of early compilers/systems >that enforced the 6 character limit (or at least something close - I >recall CDC as having a limit at 7) so that one needed to stick to it for >portable code. > >These days, modules provide an improved solution. In fact, I personally >would have preferred to put more of the new standard intrinsics into >modules, but I didn't have much luck swaying the committee on that one. >I do put my own new code in modules. I do not consider 128-character variable names an improved solution. It's a huge mess maker. /BAH |