10 ms·

There's something amazing about carrying around your dot-matrix printed source code in a roller suitcase. The only thing that says "stable release" more than pr

by szczys 10y ago

There's something amazing about carrying around your dot-matrix printed source code in a roller suitcase. The only thing that says "stable release" more than printing it out on hundreds of pages of paper is launching the computer running the code into space with no hope of doing an update.

gumby 10y ago
Thats line printer output. Dot Matrix was only invented in the late 60s and in any case was too slow, being character at a time.
- jgrahamc 10y ago
  And you don't know terrifying power until you've seen a line printer going at full speed.
  - AstroJetson 10y ago
    .. or the unworldly noise that a broken chain makes as it flails itself to death.
sizzzzlerz 10y ago
Kids, today! You have no idea how lucky you are. At the time of writing this code, there were no 32" color monitors, IDEs, code text editors, or source code management systems. Code was first written out by hand and then typed onto punch cards or paper tape. These were fed into a mainframe computer for assembly. If you made a mistake, you had to find cards (by hand), remove and replace them with corrected cards. Get the cards out of order, you were toast. In general, the only way to gain a big picture of the code was to print it out, often over and over. Needless to say, paper was in huge demand.
- liotier 10y ago
  Also, for all but the richest programmers who had direct access to the computer, the typical experience was that you submitted your stack of cards at the end of the day and got a printout in the morning... Probably why my old programming teacher scorned our iterative approach to repeatedly stumbling upon syntax errors by hitting the 'compile' key and adding the missing commas.
- nervousvarun 10y ago
  Yup..."back then" you would arrange all your cards in a shoebox and then take a marker and make a diagonal mark from top left to bottom right JUST IN CASE you dropped said shoebox on the way to class to turn in your homework/take home test. Without that mark there's no easy way to recreate the correct order of the punch cards. Source: dad was an engineering major in the early 70s.
  - kjs3 10y ago
    I was an engineering major in the mid 80s. You still goddamn well did mark your card deck. Wide tip sharpie, top left to bottom right. I think they retired the punches after my freshman year or the year after.
  - punchthrowaway 10y ago
    This comment is extremely interesting to me as my first instinct would be numbering the cards w marker. But it makes far more sense to draw a line on the edge for visual sorting.
  - lettercarrier 10y ago
    And... you always kept your card decks until you graduated.
  - donarb 10y ago
    The first six columns of IBM cards used for COBOL programming had sequence numbers that could be used to validate that program lines were in order.
    - joezydeco 10y ago
      I'm curious what % of HN readers have ever written a program with line numbers...
      - Zardoz84 10y ago
        ZX Spectrum +3 user here
- lettercarrier 10y ago
  Since each punch card meant something, you really learned code. Watching out for memory and keeping track of registers was paramount (COMPASS was my HS and Freshman initial class). Syntax killed, but was overcome by hand writing code. The science of CPS courses had to be taught just to be able to pass the class via assignments. Writing an OS with punch cards was an entire term. We could get same day runs if we paid more or had our own account. There were 3 tiers of cost..
- woofyman 10y ago
  I'm 57 and a working developer. In school, It was a beautiful feeling if your card deck compiled, ran, didn't run out of CPU time, and produced the correct print out, the very first time.
  - kjs3 10y ago
    It was. But then (in my world) they replaced punched cards with Ada, which wouldn't compile anything until everything was correct. Those rare times when you actually thought long and hard enough to get everything right the first time or two...priceless. This was not a bad thing.
  - shitgoose 10y ago
    never happened to me:) most of the time i used to receive my deck wrapped in thin printout with some compilation error.
- shitgoose 10y ago
  yep. that's why things used to work back then - because people actually were thinking about what they were doing.
Arnavion 10y ago
>with no hope of doing an update To be fair, space probes occasionally do get software updates, eg http://blogs.esa.int/rosetta/2014/03/28/software-upgrade-at-655-million-kilometres/ http://blogs.esa.int/rosetta/2014/03/28/software-upgrade-at-... In the case of the Curiosity Rover, it didn't even "ship" with the software of what it was supposed to do on Mars until it had landed there http://www.space.com/17034-mars-rover-curiosity-software-upgrade.html http://www.space.com/17034-mars-rover-curiosity-software-upg... Edit: I'm not saying this was possible in 1969. I posted this because I was genuinely curious if it was ever done.
- szczys 10y ago
  Yeah, I know the modern era machines have in-the-field updates, but I assume that wasn't a feature on the Lunar Module. You need a device capable of self-programming and with the state and cost of memory at the time I would think that an impossibility at the time.
  - Bromskloss 10y ago
    We'll just include a little robot that can rethread the core rope memory!
- lisper 10y ago
  > space probes occasionally do get software updates Sure. In 2014. Not in 1969. I once had the very interesting experience of developing an in-place update for a mid-1980s-vintage spacecraft instrument: the magnetometer on the Galileo spacecraft. It used an 1802 processor with 2k bytes of memory and was programmed in Forth. The development system ran on an Apple II. The instrument developed a bad byte of RAM and so a patch had to be developed, but the Apple II that ran the Forth compiler had long since been decommissioned. (It was nine years between when the spacecraft was completed and when it arrived at Jupiter, three of which were a delay caused by the Challenger explosion.) I ended up writing a complete 1802 emulator and new Forth development environment that was able to compile the original source code and reproduce what was then running on the instrument. That code ran in Common Lisp on a Macintosh II. Using that new development system, I produced a patch, which was only about a dozen bytes long. It was quite an inexpensive project by NASA standards (took about three months from start to finish with just me working on it) but the cost per byte of output code was pretty staggering :-)

by szczys 10y ago

gumby 10y ago

Thats line printer output. Dot Matrix was only invented in the late 60s and in any case was too slow, being character at a time.

jgrahamc 10y ago
And you don't know terrifying power until you've seen a line printer going at full speed.
- AstroJetson 10y ago
  .. or the unworldly noise that a broken chain makes as it flails itself to death.

sizzzzlerz 10y ago

Kids, today! You have no idea how lucky you are. At the time of writing this code, there were no 32" color monitors, IDEs, code text editors, or source code management systems. Code was first written out by hand and then typed onto punch cards or paper tape. These were fed into a mainframe computer for assembly. If you made a mistake, you had to find cards (by hand), remove and replace them with corrected cards. Get the cards out of order, you were toast. In general, the only way to gain a big picture of the code was to print it out, often over and over. Needless to say, paper was in huge demand.

liotier 10y ago
Also, for all but the richest programmers who had direct access to the computer, the typical experience was that you submitted your stack of cards at the end of the day and got a printout in the morning... Probably why my old programming teacher scorned our iterative approach to repeatedly stumbling upon syntax errors by hitting the 'compile' key and adding the missing commas.
nervousvarun 10y ago
Yup..."back then" you would arrange all your cards in a shoebox and then take a marker and make a diagonal mark from top left to bottom right JUST IN CASE you dropped said shoebox on the way to class to turn in your homework/take home test. Without that mark there's no easy way to recreate the correct order of the punch cards. Source: dad was an engineering major in the early 70s.
- kjs3 10y ago
  I was an engineering major in the mid 80s. You still goddamn well did mark your card deck. Wide tip sharpie, top left to bottom right. I think they retired the punches after my freshman year or the year after.
- punchthrowaway 10y ago
  This comment is extremely interesting to me as my first instinct would be numbering the cards w marker. But it makes far more sense to draw a line on the edge for visual sorting.
- lettercarrier 10y ago
  And... you always kept your card decks until you graduated.
- donarb 10y ago
  The first six columns of IBM cards used for COBOL programming had sequence numbers that could be used to validate that program lines were in order.
  - joezydeco 10y ago
    I'm curious what % of HN readers have ever written a program with line numbers...
    - Zardoz84 10y ago
      ZX Spectrum +3 user here
lettercarrier 10y ago
Since each punch card meant something, you really learned code. Watching out for memory and keeping track of registers was paramount (COMPASS was my HS and Freshman initial class). Syntax killed, but was overcome by hand writing code. The science of CPS courses had to be taught just to be able to pass the class via assignments. Writing an OS with punch cards was an entire term. We could get same day runs if we paid more or had our own account. There were 3 tiers of cost..
woofyman 10y ago
I'm 57 and a working developer. In school, It was a beautiful feeling if your card deck compiled, ran, didn't run out of CPU time, and produced the correct print out, the very first time.
- kjs3 10y ago
  It was. But then (in my world) they replaced punched cards with Ada, which wouldn't compile anything until everything was correct. Those rare times when you actually thought long and hard enough to get everything right the first time or two...priceless. This was not a bad thing.
- shitgoose 10y ago
  never happened to me:) most of the time i used to receive my deck wrapped in thin printout with some compilation error.
shitgoose 10y ago
yep. that's why things used to work back then - because people actually were thinking about what they were doing.

Arnavion 10y ago

>with no hope of doing an update To be fair, space probes occasionally do get software updates, eg http://blogs.esa.int/rosetta/2014/03/28/software-upgrade-at-655-million-kilometres/ http://blogs.esa.int/rosetta/2014/03/28/software-upgrade-at-... In the case of the Curiosity Rover, it didn't even "ship" with the software of what it was supposed to do on Mars until it had landed there http://www.space.com/17034-mars-rover-curiosity-software-upgrade.html http://www.space.com/17034-mars-rover-curiosity-software-upg... Edit: I'm not saying this was possible in 1969. I posted this because I was genuinely curious if it was ever done.

szczys 10y ago
Yeah, I know the modern era machines have in-the-field updates, but I assume that wasn't a feature on the Lunar Module. You need a device capable of self-programming and with the state and cost of memory at the time I would think that an impossibility at the time.
- Bromskloss 10y ago
  We'll just include a little robot that can rethread the core rope memory!
lisper 10y ago
> space probes occasionally do get software updates Sure. In 2014. Not in 1969. I once had the very interesting experience of developing an in-place update for a mid-1980s-vintage spacecraft instrument: the magnetometer on the Galileo spacecraft. It used an 1802 processor with 2k bytes of memory and was programmed in Forth. The development system ran on an Apple II. The instrument developed a bad byte of RAM and so a patch had to be developed, but the Apple II that ran the Forth compiler had long since been decommissioned. (It was nine years between when the spacecraft was completed and when it arrived at Jupiter, three of which were a delay caused by the Challenger explosion.) I ended up writing a complete 1802 emulator and new Forth development environment that was able to compile the original source code and reproduce what was then running on the instrument. That code ran in Common Lisp on a Macintosh II. Using that new development system, I produced a patch, which was only about a dozen bytes long. It was quite an inexpensive project by NASA standards (took about three months from start to finish with just me working on it) but the cost per byte of output code was pretty staggering :-)