4 ms·

I'm glad I learned to program using punched cards, in a batch-job system. At my university, the local (IBM 1130) machine was used during the day to send jobs t

I'm glad I learned to program using punched cards, in a batch-job system. At my university, the local (IBM 1130) machine was used during the day to send jobs to a larger (IBM 360?) machine at an affiliate university. The turnaround from putting cards in the output tray and getting output was often over an hour, since a local operator sent jobs in groups, and separated printouts only when there was enough paper to justify interrupting her other work. The whole computer system was behind locked doors, and this operator was like a god who took our offerings and bestowed her blessings when she felt like doing so. Past 6PM or so, the local machine was available only to researchers, who worked through the night. I think the weekend was also dedicated to local research, so mere mortals (undergraduates) like me did not get a lot of chances to meet our deadlines. The upshot of these restrictions is that code often worked the first time. You didn't write it on coding sheets until your logic made sense. And you didn't punch cards from those sheets until you had gone through them again, and were sure not just on the logic but the variable spelling, etc. Then you punched the cards. Then you worked through the deck, one by one, imagining yourself to be the machine. Every extra hour spent this way increased your chance of getting results before the end of day. The difficulty of the process led to good habits.

caspper69 7y ago
Habits that could shave 4/5ths off of our existing software stack if you ask me.
okal 7y ago
I find this… interesting. I mean, yes, think about your problems up front, but a computer will always be a better computer than a programmer would. How do slow feedback cycles make one a better programmer? In what ways do you find that these habits serve you well now? Is, for instance, painstakingly checking variable spelling an interesting (or valuable) use of a programmer's time, when it can be handled by automated tooling?
- pjmorris 7y ago
  My impression of how slow feedback cycles make for better programmers is that habits of careful thought are developed because the cost of waiting is so high. The following are anecdotes, not data, but consider their sources: "When I learned to program, you were lucky if you got five minutes with the machine a day. If you wanted to get the program going, it just had to be written right. So people just learned to program like it was carving stone. You sort of have to sidle up to it. That's how I learned to program." - Don Knuth [0] "Before I sit down to code something, most of the instructions have already run through my head. It’s not all laid out perfectly, and I do find myself making changes, but all the good ideas have occurred to me before I actually write the program. And if there is a bug in the thing, I feel pretty bad, because if there’s one bug, it says your mental simulation is imperfect. And once your mental simulation is imperfect, there might be thousands of bugs in the program. I really hate it when I watch some people program and I don’t see them thinking." - Bill Gates [1] [0] http://www.softpanorama.org/People/Knuth/index.shtml http://www.softpanorama.org/People/Knuth/index.shtml [1] https://programmersatwork.wordpress.com/bill-gates-1986/ https://programmersatwork.wordpress.com/bill-gates-1986/
  - graycat 7y ago
    Along those lines, in the Kemeny-Kurtz documentation for their original Basic from Dartmouth college on GE hardware, there was a remark "Typing is no substitute for thinking."
- CarVac 7y ago
  > In what ways do you find that these habits serve you well now? It doesn't help now, it helps you get better for the future. This is something in photography: if you lengthen the feedback cycle, you are forced to build a stronger mental model of the behavior of the camera. With film, you had to see whether the exposure was right well after the fact. With digital, you could see right away and take another shot after adjusting. With live view, you can fix exposure before taking the shot. Which teaches you more? If you always have exposure preview, you blindly learn to adjust the exposure compensation knob until the exposure is good, and there's no learning forced upon you. With film, when I would mess up exposure, I would find out a week later and feel intense regret: "Damn, in that situation I should have used positive exposure compensation." This leads to me, having understood the system better and internalized it, being able to anticipate what exposure comp I need ahead of time. Basically, if there's nothing (or less) lost as a result of a mistake, you won't learn as quickly.
  - uxp100 7y ago
    I'm going to make a little stretch here, just bullshit really, but: There is no (conventional) way to lengthen the feedback cycle when playing a musical instrument. It is immediate. But beginning jazz piano soloists are often taught to vocalize their lines as they play. This clarifies your goals, and keeps you from aimless noodling that is in key, but lacks a pull towards something (which is how I play, since I have shit pitch memory and perception). I guess I'd draw the connection to writing tests before implementation. And then to extend out a little further, as you become experienced and have internalized what your instrument will sound like, this habit could hold you hold you back from truly free expression, not that anyone wants that in my code.
    - CarVac 7y ago
      On the other hand, personally when playing music I don't perceive any feedback on the more subtle aspects unless I make blatant mistakes. Intonation and bowing on cello, unwanted accents on piano. These are only revealed fully when I record myself. And regardless of how short or long he feedback loop is, listening to a recording of my own mistakes when playing is sufficiently traumatic for me to make for a strong learning experience.
- asdfman123 7y ago
  Have you ever heard teachers say that they don't allow cheat sheets on tests because students learn the material better without them? Have you ever studied for a test and REALLY mastered the material, and walked away with the feeling that you know it inside and out? It's actually a great feeeling. Alternatively, have you ever managed to squeak and get a decent grade despite the fact you only partially knew the material but had prepared a good enough cheat sheet? I feel like code completion, fast compilers, and debuggers are one big cheat sheet.
asdfman123 7y ago
As a younger developer, I feel like I would have enjoyed the work of writing code for those sorts of machines more. These days it's just too easy to throw a bunch of junk at the wall and seeing what sticks. I would have loved to be able to slow down, have an incentive to really know my stuff, think through all the possibilities and write out a few lines of beautiful, efficient code. I suppose I can still do that with discipline -- but it's too easy to lean on the debugger, and even if you want your code to be clean, the codebase you're working on isn't necessarily going to be.
- SilasX 7y ago
  Sorry for the plug, but you can kind of simulate that process in the nand2tetris.org course (also available on Coursera). In that course, you build a computer (through hardware simulators) that can run binary programs. Then you build up a programming toolchain: stack based virtual machine language that compiles to assembly, and a high level language that you compile to the VM language. You also write the assembler that translates your assembly into ones and zeros, which are like the punch cards. So you can simulate what it's like to be writing the binaries: if you take out the compilers, you can go through the process of manually translating your high level code into punchcards. The high-level lines become stack operations, which become assembly commands, which become binary words. (For efficiency reasons, you'd probably program directly in assembly where possible, but you can add on the abstraction levels.)
  - asdfman123 7y ago
    That sounds like a great course. Plugs are welcome when they benefit the readers -- they're only bad when they only benefit the authors.
    - SilasX 7y ago
      Fair enough. I was just worried that HNers might feel that that course gets promoted too much here. (IMHO, nand2tetris deserves that level of promotion! I just recently gave a talk about it for the Austin Python meetup.)
DannyB2 7y ago
I also learned on an IBM 1130. At the very end of the era of punched cards. With 029 keypunch. During my 1st semester a new (not IBM) minicomputer with two CRT terminals was installed. Macros had been written on the new system by school staff so that you could change a few control cards and run your existing deck on the new system. Some people would run their jobs on the 1130, but you had a choice. The new system had a very small tabletop high speed punched card reader. Had a huge fan that blew air through the deck causing all the cards to separate and the weight on top of the cards to lift. It was fun to watch the deck "expand" like a blown up balloon. It could not read card at a time. It read in the entire stack of loaded cards at very high speed and spooled it to disk. These jobs ran (up to 3 concurrently) in background, along with any interactive CRT users. Then printout of your job would come out on a printer that was way faster than the printer on the 1130. Some people stuck with the 1130 because there were minor differences in the compilers. So it wasn't necessarily magically transparent to run your job on the new system by just swapping a few cards. There were initially two interactive CRT terminals. (Beehive) I asked a lot of annoying questions. There was now about three feet of manuals bolted to a table in the keypunch room. I made a point of reading it. After more questions, I was able to log in using an interactive terminal. I was encouraged. I was surprised that very few people expressed any interest in doing this. I could type my code into a file. Compile and run it. Send my printout to the printer. Come back to terminal, edit some more, etc. Fast turnaround. No more throwing out an entire card over a single character typo. People who watched over my shoulder became interested. I showed a few people how to edit, and compile and run their programs, spool to printer, etc. Soon there were sign up sheets for 30 minute blocks on the two CRTs. In the 2nd semester the school realized they needed more CRT terminals and fast. Some people did continue to use keypunch and cards because those were now less in demand and often not in use. Those were fun days.

caspper69 7y ago

Habits that could shave 4/5ths off of our existing software stack if you ask me.

okal 7y ago

I find this… interesting. I mean, yes, think about your problems up front, but a computer will always be a better computer than a programmer would. How do slow feedback cycles make one a better programmer? In what ways do you find that these habits serve you well now? Is, for instance, painstakingly checking variable spelling an interesting (or valuable) use of a programmer's time, when it can be handled by automated tooling?

pjmorris 7y ago
My impression of how slow feedback cycles make for better programmers is that habits of careful thought are developed because the cost of waiting is so high. The following are anecdotes, not data, but consider their sources: "When I learned to program, you were lucky if you got five minutes with the machine a day. If you wanted to get the program going, it just had to be written right. So people just learned to program like it was carving stone. You sort of have to sidle up to it. That's how I learned to program." - Don Knuth [0] "Before I sit down to code something, most of the instructions have already run through my head. It’s not all laid out perfectly, and I do find myself making changes, but all the good ideas have occurred to me before I actually write the program. And if there is a bug in the thing, I feel pretty bad, because if there’s one bug, it says your mental simulation is imperfect. And once your mental simulation is imperfect, there might be thousands of bugs in the program. I really hate it when I watch some people program and I don’t see them thinking." - Bill Gates [1] [0] http://www.softpanorama.org/People/Knuth/index.shtml http://www.softpanorama.org/People/Knuth/index.shtml [1] https://programmersatwork.wordpress.com/bill-gates-1986/ https://programmersatwork.wordpress.com/bill-gates-1986/
- graycat 7y ago
  Along those lines, in the Kemeny-Kurtz documentation for their original Basic from Dartmouth college on GE hardware, there was a remark "Typing is no substitute for thinking."
CarVac 7y ago
> In what ways do you find that these habits serve you well now? It doesn't help now, it helps you get better for the future. This is something in photography: if you lengthen the feedback cycle, you are forced to build a stronger mental model of the behavior of the camera. With film, you had to see whether the exposure was right well after the fact. With digital, you could see right away and take another shot after adjusting. With live view, you can fix exposure before taking the shot. Which teaches you more? If you always have exposure preview, you blindly learn to adjust the exposure compensation knob until the exposure is good, and there's no learning forced upon you. With film, when I would mess up exposure, I would find out a week later and feel intense regret: "Damn, in that situation I should have used positive exposure compensation." This leads to me, having understood the system better and internalized it, being able to anticipate what exposure comp I need ahead of time. Basically, if there's nothing (or less) lost as a result of a mistake, you won't learn as quickly.
- uxp100 7y ago
  I'm going to make a little stretch here, just bullshit really, but: There is no (conventional) way to lengthen the feedback cycle when playing a musical instrument. It is immediate. But beginning jazz piano soloists are often taught to vocalize their lines as they play. This clarifies your goals, and keeps you from aimless noodling that is in key, but lacks a pull towards something (which is how I play, since I have shit pitch memory and perception). I guess I'd draw the connection to writing tests before implementation. And then to extend out a little further, as you become experienced and have internalized what your instrument will sound like, this habit could hold you hold you back from truly free expression, not that anyone wants that in my code.
  - CarVac 7y ago
    On the other hand, personally when playing music I don't perceive any feedback on the more subtle aspects unless I make blatant mistakes. Intonation and bowing on cello, unwanted accents on piano. These are only revealed fully when I record myself. And regardless of how short or long he feedback loop is, listening to a recording of my own mistakes when playing is sufficiently traumatic for me to make for a strong learning experience.
asdfman123 7y ago
Have you ever heard teachers say that they don't allow cheat sheets on tests because students learn the material better without them? Have you ever studied for a test and REALLY mastered the material, and walked away with the feeling that you know it inside and out? It's actually a great feeeling. Alternatively, have you ever managed to squeak and get a decent grade despite the fact you only partially knew the material but had prepared a good enough cheat sheet? I feel like code completion, fast compilers, and debuggers are one big cheat sheet.

asdfman123 7y ago

As a younger developer, I feel like I would have enjoyed the work of writing code for those sorts of machines more. These days it's just too easy to throw a bunch of junk at the wall and seeing what sticks. I would have loved to be able to slow down, have an incentive to really know my stuff, think through all the possibilities and write out a few lines of beautiful, efficient code. I suppose I can still do that with discipline -- but it's too easy to lean on the debugger, and even if you want your code to be clean, the codebase you're working on isn't necessarily going to be.

SilasX 7y ago
Sorry for the plug, but you can kind of simulate that process in the nand2tetris.org course (also available on Coursera). In that course, you build a computer (through hardware simulators) that can run binary programs. Then you build up a programming toolchain: stack based virtual machine language that compiles to assembly, and a high level language that you compile to the VM language. You also write the assembler that translates your assembly into ones and zeros, which are like the punch cards. So you can simulate what it's like to be writing the binaries: if you take out the compilers, you can go through the process of manually translating your high level code into punchcards. The high-level lines become stack operations, which become assembly commands, which become binary words. (For efficiency reasons, you'd probably program directly in assembly where possible, but you can add on the abstraction levels.)
- asdfman123 7y ago
  That sounds like a great course. Plugs are welcome when they benefit the readers -- they're only bad when they only benefit the authors.
  - SilasX 7y ago
    Fair enough. I was just worried that HNers might feel that that course gets promoted too much here. (IMHO, nand2tetris deserves that level of promotion! I just recently gave a talk about it for the Austin Python meetup.)

DannyB2 7y ago

I also learned on an IBM 1130. At the very end of the era of punched cards. With 029 keypunch. During my 1st semester a new (not IBM) minicomputer with two CRT terminals was installed. Macros had been written on the new system by school staff so that you could change a few control cards and run your existing deck on the new system. Some people would run their jobs on the 1130, but you had a choice. The new system had a very small tabletop high speed punched card reader. Had a huge fan that blew air through the deck causing all the cards to separate and the weight on top of the cards to lift. It was fun to watch the deck "expand" like a blown up balloon. It could not read card at a time. It read in the entire stack of loaded cards at very high speed and spooled it to disk. These jobs ran (up to 3 concurrently) in background, along with any interactive CRT users. Then printout of your job would come out on a printer that was way faster than the printer on the 1130. Some people stuck with the 1130 because there were minor differences in the compilers. So it wasn't necessarily magically transparent to run your job on the new system by just swapping a few cards. There were initially two interactive CRT terminals. (Beehive) I asked a lot of annoying questions. There was now about three feet of manuals bolted to a table in the keypunch room. I made a point of reading it. After more questions, I was able to log in using an interactive terminal. I was encouraged. I was surprised that very few people expressed any interest in doing this. I could type my code into a file. Compile and run it. Send my printout to the printer. Come back to terminal, edit some more, etc. Fast turnaround. No more throwing out an entire card over a single character typo. People who watched over my shoulder became interested. I showed a few people how to edit, and compile and run their programs, spool to printer, etc. Soon there were sign up sheets for 30 minute blocks on the two CRTs. In the 2nd semester the school realized they needed more CRT terminals and fast. Some people did continue to use keypunch and cards because those were now less in demand and often not in use. Those were fun days.