4 ms·

My father used to be a programmer back in the 1960's for the IBM 700 series mainframes, writing programmes and simulations in FORTRAN 4 (and I think some assemb

by Qasaur 6y ago

My father used to be a programmer back in the 1960's for the IBM 700 series mainframes, writing programmes and simulations in FORTRAN 4 (and I think some assembler, too) for our now-defunct shipbuilding industry (Sweden). The stories he told me about how debugging back then included manually going through series upon series of punchcards (often by laying them out on the floor in his house and crawling while reading) humbles me somewhat to how far we've come in the industry where debugging something is as easy as pressing a button and getting instant feedback. Back then results from a compute had to be processed overnight even for relatively simple programmes. One thing we've seemed to regressed on though is the professional stature of our industry - back then private offices were the norm and the Orwellian open-office hellscape of today was no where to be found.

bluenose69 6y ago
In the old days, the first step was think through the logic very carefully, because every mistake took a long time for the cards to get collected and run through the machine. Most people started by scratching their head and looking into space for a long time. Then they started drawing some sketches of flow (maybe with flowcharts, but often not doing that formally). Then they wrote out the code on coding sheets that had columns matching the columns on cards. Then they spent time reading the code and thinking like the machine. Only then were cards punched. And those cards were certainly checked for typos before submitting the job. This was all because the turnaround was so slow. Another fun card fact was that most people drew diagonal lines on their card decks, so you could more easily put them in order if they got scrambled. The consequence of all of this is that debugging cards was actually not all that common, because you were doing checks at all the preliminary steps. This was all quite fun, actually. Think of driving a standard-shift car, compared with an automatic.
- majewsky 6y ago
  > Most people started by scratching their head and looking into space for a long time. Then they started drawing some sketches of flow (maybe with flowcharts, but often not doing that formally). Then they wrote out the code on coding sheets that had columns matching the columns on cards. Then they spent time reading the code and thinking like the machine. This sounds a lot like how I work when writing new code that's not just a quick throw-away script, but built to last. If implementing a new feature takes me one week, then the first one is usually spent just reading the existing code and thinking about the other parts of the application and environment are going to interact with the new feature. It takes more time initially, but it saves me a ton of pain down the line, and luckily my managers appreciate that trade-off as much as I do.
- wazoox 6y ago
  Ah yes. I remember an article talking about how Jean Ichbiah programmed, and his card decks were always right at first run even when writing awfully complex programs :)
grishka 6y ago
Interesting. But then, what those consoles with lots of lights and buttons were for? They definitely do look like they display the CPU state, allow control over it, and just in general are hardware precursors of today's debuggers.

by Qasaur 6y ago

bluenose69 6y ago

In the old days, the first step was think through the logic very carefully, because every mistake took a long time for the cards to get collected and run through the machine. Most people started by scratching their head and looking into space for a long time. Then they started drawing some sketches of flow (maybe with flowcharts, but often not doing that formally). Then they wrote out the code on coding sheets that had columns matching the columns on cards. Then they spent time reading the code and thinking like the machine. Only then were cards punched. And those cards were certainly checked for typos before submitting the job. This was all because the turnaround was so slow. Another fun card fact was that most people drew diagonal lines on their card decks, so you could more easily put them in order if they got scrambled. The consequence of all of this is that debugging cards was actually not all that common, because you were doing checks at all the preliminary steps. This was all quite fun, actually. Think of driving a standard-shift car, compared with an automatic.

majewsky 6y ago
> Most people started by scratching their head and looking into space for a long time. Then they started drawing some sketches of flow (maybe with flowcharts, but often not doing that formally). Then they wrote out the code on coding sheets that had columns matching the columns on cards. Then they spent time reading the code and thinking like the machine. This sounds a lot like how I work when writing new code that's not just a quick throw-away script, but built to last. If implementing a new feature takes me one week, then the first one is usually spent just reading the existing code and thinking about the other parts of the application and environment are going to interact with the new feature. It takes more time initially, but it saves me a ton of pain down the line, and luckily my managers appreciate that trade-off as much as I do.
wazoox 6y ago
Ah yes. I remember an article talking about how Jean Ichbiah programmed, and his card decks were always right at first run even when writing awfully complex programs :)

grishka 6y ago

Interesting. But then, what those consoles with lots of lights and buttons were for? They definitely do look like they display the CPU state, allow control over it, and just in general are hardware precursors of today's debuggers.