I took my my first programming courses in college in 1964. I was an astronomy student, and all science majors at the time were required to know the FORTRAN programming language. FORTRAN was a means of coding up algebraic formulas (FORmula TRANslation). It consisted of statements (a single line of code) that looked very similar to algebraic equations, interspersed with statements that managed memory, Input/Output operations, communication of the program with the computer’s operating system, and Control Statements, a set of Boolean and Logical operators that allowed you to loop, compare, make decisions, jump in and out of sections of code, and other “control” functions. FORTRAN, like all computer languages, could call, or invoke, other programs called subroutines, which either you provided with your program, or which your program could access from a shared library in the Computer center.
The physical act of writing a computer program involved diagramming it as a flowchart, coding it up on paper forms, and then punching it up into 80 column records on paper tape, or IBM cards, with one FORTRAN statement per record. A stack of these cards (or a strip of tape) was a program, and programs were stacked up on a hopper and read into a computer, I used a PDP-9 (a small, room-sized machine) or the University’s IBM System 360, a huge installation that filled up an entire floor of the Science Center.
The programming environment at the time was called batch processing. The term came from the fact that programs were fed into computers in batches, one after another. You handed your deck of cards to a tech (wrapped together with a rubber band) with a few cards in front and back written in IBM Job Control Language (JCL), which alerted the computer who you were, who your job was being billed to, and what memory files and I/O devices your program would need to access when it executed. These were stacked into a hopper and the card reader would swallow them up and spit them out. The next day, you would pick up your card deck wrapped in a printout containing your results (if it ran) or a series of impenetrable error messages if you screwed up.
What happened behind that counter was all a mystery. This is all I knew. The cards with my program were read, converted to machine language (a process called compilation) and the computer would access all the pre-written subroutines I needed from the computer library, (a process called linking). For example, I didn’t need to write a program to do a least squares analysis if I needed one, the Center already had a very good one available). All I had to do was provide that routine with coded instructions (in my program) to call that routine, and give it the parameters I wanted, on what device to find my data, and on which device to write the results.
The final program, compiled and linked into assembly language, now went on a queue and waited for its turn to execute, along with a batch of other programs. After it ran, the tech would match my cards with my printout and stick it in my mailbox.
Batch programs were not interactive, they didn’t ask you questions and accept your responses before proceeding for further processing. You could not communicate with the software while it executed. It was on its own. Programs ran, printed up their results, perhaps wrote data to computer memory or tapes for later use, and then stopped. All without human intervention or control. If a mistake ocurred, you had to locate it, correct your code, and re-run the process all over again. With a turn-around time of 12 to 24 hours, it could takes hundreds of man-hours of work to write a big program, and months to debug it and optimize it. And of course, at any one time, you might have dozens of programs at different stages of development in the pipeline. There was no interactive programming, no graphical user interfaces, no monitors and no keyboards (except for the card keypunch). That was stuff we read about in the trade papers, or saw in 2001: A Space Odyssey.
Besides my own software courses, I used FORTRAN to work on problems for my astronomy, math and physics classes, and I also worked on computational aspects of research projects with my professors (none of the older ones knew how to program, or cared for it even when they knew how). I also had a part-time job in the Engineering Department as a student assistant, helping students debug their programs.
Besides FORTRAN, I also took a course in COBOL (Common Business Oriented Language) but it was too cumbersome for scientific work, so I specialized in the former. In the parlance of the day, I was called an applications programmer, because I wrote applications, not systems, software. By the time I graduated in 1971, I was a pretty damned good scientific/engineering applications programmer.