Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Government Programming United Kingdom

One-a-Day-Compiles: Good Enough For Government Work In 1983 230

Posted by Unknown Lamer from the could-have-had-a-lisp-machine dept.
theodp (442580) writes "Simon Allardice takes a stroll down coding memory lane, recalling that when he got started in programming in 1983, hand-writing one's programs with pencil on IBM coding sheets was still considered good enough for British government work (COBOL, Assembler forms). Allardice writes, 'And when you were finished handwriting a section of code — perhaps a full program, perhaps a subroutine — you'd gather these sheets together (carefully numbered in sequence, of course) and send them along to the folks in the data entry department. They'd type it in. And the next day you'd get a report to find out if it compiled or not. Let me say that again: the next day you could find out if your code compiled or not.' So, does anyone have 'fond' memories of computer programming in the punched card era? And for you young'uns, what do you suppose your C++ or Java development times would be like if you got one compile a day?" The other way you could program in 1983.
This discussion has been archived. No new comments can be posted.

One-a-Day-Compiles: Good Enough For Government Work In 1983 More

One-a-Day-Compiles: Good Enough For Government Work In 1983

Comments Filter:

  • In the late 70s (Score:2, Informative)

    by Anonymous Coward

    We started with two languages. One was APL\360 which was interactive and fast for debugging. The other was FORTRAN IV on punched cards, which was an overnight batch sort of thing. I still think APL was far better, once you could wrap your head around the mathematical details it entailed. With APL, it was always better and faster (in programmer time and processor time) to work in parallel with array operations than to break them into loops of scalar operations like you'd have to do with FORTRAN..

    • Re:In the late 70s (Score:5, Insightful)

      by Arnold Reinhold ( 539934 ) on Wednesday April 30, 2014 @12:21PM (#46881183) Homepage
      The punched card era ended for me in 1975, when I started working on Data General Nova minicomputers at Computervision. But I spend more than a decade before that with cards and keypunch machines. I never let anyone else punch in my programs, as I usually found some errors when I typed them in myself. Card decks weren't dropped often and it wasn't that big a deal. Dropping a deck is not an effective way to shuffle it. I'm more nervous about my online source files being munged by accident. The overnight or 24 hour turnaround was common, but possible to work around. I spend many nights after mid-night at the MIT computer center in the late 1960s, when hour or even half hour turnarounds were possible. One spent the time waiting socializing or helping others find their bugs. During summer jobs at NASA MSC, I found a Honeywell 316 that wasn't being used much and could get time on it all to myself when needed. In the early 1970s my employer had an IBM 1130 and we took turns using it, so turnaround was not an issue there, though it could be when software was to be installed at a client. Finding ways to get around obstacles in your path was a valuable skill then as now.
      • Actually, Data General had a line of card punch and reader machines (I think they were OEM'ed, though) in the late 70s. I know because I was DG Field Engineer and had to work on those during election cycles. That's why I knew what "hanging-chad" was very early in the 2000 election fru-fru.

  • ah, those were the daze;-) (Score:4, Funny)

    by airdrummer ( 547536 ) <air_drummer @ v e r i z o n . n et> on Wednesday April 30, 2014 @11:28AM (#46880429)

    i started on punchcards in college on a cdc mainframe: drop the deck in the tray outside the machine room, operator periodically runs them, puts the output in the out tray, hours later...

    i improved my turnaround by dating 1 of the operators;-)

    • i started on punchcards in college on a cdc mainframe

      Me too. But that was the 1970s, not the 80s. Using punch cards in 1983 was idiotic.

      • I took a Fortran class at Virginia Tech in 1983 that used punch cards. And you couldn't run your own jobs, so it was literally the same as "one compile a day" described in the article. Drop off your deck and come back the next morning to find you had a syntax error on card 2...

        It was especially depressing since I'd been writing BASIC on an Apple ][ for years. It was probably one of the last classes that used punch cards.

        • Hey, I took that class! The professor graded you on how many runs it took you to make your program work, which he could do as all your runs had to go through him: One or two runs an A, three runs a B, four runs a C...

          • Oh, and you had to include your flowchart and coding forms. If you didn't have your flowchart and everything all properly done, it got returned unrun (but it still counted as a run for your grade).

      • i started on punchcards in college on a cdc mainframe

        Me too. But that was the 1970s, not the 80s. Using punch cards in 1983 was idiotic.

        Similar story here too, but my experience was not idiotic at all. We only had to use punch cards for the first homework project in the Intro to CS class. The instructor said it would help us understand why many things are the way they are, and we would have a ready supply of bookmarks for years to come. Do I need to mention that bookmarks were once pieces of paper that one stuck in a paper book? :-)

      • i started on punchcards in college on a cdc mainframe

        Me too. But that was the 1970s, not the 80s. Using punch cards in 1983 was idiotic.

        It was about 1983 that we first began to get terminals and go to online text editing, although I'd worked on a TTY-based minicomputer in college. Before that, 3 compiles a day was a VERY good day. Even after, printouts were only dumped in the bins every couple of hours and since those 3270 terminals were expensive you had to sign up for one.

        One of the largest shops in town had union keypunchers, so programmers there couldn't actually keyboard anything. I don't know how long it took for them to go interactiv

    • 1979-1980. Punched cards. CDC 7600. If one was lucky one could get time on one of the Decwriters and work interactively. Getting paper before someone stole your seat was another story. Pair programming became popular for that reason.

  • 1983 was not the "punched card era" (Score:3)

    by NotDrWho ( 3543773 ) on Wednesday April 30, 2014 @11:30AM (#46880447)

    That was in the 60's and early 70's.

    • I was going to say this too.. though it might be more accurate to call it the twilight of punched cards. The transition to using DTE was pretty close to complete though availability of terminals in some cases would see fall back to cards. Cards continued to be used for data in the business world a bit longer.

      And that Brit example does sound a bit elitist. Certainly academically you could punch up your code and toss it to the operators as much as you wanted and it would be run as other jobs permitted.

    • Depends on location and means. I took some programming classes at a NC public university in 1983 where we used punch cards for FORTRAN 77 programs which were batched and sent to the mainframe in Chapel Hiill for overnight processing. One job/run per day was normal. It paid to be a careful programmer.

    • That was in the 60's and early 70's.

      Nope. I was Computer Science in the School of Science and we used terminals, except for the first homework assignment in the Intro to CS class. They wanted us to have used punched cards once to help us better understand why some things are the way they are. However in the Computer Information Systems program in the School of Business they were still using punch cards for regular classwork in most classes. They only got to use terminals in some upper division classes.

      • Yeah, but by 1983 it was a learning exercise more than a day-to-day reality. A lot of college programs still make their students take COBOL today. But I wouldn't call 2014 "The COBOL era."

    • Punch cards were still being used as late as 1984...probably not much longer.

      I grew up in the era of punch-cards (1970's). My mother was a key-punch operator and was responsible for translating the handwritten code from the programmers as well as customer data into punched card format. It was also how and when I learned to program - I was in 4th grade and had an interest in computers. A programmer (and, department head) took interest in helping me learn. He would spend a little time with me each week t

    • Re: (Score:2)

      by Jahta ( 1141213 )

      True. But things were still pretty basic in the 1980's. On PCs compiling and linking (memory overlays anyone?) could take forever. There was a "conspiracy theory" that compiler/linker suppliers were secretly owned by coffee companies! :-)

    • Re: (Score:2)

      by Pinkfud ( 781828 )
      We still used them in 83 where I was. We had to code by hand on coding forms, then we had to make our own punch cards on IBM Model 29s. The target system, an IBM 360, had a tempermental card reader that would sometimes spew the cards all over the place. Gathering them up and resorting them was a real treat. But we did get to see if it compiled on the spot. Whether it gave the desired output, well that was another matter.

  • /android $make (Score:5, Funny)

    by pushing-robot ( 1037830 ) on Wednesday April 30, 2014 @11:30AM (#46880455)

    Let me say that again: the next day you could find out if your code compiled or not.

    So not much has changed, then.

  • Confetti on the Charles (Score:4, Interesting)

    by paiute ( 550198 ) on Wednesday April 30, 2014 @11:33AM (#46880493)
    There was a day at the end of the term when the students in a chemical engineering course (10.something) coming back over the Harvard Bridge would take the rubber bands off the stacks and stacks of punch cards accumulated while writing FORTRAN programs for the course and toss them off the bridge. There was usually a stiff breeze and the results were satisfying.

    I took an introductory version of that course. Punch a hundred cards out on the big old typewriter workstation thing. Take the stack to the computer window. Come back next day for the wide printout. Unfold and see all the fucking errors. Repeat. Repeat. Repeat. All failures separated by a day or a weekend.
    • I was at UMASS/Amherst in the 70s. I did the card deck thing for the first couple of assignments. Then I realized that the Teletype terminal in my room (yes, I was a true nerd...had my own Teletype) was connected to the very same computer that the cards were fed into. Why, I thought, couldn't I type the card images into a file from my terminal, then submit *that* as a job? Yup. Worked perfectly. I never punched another card.
  • Not that long ago, back in the 90's I worked on a project for Macintosh (not called MacOS yet) that had a minimal compile time of 12 minutes on the highest end Mac at the time (a Quadra something or other loaded to the max with RAM) and that's assuming you change one or two source files and not touch headers. Touching a header file forced a full compile and that would be 45 minutes. We ended up scheduling our compiles so that we could all play fooseball or something. Coming back to a failed compile sucked h
    • Perhaps that header did not belong in the pre-compiled headers list?

      If that was a header that everything else did in fact need then things were no different on PCs. I did cross platform work targeting PCs and Macs in the 90s. Macs usually had a slight advantage for disk based activities since they had SCSI drives at that time.

  • Carrying boxes of IBM cards to the computing center was a pain, particularly if you dropped a box before you diagnonally marked the deck.

    I was glas to get to a teletype with paper tape by the early 70s.

    • I worked on a DEC20 (god rest its blessed soul) in the early 80s and while we were all terminaled out, I would from time to time send my code to the card punch or paper tape just to annoy the operators who were still busy handling cards for the CDC Cyber.

    • What, you did not punch sequence numbers on the cards so you could drop them into the sorting machine? :-)

  • The system I administered did overnight compiles.

    It was just not grunty enough to compile during the day and do development.

  • I remember one of my Computer Architecture lecturers lamenting the end of of punchcard era.

    Gone are the days of being able to see how hard a PhD student is working by counting the boxes of punchcards in their office.

    Gone are the days when sending code to be compiled meant everyone could go to the pub.

    • Another downside I think is that when you had to use cards (or the code base was large and compiles were very slow) you put a bit more thought into the code you were submitting and probably checked it a bit more thoroughly before trying to run it.

    • Or as a physic professor I had at Virginia Tech joked... you couldn't pull out a pen knife and edit your code while stuck at a traffic light.

    • Gone are the days of your PHB using successful compiles as a performance metric.
  • When waiting for a compile, we had to make proper flowcharts for operations manual, maintenance manual, and also the prammers manual, the latter having the source code. When there was a change to any program, all needed to be updated and approved before the change was put into place. Although a compile a day seemed leisurely, there was more time for code review and complaince. I think biggest issue is the lack of code review needed. Now, people are more interested in their train of thought to correct errors

    • A build a day isn't so bad when everything you are using is fully and truly documented (with source). Nowadays, a lot of debugging involves figuring out what the libraries (and sometimes the OS) are actually doing that isn't documented so you can work around them.

    • When waiting for a compile, we had to make proper flowcharts for operations manual, maintenance manual, and also the prammers manual, the latter having the source code. When there was a change to any program, all needed to be updated and approved before the change was put into place. Although a compile a day seemed leisurely, there was more time for code review and complaince. I think biggest issue is the lack of code review needed. Now, people are more interested in their train of thought to correct errors from compiler that they do not slow down and think about what they are coding. Code reason why there are so many bugs and security holes. People need to slow down and do all the other required steps to ensure quality code.

      Agreed. Instant Gratification killed a lot of the quality-adding aspects of programming and what it didn't kill, the Ctrl-Alt-Delete method of problem solving did. At the time, resources were expensive and the cost of manpower was relatively cheap, so the programmers were allowed to be "inefficient". Now, the developers are the most expensive part of the system, we no longer work 40-hour 5-day weeks, and pre-compile code reviews, documentation and other "time-wasters" are not generally tolerated. After all,

  • I remember my first assembly class when we toggled in our initial few programs directly at the front panel of a PDP-11. (Not even really assembly at that point but direct machine instructions.) The paddle switches were in colored groups of three leading to the only really use for octal I have ever encountered: you could get very fast at reading octal and setting the switches with your index/middle/ring fingers.

  • Dead-end bureaucracy (Score:4, Insightful)

    by JDG1980 ( 2438906 ) on Wednesday April 30, 2014 @11:46AM (#46880673)

    Of course, the vast majority of people doing programming in 1983 didn't do any of this. If you count everyone who was entering any code (from "Hello World" on up), the vast majority of programmers were working on 8-bit microcomputers that didn't require jumping through any such hoops. If you had a Commodore 64, you could get a basic test program working in less than a minute:

    10 PRINT"HELLO WORLD"
    20 GOTO 10
    RUN

    Then once you figured that out you could learn about variables, figure out how to write to the screen RAM, and eventually figure out sprites. And then once you figured out that interpreted BASIC at 1 MHz wasn't fast enough to do a decent arcade game, you'd move on to assembly. I'd wager a majority of the people programming today learned in an environment like this. Edsger Dijkstra and other academic computer scientists hated BASIC, which they thought taught bad habits and caused brain damage, but they were wrong. It was this kind of hacker culture that created the flourishing IT industry we have today, not the dead-end bureaucracy represented by Thatcherite Britain.

    • I started with basic way back when I was a kid (I'm 30 now; some would say I'm still a child, but now I'm a child with arthritis and acid reflux :P), probably around 8 years old, plugging in BASIC games that I found in 321 Contact magazines. While I look at BASIC now and think, "Ugh, who would use that language", it did at least help me learn the basics of math and variables when it comes to programming, and by the time I hit college I already covered the Intro to C++ course myself quite some time before.

      If

    • Oh, Dijkstra was right about BASIC, but a lot of us managed to recover.

      • Re: (Score:3)

        by jc42 ( 318812 )

        Dijkstra was right about BASIC, but a lot of us managed to recover.

        Yeah, and I ran across part of the explanation in an earlier form that's really similar: In high school, I took several years of German and French. The teachers all commented that most of the students wrote and (occasionally;-) spoke those languages with English word order, and were obviously doing word-at-a-time translation; I was one of the few who quickly adopted non-English phrasing from these languages and sounded more like a native speaker.

        It's similarly with software. You can often identify the

    • the new generation of hobbyists were working on 8-bit microcomputers that didn't require jumping through any such hoops.

      FTFY.

      While I agree that the PC revolution was indeed a revolution that led to todays' environment, it certainly was not a "vast majority" in 1983. You didn't run a company's accounting or payroll, or design integrated chips, or CAD-CAM, or you-name-it on 8-bit computers in '83. Took a little longer than that.

      There's a reason that today's Windows kernel is designed after VMS, and that Linux, Mac OSX, iOS, and Android are all based on Unix designs. It's because that is the world the big kids programmed in,

    • Of course, the vast majority of people doing programming in 1983 didn't do any of this. If you count everyone who was entering any code (from "Hello World" on up), the vast majority of programmers were working on 8-bit microcomputers that didn't require jumping through any such hoops. If you had a Commodore 64, you could get a basic test program working in less than a minute:

      10 PRINT"HELLO WORLD"
      20 GOTO 10
      RUN

      Then once you figured that out you could learn about variables, figure out how to write to the screen RAM, and eventually figure out sprites. And then once you figured out that interpreted BASIC at 1 MHz wasn't fast enough to do a decent arcade game, you'd move on to assembly. I'd wager a majority of the people programming today learned in an environment like this. Edsger Dijkstra and other academic computer scientists hated BASIC, which they thought taught bad habits and caused brain damage, but they were wrong. It was this kind of hacker culture that created the flourishing IT industry we have today, not the dead-end bureaucracy represented by Thatcherite Britain.

      Quoting another post to get past the damn filter.

      Then once you figured that out you could learn about variables, figure out how to write to the screen RAM, and eventually figure out sprites. And then once you figured out that interpreted BASIC at 1 MHz wasn't fast enough to do a decent arcade game, you'd move on to assembly. I'd wager a majority of the people programming today learned in an environment like this. Edsger Dijkstra and other academic computer scientists hated BASIC, which they thought taught b

  • You got your compiles back the NEXT day? Bloody luxury!!

    At my high school, we had to write our own programs, punch them ourselves and submit. We then had to wait 2 days to see if they compiled!

    You young whippersnappers with your fancy "gcc" have it so much better! And get off my lawn!!!

    • Luxury. We used assembly language on the Z80 - where if you POKE'd the wrong address the OS would crash. This was before Microsoft introduced win.com which could do the crashing for you.

    • Re: (Score:2)

      by stox ( 131684 )

      I was going to write exactly this, but you beat me to it. 2 days if we were lucky.

    • Your high school had a computer that students could access during the punch card era? Bloody Luxury!

    • Re: (Score:2)

      by ctid ( 449118 )

      Two days? TWO? We would submit our cards and then wait for the lesson THE NEXT WEEK to find out if the program had compiled. To be fair, it did encourage one to try be a very, very careful programmer. The rest of you are all whippersnappers by the way.

    • Every Sunday, we had to get up at 11 oclock at night, half an hour before we went to bed,
      Hike it down to the quarry. Mine rock slabs with our bare hands,
      then break our backs chiselling marks of 1s and 0s in the stone,
      Drag the stone cards down to the beach before sunrise, where an endless sea of tiny sand crabs would scuttle over the tablets, some of them settling into the depressions of the marks.
      Then one of us on each side of the beach would wave our arms up and down and startle the crabs in just such a wa

  • Give me a few more minutes (Score:3)

    by ArhcAngel ( 247594 ) on Wednesday April 30, 2014 @11:52AM (#46880773)
    As soon as this compile of Gentoo I started in 2010 finishes I'll tell you whether I have 'fond' memories of the experience.
  • In 1972 at Adelaide University, we got 4-hour turn-around on our card decks. Half the time (at least), we got a print-out from the line printer which had two pages of octal dump centred on the location where the program bombed. So we could edit the cards and re-submit them a few times a day. We got 2-hour turn-around if we were on good terms with the girl who loaded the card batches into the reader. One good thing about the old 80-column IBM hollerith cards is that they were the best book-marks in the world

  • Let's see, when I got hired as a programmer in '80, we punched our own cards, and handed them in. As many times as we needed to. By '81? '82? We had time-shared terminals, and entered them online.

    And this was a community college in the US.

              mark

  • He told me how it was to do things by hand because programmer time was cheap and machine time was expensive.

  • My first programs were on punched cards at U.C. Berkeley in 1968. As a student I punched the cards myself. The serious programmers, like me, would stay up all night so we could get our results back in only an hour or two. Results came as 11 by 14 blue striped paper wrapped around the original deck of cards.

    Ah, I miss punched cards! They were the perfect size to fit into your breast pocket. One side was blank to write notes on; the other side had column numbers and digit numbers: columns 1-80, digits 0-9. T

  • I wrote COBOL in 1983 for the US gov't (Score:3)

    by ReallyEvilCanine ( 991886 ) on Wednesday April 30, 2014 @12:16PM (#46881119) Homepage
    Though I was primarily a SYSOP for our internal mini mainframe, I also coded for other sections. To do so we connected using dumb terminals via 300baud to a Boeing datacenter and paid for connection as well as processor time. While it was government work, Reagan was just starting to take money away from the agencies, so we were encouraged to compile and run as little as possible.

    Meanwhile, by 1983 there were a couple of COBOL packages for the Atari 800, a machine I happened to have at home. So I'd code on that, allowing me to compile, link, and execute, all in real time!! Every bit of my submitted code was fully tested. The downside was that I had to print it out and then type it back into those fucking dumb terminals where the occasional typo might slip in.

    Prior to that I had the misfortune of batch programming on punchcards, dropping off decks of cards to pick up a day or two later with greenbar printouts full of the most obnoxious fatal errors.

  • I won't run down the whole story, but my last company had a completely horrible, 100% custom, python based build system for a very large product that contained hundreds of subparts. Despite that - or perhaps because of it - I was able to easily get all the active code running from an eclipse instance, meaning that testing a code change usually required no more than republishing to an eclipse tomcat instance. You could pull the previous day's changes from all the other devs and in about a minute or two, ha

  • That was my first computer in 1979 (British Government). Not only was coding (COBOL) done on coding sheets, but you hand drew flow diagrams first before you started coding. When complete you sent the code off to be punched (onto cards) and compiled. Frustratingly the source code was only stored once one got one's first 'clean' compile. Before then one got the listing back (with compiler errors) along with the punched cards, and one had to replace the incorrect punch cards by hand. If I remember rightly, the

  • School, circa 1974. Sending off your sheets and hoping that the keypunch operators didn't get 0's and O's confused. O's were slashed, or perhaps it was the other way round. Getting your job back on music ruled paper the next week

    University. There were teletypes that you could use to get access to the ICL mainframe, but for exams you had to use punched cards, and only got 3 goes to compile and run your program. There were always queues for the big punch machines, so if you just needed one card doing, you cou

  • We preferred to use TTY paper consoles. (Don't recall the model number).

    Instead of a screen, it was just paper. You type something in on the keyboard, it would print out. You run a program, it would print out.

    Was generally a lot faster than typing in on a screen, then going to get printouts as you would immediately get printouts. Just tear off the stuff you needed.

  • I remember punching up around 200 cards and then dropping them on the floor while taking them to be submitted. I do not think I would refer to that as a fond memory however:)

  • The other way you could program in 1983.

    There were plenty of "other ways" to program in 1983 - maybe not in government departments, but the public already had the ZX80, the ZX81, the ZX Spectrum, the Vic 20, the Commodore 64, the BBC B...

  • Atari, Tandy, IBM, Apple, Wang, Sinclair, Acorn, Texas Instruments, Digital, Xerox, Toshiba, Compaq, Timex, Sun Microsystems, Epson, Osborne, Intel, Motorola, AT&T, Microsoft, Digital Research, Lotus, Watcom, and Borland are on the time phone from 1983. They want to have a word with you.

    You could buy an IBM PC and buy assemblers, COBOL, Fortran, C, C++, Pascal (including Turbo Pascal on DOS), and more for it running on a Unix system (Xenix) or DOS.

    CP/M machines from several makers including Osborne and several other micros were around before that, with Apple, Atari, Commodore, and Tandy being the big ones in the US.

    Sun had already launched the Sun-1 and in 1983 launched the Sun-2 series.

    This list could go on and on.

  • My first gig out of college was for the same University I graduated from, and I worked on a mainframe doing COBOL programming, and some scripting in a proprietary language called NATURAL which I've never seen used anywhere else, ever.

    One project I was handed was to update the 1098-T form. It's basically the IRS tax form for tuition writeoffs. Every year we had to produce a 1098-T form for every student which basically detailed what they paid in tuition. Every year the form was a little different (of course)

  • My college, in 1980, was running a Honeywell Level 2 GCOS mainframe. It had 208k of memory, and could run up to four concurrent tasks. The workstation I'm writing this post on has about 82,000 times the memory as that old beast, which physically approximated a large fridge laying on its side. The removable disk drives were sized like washing machines, had five 14-inch platters, and held 80k.

    I took some Cobol courses, using keypunch machines and Hollerith punch cards. When assignments were due, you'd oft

  • When I moved into programming, I was allowed into the datacenter after 5PM after bosses and coworkers were no longer around to complain and could submit my own decks and retreive my own reports. Two finger keypunching the code revisions was also de rigeur. I sure miss the steel forms ruler I was given after helping out after hours one night. Thankfully I still have my Green card (it is yellow) carefully re-inforeced with scotch tape (this was before duct tape became wildly popular amongst the geek set). Eye

  • We need to bring back those days of long compile times: xkcd - Compiling [xkcd.com]

  • I did my first year Computer Science in Algol W with punched cards.

    The system required a blue "ticket card" to do anything other than list your card deck. We were issued a supply of ticket cards, and could (and did) buy more at the campus bookstore. We punched our cards ourselves. We were very careful to write everything out, to walk through our programs to make sure the program was syntactically correct and might have a chance of doing what it was supposed to do before spending a ticket card to find out

    • I am pretty sure I was at the same institution as you 3 years later, and the blue "computer money" card system was still in place. We figured out a couple of hacks to it, however. One was you could re-use the computer money punch card on the faculty/administrative mainframe after using it on the student mainframe, so you could double your money (CPU time used) if you happened to know a student who'd had a summer job using the other system, not that any of us knew anyone like that of course.

      Second was, say i

  • So, does anyone have 'fond' memories of computer programming in the punched card era?

    Well, maybe not punch cards, but I certainly remember printing out code onto 132 columns green bar paper in the lab so I could go away and review it for typos and changes I wanted to make.

    Because 'keep bashing at the compiler until it runs' was way more time consuming and annoying than reviewing it on paper and identifying what you needed to be doing.

    I've certainly hand-written out code while sitting in a coffee shop based

  • You keypunched, submitted, and picked up yourself. Rates were like 1/3 during night hours, so you got more bang for your buck working overnight. They'd give you like $500 funny money for class homeowrk or a research project. This might be 2 day hours or 6 night hours. A compile and small test run might consume five computer minutes. The final project runs would use most of the time.

    We got a lab mini-computer with CRT terminals around 1976 and ended this pain.
  • Sometimes your printout came back a hundred pages thick when you were expecting ten. IBM computers would print the contents of all registers and core memory when "ABnormal END" occurred. You could sometimes diagnose your problem from this. I think you bypass this with a proper JCL/DDL command.

  • that took 36 hours to compile. We alwaya ran it on mondayd.
    SO:
    Arrive: 8:00
    Meeting 8:15 to 8:30
    Start compile 8:35
    Take long lunches, and have long nerd discussions.
    Weds. Morning, review log.
    Thurs-Fri Make fixes.

    We could have had another system and done other work for 3k a pop, but no. It was too expensive.

    Bean counters. SHeeesh.

  • You young whippersnappers get off my lawn! (Score:4, Interesting)

    by n0ano ( 148272 ) <n0ano@arrl.net> on Wednesday April 30, 2014 @01:35PM (#46882313) Homepage

    I started in 1968 at Michigan State with punch cards on a CDC 6000 mainframe, a big one, all of 65K words of memory (60 bits per word but still, that was considered big back then). As a student I was guaranteed 1 run per day and yes, even after eyeballing my programs carefully I lost many days of work due to missplaced punctuation. It's amazing what you can get used to when you have no choice.

    I remember my excitement when I was able to move to a research account from a student one. Research accounts could get as many runs as the system could turn around, typically around 4-5 per day - nirvanna! Of course, the research runs weren't guranteed so when the system got backed up (some physics professor tying up the machine for hours or down time due to HW failures) the student jobs got priority and your research job came back whenever they could get to it. I waited 2-3 days for a job more than once.

    Back to punch cards, my favorite technique was something I saw one of the FORTRAN programmers do. The technique used the fact that you could put a line number on any card and it was possible to put multiple statements on the same card. This guy ended every single card with a goto statement to the next card in the deck. As he said, the operators could drop his deck, shuffle the cards and his program would still work properly. (We really didn't like or trust the operators back then.)

  • The summer of 1978, I spend some time to convert a large Fortran program in the IBM dialect to Fortran on a Cyber mainframe. The program consisted of about 1500 punch cards. At first I would load the whole deck every time. After some time, I discovered it was possible to store the program on disk and edit them by-line using a program called Update. This still requires typing punch cards. Everytime, I checked the cards many times to make sure, I did not make any mistakes. And then it was waiting before the m

  • I had to walk in snow, both ways uphill to get my programming forms to the Data Entry folks! Then I had to trek over to the line printer and wait for my output which could take years.

  • I did Intro Computing CS 301 under Prof Mahabala in IBM 350/155 using punch cards, in 1980. Very few of the punching machines had working ribbons and working print modules. So most of our cards did not have the line printed on the top. They can only be read by a machine, some of us learned to decode the holes pencil in the character on top. We get one run a day. Undergrads are limited to six pages of 132 char fan fold computer paper per job.

    The punch card machine had a "multipunch" option to prevent the c

  • First computer virus (Score:3)

    by Yakasha ( 42321 ) on Wednesday April 30, 2014 @03:23PM (#46883517) Homepage
    Growing up, my dad liked to tell me about one of the first computer viruses he & his classmates thought of in college.

    It was a piece of string tied across a hallway that waited for programmers carrying carefully ordered (and hopefully for their sake, numbered) stacks of punch cards.

    It replicated and evolved by way of angry programmers getting back at them in creative ways.

  • no flight involved? (Score:3)

    by belmolis ( 702863 ) <billposer@@@alum...mit...edu> on Wednesday April 30, 2014 @05:29PM (#46884767) Homepage
    When I was a grad student at Bell Labs in 1983, a senior programmer told me about how she first programmed, when the labs were in New York City. She would write her program VERY carefully, punch the cards, put them in her briefcase, and fly to Washington, D.C. where she had access to a computer. She would give the deck to the attendant, wait a few minutes, receive her output, go back to the airport, and fly back to New York.

Slashdot Top Deals

Don't tell me how hard you work. Tell me how much you get done. -- James J. Ling

Close