Programming Without Computers

Mundane Pointless Stuff I Must Share (MPSIMS)
#21

In the mid-50s I was running a large analog computer (someone once claimed it was the largest analog computer ever built, although I really doubt that) and in the same room were 2 or 3 people writing code for the Univac I. This was pre-Fortran, you understand. The machine was hard wired to accept instructions like
A 440
which meant add the contents of memory address 440 to what is in the accumulator. Similarly
M 440
would multiply the contents of 440 to a different (I think) register. (The word “registor” wasn’t yet in use.) So it was kind of an assembly language. There were 1000 memory locations, numbered 000 to 999. Everything was in binary-coded decimal, using excess 3 notation, which I will not explain, but it had to do with carrying. Each memory location contained 72 bits divided into 12 six-bit bytes. (This reminds me that the French word for byte, octet, is incorrect. In the early days of computing, a byte could be 6, 8, or even 9 bit long.)

Anyway, they would work out an algorithm for what they wanted to do and then write not one, but several lines of code on special coding pads. Then someone else punched paper tape and entered it into the machine and tried to run it.

Incidentally, I read some years ago that the average programmer produces, on average, 7 lines of debugged, commented code a day. Fifty lines would be quite extraordinary.

#22

Compiling.

#23

I was an Enlisted AF computer programmer my whole 21 years. Air Force Specialty Codes 511x1, 491x1, 3C0x2, in that order.

(Multiple specialty codes because AFPC and the career field management team kept playing reindeer games with career field structure. The “x” is the skill level, from 1 (untrained) to 9 (manager/technical leader)).

Yes, we enlisted punks did program. We were doing work that would have cost the DoD 3 times as much to contract out, largely because leadership could order us to do stupid self-destructive things to meet schedule and budget and we’d be obligated to obey or go to prison for disobeying a lawful order. (Ask me about the summer of 1995, which consisted of 100 hour weeks for an entire 3 1/2 months, because our commander boasted to his boss about software which didn’t even exist… and we had to make the software exist before the demonstration he promised for September. :eek:)

1-level newbies went to technical school, where they learned the fundamentals of computers and computer programming. As much as you can in 6 weeks, anyway.

Pass tech school, and you’re a 3-level.

The 3-level, “apprentice” programmer was then assigned to his first unit and usually did trivial code-monkey stuff under the watchful eye of an NCO supervisor. In my early career, a setting like OP, the kid (an Airman First Class, for instance) would try writing a few lines of code to satisfy a small part of the flowchart. (Write, on a coding form.) Then the coding form would be reviewed by his supervisor, and if it passed muster, the kid would get to punch his stuff on cards and merge it with the rest of the supervisor’s deck.

Sometimes the apprenticeship was also being the keypunch monkey for the supervisor’s entire team. A form of “paying your dues”, and you get to see other programmers’ code as you poked it into the IBM 026.

You learn, you pass tests, you undergo a formal OJT process (like a correspondence course) along with the informal OJT, and you get certified as a 5-level Journeyman. You’re now skilled enough to be promoted into the NCO ranks. (That happens separately, using different test. One test is for your technical specialty, so your OJT is helpful for that, but the other test is general military/enlisted knowledge.)

Having your 5-level doesn’t guarantee your promotion. But not having it when you should guarantees you can’t be promoted. You can test, but they’ll hold the promotion and press your leadership to get you skill certified. (Try explaining to your commander why you’re too busy to get your formal OJT done. :eek:)

Now you’re an NCO. You’re Sergeant So-and-so. You get to supervise and train your own pack of snot-nosed airmen. You also get to design the flow of the software, some of the low-level architecture, and write a lot of the code. Plus testing, and quality, and paperwork, and being responsible to the rest of the organization for your code.

Do more OJT (technical and military leadership), plus some in-residence formal schools, and you can be certified as a 7-level Craftsman programmer. Now you can be promoted to an upper-tier NCO grade (E-6 Technical Sergeant or maybe eventually E-7 Master Sergeant) and supervise a large team, owning lots of the design and implementation space for a large project… plus budgets and schedule. Software development management plus system analysis/architecture/engineering. Drawing a salary and benefits less than half what you’d command as a civilian.

They you retire. At least, I did, as a Master Sergeant. I supervised a shop of about 20 folks, with both coding responsibilities and server management/sys admin responsibilities.

And that’s a microcosm of what happened to Enlisted Air Force computer programming. They added other responsibilities to the career field (like system administration, or network administration, etc.), then turned the actual software development over to contractors, then converted the entire career field into the other jobs they added (like 3Dxxx Cyberspace Support) or into subject-matter specific operations jobs (like 1Cxxx Command and Control Operations).

As far as “write code out longhand, punch it, etc.”, that was pretty much done in my neck of the woods by the early 1980s, but a lot of the practices remained (such as designing in paper flowcharts and coding on paper for review before sitting down at a terminal and entering your code on-line using a text editor).

#24

I usually hear 10 lines a day. It’s a nonsense figure based on total man-hours in a project, often involving a lot of re-writes and non-programming work. It’s also meaningless because lines of code doesn’t readily translate to functionality or value. Skilled programmers can produce much more code than that in a day, or less depending on circumstances, but the average will be much higher for actual coding. These days there is so much copy and paste, point and click, templates, code generators, and other super-duper tools that some programmers barely write any code at all.

BTW: I wrote tons of code in assembly language. It was a lot more fun, but without a good code base to start with something like Hello World was a lot of work.

#25

I suspect this 10 lines a day number includes the design also, not just the coding. And Barry Boehm measured a 10x difference between the best programmers and mediocre programmers in terms or productivity. (This was years ago.)
Good programmers don’t think in lines of code like good players don’t think in terms of moves. They’ve probably written code to do common functions many times, even if they are too specialized to go into libraries, and so can emit dozens of lines of code as fast as they can type. This is how productivity happens.

#26

This part is inaccurate.
The keypunchers were not in a room with the actual computer – they were in a separate room (usually nearby) with bunches of people (nearly always women) each working at their own keypunch.

The room with the big tape reels was the I/O (input/output) room, which was part of the main computer room, but often somewhat separated from the actual CPU part of the computer.

But “refrigerator sized databanks” sounds odd. That could be referring to banks of disk storage devices – they were each about refrigerator sized, but only about waist height. Usually removable disk packs (cakepans) at that time, probably. But the term “databank” didn’t really come into common use until later, when database systems started being used and multiple sunsystems would acces the same master data file(s). But by that time, much smaller DASD hardware was being used.

#28

24-hour turnaround was common in the 1960’s. Many programmers came in on graveyard shift to get faster turnaround.

In the mid-1970’s, when service bureaus were providing less than 1-hour turnaround, I had programs that needed to run standalone on IBM mainframes that might rent for almost $1000 per hour, and available on weekends or graveyard only. :eek:

Needless to say, in such conditions there was a strong incentive to catch coding or logic errors before testing. Once, interviewing for a consultant’s position in the late 1980’s, I was asked what made me special enough to get the job. I mentioned that, due to the expense and inconvenience of testing those standalone programs, I had released new versions without testing and was correct in my confidence that they were error-free. Shortly after I started this explanation it occurred to me this might not be the best response (:smack:) but I did get the job.

I think it refers to delivered lines of code. A coder might create as much undelivered code just to test the deliverable code.

And not only does a good programmer produce 100 lines in the time it takes another to write five or ten; those 100 lines might solve a problem the mediocre programmer would need a thousand lines for.

The first large computer center I visited (renting for experiments as described above) was at Firemen’s Fund headquarters near San Rafael, California. The main room was huge with many scores of disk drives and tape drives and three 370/168 consoles that looked like this one. But those very impressive-looking consoles are NOT the CPUs. The three CPUs were in an otherwise-empty locked room adjacent, and had no lights or any writing except a plaque warning that the computers were the property of the Chase Manhattan Bank of New York and could not be hypothecated. :eek:

Those were the most expensive machines I’d ever seen; seeing them silent and alone in their own locked air-conditioned room was more impressive than if they’d been the consoles with the blinking lights.

#29

Just for grins, I wrote Hello World in COBOL once. Even that was a fair amount of work for such a trivial program. IIRC it required about a half-page of code, by the time I was done with the Identification, Environment, and Data divisions. The actual Procedure division, once one actually gets that far, was reasonably brief.

ETA: Writing Hello World in assembly to run under DOS or even CP/M was relatively painless. Those systems had ready-made primitives to write messages to the terminal, without any need for any extensive code to open and close any output file or set up elaborate data structures for that, as in some other systems. I actually wrote a program like that to do something useful: Output a brief command string to the printer port to set the printer to landscape or portrait mode, which otherwise required reconfiguring the printer through its own set-up screens and rebooting the printer. The Executive Secretary who benefited this went so far as to write up a glowing letter to her bosses (two of the VP’s) about this.

#30

Though I agree with everyone else about the uselessness of “lines of code” as a metric, I got curious so ran a code analysis of a little project that I’ve been working on that’s close to done. I’ve been working on it on and off over the past 3 weeks or so. If I had to guess, I’d say I’ve spent somewhere between 4 and 7 8-hour days on it, spread out over the weeks.

Result? 450 lines of code.

Sheesh. I would have thought it was more than that. In all honesty it was fairly tricky, no real UI (which is where it’s pretty easy to get a lot of lines of code), and involved a lot of pulling-my-hair-out debugging along with starting with proof-of-concept (ie, quick and easy but not very maintainable), realizing it was going to work, so then reorganizing it into nicely-written, tiered & maintainable code.

Still, 450 lines!

#31

This reminds me of The Story of Mel, first shared on Usenet by its author, Ed Nather (<nather@astro.as.utexas.edu>), on May 21, 1983, and later published in The Jargon File. This is how his story starts (and **Voyager **may recognize the computer) …


A recent article devoted to the macho side of programming
made the bald and unvarnished statement:

    Real Programmers write in FORTRAN.

Maybe they do now,
in this decadent era of
Lite beer, hand calculators, and “user-friendly” software
but back in the Good Old Days,
when the term “software” sounded funny
and Real Computers were made out of drums and vacuum tubes,
Real Programmers wrote in machine code.
Not FORTRAN.  Not RATFOR.  Not, even, assembly language.
Machine Code.
Raw, unadorned, inscrutable hexadecimal numbers.
Directly.

Lest a whole new generation of programmers
grow up in ignorance of this glorious past,
I feel duty-bound to describe,
as best I can through the generation gap,
how a Real Programmer wrote code.
I'll call him Mel,
because that was his name.

I first met Mel when I went to work for Royal McBee Computer Corp.,
a now-defunct subsidiary of the typewriter company.
The firm manufactured the LGP-30,
a small, cheap (by the standards of the day)
drum-memory computer,
and had just started to manufacture
the RPC-4000, a much-improved,
bigger, better, faster — drum-memory computer.
Cores cost too much,
and weren't here to stay, anyway.
(That's why you haven't heard of the company,
or the computer.)
#32

He was enlisted in the Air Force, and was a noncom at the time. He’d served a tour in Vietnam, but didn’t much like it over there, and did not like being separated from his wife and child. He also did not have a college degree, and was looking around for an opportunity that would prevent his reassignment overseas.

He was very good with math, and was an excellent student, and when the chance to become a Computer Programmer opened up, he dived on it. It’s my understanding that they taught him the basics, but then he spent several years sitting at a desk, staring at a legal pad…

#33

I stand corrected. But I did not say he was in the room with the computers; he specifically told me he was NOT. He worked in what would be called a “cube farm” today, except that cubes hadn’t been invented yet. He said the room reminded him of a secretarial pool, because they all had big rectangular wooden desks… for nothing but legal pads and pencils. And yes, his immediate supervisor had no earthly idea what they were doing; he was NOT a computer guy, and was irritated as all hell that he was responsible for what they were doing, despite knowing zero ABOUT it…

This is all secondhand; I learned everything I’m spouting off about by listening to him reminisce to his granddaughter, several years ago. That, and among his personal effects is a tape reel the size of a dinner plate, of the sort often seen twirling in the background in James Bond movies…

#34

There’s no reason the keypunch couldn’t have been in the computer room. The computer room would have required heavy duty air-conditioning and keypunch machines didn’t so they usually wouldn’t be located there. But in many computer rooms there was at least one keypunch to use for various purposes. I worked at one place that had equipment shoved into any place it would fit. A complete run of their payroll required taking boxes full of punched cards from one room to another to sort them initially, then after processing duplicate them, and then put them through another machine which would print the codes on the top line. Also, fixed disk drives were generally mounted in full size racks that would be called refrigerator sized. So his story could be accurate.

#35

The LGP-30 was the vacuum tube version of the LGP-21 I used in high school. The LGP_21 used transistors. It was slower.
Here is the LPG21 programmers manual. I have the hard copy right here in my office, liberated from school. You can see the optimum address locator, mentioned in the story, on page 8-3.
I never used that. However I did write a tic-tac-toe program that was too big to fit into the 4k memory - so I “optimized it” by modifying instructions so the same code could be used for both sides of the game. I changed adds to subtracts and vice versa if I remember correctly.

#36

Yep. One of my sisters took a programming class in the local community college in the mid-70s. They were still using flowcharts & cards.

#37

Never mind the reels of tape the size of dinner plates.

There were large multi-platter disk drives wherein each platter was large enough and thick and solid enough to make a coffee table top. That’s what the computer maintenance engineers did with them.

The picture caption (you can find it here, just scroll down a ways) says:

The entire disk drive machine itself (maybe not exactly this one, but one of that era) was bigger than a typical home refrigerator. Maybe the size of a commercial refrigerator that you might find in a restaurant.

I was a computer operator at a research facility that did classified work. Once upon a time, when one of those disks was taken out, the engineer took a platter home to make a coffee table. When the Security folks found that a platter was unaccounted for, all shit broke loose.

#38

When I was an undergrad my friend and I saw an ad in a computer magazine from a disk drive company saying that they were rigorous in their testing, and so had bad platters that they would send to you free. So we ordered one.
And one evening we rolled it down the corridors of the MIT Computer Center.
They were not pleased…

#39

I started my CS degree at UMR (now Missouri University of Science and Technology) in 1980. First year was doing Fortran on punched cards. The card reader was in the hall outside the machine room. If it was quiet you could run your cards through and immediately see the printer printing the results. From the 2nd year onward we could use the 3270 terminals.

My first job was as a COBOL programmer at an insurance company in 1985. They had only recently gone from coding forms to 3270s for the programmers. However, they didn’t have enough so there was one terminal per 2 programmers. All the source code was printed on microfiche which we each had a reader for. I’d study the source on the fiche machine, work out what changes were needed, and when it was my turn I’d get on the terminal to enter the changes.

The code I worked on was for the actuaries, so vast amounts of historical claims data to process. The master file fit on 72 reels of 9 track tape. One of the quarterly jobs required that the data be sorted in a different order. The sort job would run for over 24 hours and produce a couple hundred intermediate tapes in the process.

This week I’ve written about 10 lines of InstallShield code.