Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

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

Unknown Lamer posted about 9 months ago | from the could-have-had-a-lisp-machine dept.

Government 230

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.

Sorry! There are no comments related to the filter you selected.

In the late 70s (2, Informative)

Anonymous Coward | about 9 months ago | (#46880421)

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 (5, Insightful)

Arnold Reinhold (539934) | about 9 months ago | (#46881183)

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.

Huh? (0)

LWATCDR (28044) | about 9 months ago | (#46880423)

Wow. You do know that terminals and PCs where common in 1983. Great way to make work.

Re:Huh? (0)

Anonymous Coward | about 9 months ago | (#46880561)

The article mentions that they were a bit behind the times.

Re:Huh? (2)

Geoffrey.landis (926948) | about 9 months ago | (#46880585)

Wow. You do know that terminals and PCs where common in 1983. Great way to make work.

Yes, '83 was well into the "time share" era (remember "computer terminals"?), with minicomputers and Personal Computers also around, but the PC not yet ubiquitous (in '83, that would have been the IBM 5150-- still sold, back then, mostly to homes, not businesses). If the British Government was still doing hand-written code punched in by "data entry" workers, it's because of inertia, not because that was state of the art.

Re:Huh? (3, Insightful)

jellomizer (103300) | about 9 months ago | (#46880737)

Yes but they were expensive.
A B&W Dumb Terminal could cost about a grand, A PC would be about 2 grand.
When a company bought a computer back then, they didn't plan for a 4 year life cycle, but because these systems cost millions of dollars, they planed for 10+ years of usage out of it.

Secondly there wasn't much trust in the computer, and most programs were not meant to be fancy UI but straight number crunching. So a lot of the work was done by had as to have a paper backup.
That said these old programs were smaller, and had less flaws, because they were so carefully done.

Re:Huh? (2)

gewalker (57809) | about 9 months ago | (#46881029)

In 1979 I worked at a Fortune 200 company with a couple of IBM 370s. In our computer programming department, about 20 programmers shared 2 3270 terminals. You could hand-write coding sheets to have it keypunched, but turn-around was a day or two. Dumps & snapsdumps were common debugging tools.

Re:Huh? (0)

Anonymous Coward | about 9 months ago | (#46880763)

This reminds me of a story about a friend who transferred work to a bank in Germany about 5 years ago, there was one guy who would take clients information down on paper, then later type it up on a typewriter and then take that and type it in on the computer.

When asked why he didn't just use the computer and forget the paper and typewriter he replied "that's the way we've always done things" and refused to change his process.

There's the "if it ain't broke don't fix it" side but then there's the "that's the way we've always done things" side, I wonder which side the British Gov't was at back in '83

Re:Huh? (1)

show me altoids (1183399) | about 9 months ago | (#46880767)

I started as a freshman in Computer Science in 1981 and we had to use punched cards for the first semester. We had an IBM 4341 and started off in Watfive (the successor to Watfor, Waterloo Fortran). They had IBM 3277s and later 3278 terminals, but the intro class didn't get to use them until the next year; I was right at the tail end. Once again, when I got my first job in 1986 I had to use punched cards for 6 months until my Secret clearance came in because until I was cleared I couldn't log on. My boss just put his job card at the front of the deck and they would grab me the printout afterwards. This was probably against the rules, but we didn't deal with Secret data, nevertheless the rules were it was a secure computer and you had to be cleared to log on. After that, you guessed it, it was a 4341 departmental mini-mainframe with 3277 and 3278 terminals, and there was a large loud line printer and 9 track hand mounted tapes. Good times.

Re:Huh? (3, Insightful)

cardpuncher (713057) | about 9 months ago | (#46881157)

>terminals and PCs w(h)ere common in 1983

No they weren't.

The IBM PC was introduced in 1981. You couldn't do much with it, certainly not much related to mainframe programming. They were very expensive for what they did. Minicomputers existed, but they also didn't cross over mainframe territory.

People with heavy data processing requirements were mostly using DOS/VSE on S/370 and 4300 mainframes. No timesharing in DOS. It was still extremely common in industry to have people sitting with coding forms that were then passed to data preparation teams for punching. I've sat with teams painstakingly writing DOS JCL onto coding sheets.

If you were a larger user that could justify the investment in MVS, you could potentially use the Time Sharing Option, an interactive environment with a reputation for being cumbersome and inefficient - you'd only extend the "luxury "of using it to a comparatively few select people.

Computer time was also extremely expensive. Cambridge University wrote their own version of timesharing (http://en.wikipedia.org/wiki/Phoenix_%28computer%29) for their (early) S/370 in order to support a larger number of users and time on it was still so restricted that usage was "priced" to reflect demand at different times of day and CS students would either have to work at 3am or make extensive use of cards or other offline data entry to get their projects completed within the allocated budget.

Whereas there were minicomputers and early personal computers around, they were scarcely to be seen in what was still the predominant environment of the computer industry - the (IBM) mainframe shop.

Actually, the British government tended to prefer homegrown procurement and more of its staff were likely to be working with George 3 (http://en.wikipedia.org/wiki/GEORGE_%28operating_system%29), which had a far better interactive environment than IBM offered.

Re:Huh? (1)

jc42 (318812) | about 9 months ago | (#46881197)

Wow. You do know that terminals and PCs where common in 1983. Great way to make work. ...

Yeah, outside of government and corporate environments they were becoming common. I think the main point of this story is that in those environments, access to computers was still done via paper, with the DP department's priesthood the only only ones allowed to actually touch the computing equipment.

In 1982, I had some interesting experiences as a computer "consultant" to a big American company that I won't name (because they considered themselves among the highest of high-tech at the time). Their computer was the usual big IBM machine, and the DP people could do a lot of work from terminals. The rest of the company did everything by sending printed pages to DP, where the "keypunch operators" typed the data in (via their terminals, but they still called it keypunching) and fed to batch runs. They were slowly introducing terminals to the rest of the company, because some people had caught onto what was becoming possible. The terminals let a select few access the computer directly, and read the results of their batch runs on their screens. I was part of a small team of programmers brought in to write code that expanded this capability.

One of the things I did that amazed them was to provide a few programs that actually displayed the data from the computer's databases, so they could for the first time actually read the data that the "keypunch operators" had entered, and see the typos that plagued their operations. But what really amazed them was when I showed them how they could edit the data on their screen, hit the Enter key, and the computer's data was modified. This was much faster than printing out reports, marking them up, and sending them back to the keypunch operators. We had to make the method of doing this unobvious, though, because the DP department would have gone insane at the idea of this end-run around their data-entry process. Users were still sending in the original data to the keypunchers, though, until I finally showed them how they could "edit" a non-existent record using the same tool.

A part of this that was more interesting was that when our team wrote new reports for them, we included an extra output file: We looked for redundancies in their data, and wrote code that crossed-check it, with comments on inconsistent data going to the "Dubious Data Report" output. When we showed this to the users, they were at first horrified that it was possible. Then they slowly realized what could be done with our "data display" tools that could also edit the data. They started asking for the runs with the main reports suppressed, and just the dubious-data info printed, which they took to their terminals. When the data was clean, they finally ran the jobs to get the main reports printed.

Some time after I left the project, I was told by one of the guys who stayed longer that eventually the DP people had discovered what we'd given to their users, and they were outraged. But it was too late; their users had learned some of the marvels that their computer was capable of without the intervention of the DP priesthood.

Funny thing was that we'd worked primarily with top management, who were overjoyed with the orders-of-magnitude improvement in their DP operations that we'd achieved. They were actually quite aware of the difficulty of introducing such new technology into their own "high-tech" company. That's why they hired outsiders to do the job that their own DP department wasn't capable of understanding.

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

airdrummer (547536) | about 9 months ago | (#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;-)

Re:ah, those were the daze;-) (1)

ShanghaiBill (739463) | about 9 months ago | (#46880683)

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.

Re:ah, those were the daze;-) (1)

WalrusSlayer (883300) | about 9 months ago | (#46880917)

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

Idiotic yes, unheard of, no. When I started as a freshman undergrad I was enrolled in a music school that was part of a state liberal arts college. By that time I had done a ton of programming on my TRS-80 in both BASIC and Z-80 assembler on my own. I considered taking some comp sci classes, but they forced everyone to take a course that involved programming on punched cards on the mainframe.

Needless to say, my reaction was "screw that!", and I went on with my studies.

By the end of sophomore year it was clear that (a) I wasn't going to make a decent living as a musician, and (b) I know how to work a computer, may as well get a piece of paper that says so. By that time they had dropped the punched cards stupidity and I went on to earn a double-major in CS and Music.

Re:ah, those were the daze;-) (1)

ConceptJunkie (24823) | about 9 months ago | (#46880951)

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.

Re:ah, those were the daze;-) (1)

perpenso (1613749) | about 9 months ago | (#46881121)

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? :-)

Re:ah, those were the daze;-) (1)

RabidReindeer (2625839) | about 9 months ago | (#46881527)

Bookmarks? Those things made great XMAS wreaths!

Re:ah, those were the daze;-) (1)

RabidReindeer (2625839) | about 9 months ago | (#46881515)

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 interactive.

4got2mention (1)

airdrummer (547536) | about 9 months ago | (#46881059)

that was a cdc 6400 in 1968

Re:ah, those were the daze;-) (0)

Anonymous Coward | about 9 months ago | (#46881185)

I worked at a large (perhaps that's redundant) Hughes site in 1979 and one of the programs I was enhancing/maintaining had been written by my boss and he just liked cards - he could keep them in his office and feel that they were "safe" (after all, fires never happen, water leaks never happen, there are never earthquakes that destroy buildings or render the sufficiently damaged that no one is ever allowed back inside them to get stuff).

We had RJE stations, most with multiple readers/printers/punches sprinkled around the complex and you would leave the card deck on the counter and every so often (30 minutes I believe) the operator was supposed to pick up all the decks and submit them via a card reader. But, most of the time, the crusty old operator at my local RJE station just sat there doing nothing - you put your cards on the counter and he would just look at you instead of deciding "hey, I'm bored stiff, I might as well pick up the cards and submit the job - at least that will delay complete boredom for a minute or two".

Then, one day, on a hunch I smiled at the guy and made some very limited small talk ("How about those Yankees?" or something similar). That didn't get my cards picked up and submitted until the "appointed time", but every time I went to drop off cards or pick up listings I'd say "Good Morning" or "How's it going?" or something like that (occasionally with some limited small talk consisting of a sentence or two). Within three days, he would immediately get up and take my cards and submit them and if I hung around, often the job would complete (not necessarily successfully) and the job listing would start spewing out within a couple minutes and he'd pull it off and hand it to me and I'd chat with him about inane stupid stuff for a couple minutes while the job was running.

I learned a good life lesson from that. People would regularly demand that their jobs get run "now" or that he get their listings off the printer so they could have it now because it was "important" (it was the cold war, delaying the calculations on the design of a new torpedo might have jeopardized the country - who knew?) and he would just point at the clock but more subtle manipulation worked much better. Although, I hated it when one of the "demanders" showed up because he couldn't, for political reasons, run my job and not the other person's so usually mine sat there until the other person left (and, still, just my job got run before the appointed time).

(Nope, I'm not a cute female and I'm pretty sure he wasn't interested in me and I know I wasn't interested in him beyond his ability to access the reader and the printer!)

1983 was not the "punched card era" (2)

NotDrWho (3543773) | about 9 months ago | (#46880447)

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

Re:1983 was not the "punched card era" (1)

Lawrence_Bird (67278) | about 9 months ago | (#46880727)

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.

Re:1983 was not the "punched card era" (2)

OffTheLip (636691) | about 9 months ago | (#46881007)

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.

Re:1983 was not the "punched card era" (1)

perpenso (1613749) | about 9 months ago | (#46881171)

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.

/android $make (5, Funny)

pushing-robot (1037830) | about 9 months ago | (#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.

We would all be exponentially less productive (0)

Anonymous Coward | about 9 months ago | (#46880465)

Oh, wait, programmers were way less productive back then. I don't get it why "some" programmers think it somehow equated to disciple and quality ..

Ahhh... can't belive I fell for this *** flamebait

Re:We would all be exponentially less productive (2)

uncqual (836337) | about 9 months ago | (#46881427)

Although I would never want to return to the old days, one thing "high turnaround time" environments do is force developers to carefully desk check their code before compiling it. In this process, most developers (including myself) would find logic errors that testing would probably never find (even very obscure race conditions).

Now, far too many developers skip this step (and code reviews are too superficial) because it seems to get the project "done" faster while in high turnaround time environments skipping this step would mean that the project would likely never complete before it was cancelled due to coast overruns. Now, the customers find those bugs (at which time it either becomes a crisis or the customer just puts up with it and has the sense that "this software is crappy" which can be corrosive to future sales).

It takes quite a bit more discipline to do the desk check now.

Re:We would all be exponentially less productive (2)

lgw (121541) | about 9 months ago | (#46881583)

Well, there were coping mechanisms. I did mainframe programming in the 90s where an assembler job took hours in the queue - so two-a-day. We just fixed simple bugs directly with a disk sector editor (no butterflies required), in parallel to the source fix, and moved on to the next bug. Once things looked good, or your day's patches became too tangled to progress, you submitted your assembler job.

Then you moved to your other project. That's the key, you know. We were productive because we'd just do 2-3 bugs in parallel. Make progress on 1, submit job, make progress on 2, submit job, see if 1 really looked fixed, nope, submit job, and so on.

Confetti on the Charles (3, Interesting)

paiute (550198) | about 9 months ago | (#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.

Re:Confetti on the Charles (1)

Peter Simpson (112887) | about 9 months ago | (#46881211)

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.

Ugh (1)

P Bacon (3557945) | about 9 months ago | (#46880501)

My initial response was 'Ugh. It's not THAT hard to write code that compiles properly, especially if you have a whole day to write it.' but then again, I was a bad programmer for a long time, and it takes a lot of bad compiles to get through that phase...

Re:Ugh (3, Insightful)

Arker (91948) | about 9 months ago | (#46880843)

I think you learn more effectively that way though. It's not really all that hard to sit down with a cpu reference and a pen and some paper and write out a program by hand, checking your work at each step, and wind up with a working program written in longhand hexidecimal. It's time consuming, of course, but it's really not all that hard if you focus and spend the time.

The biggest thing is just mindset and expectation. If it's your mindset to just spew something rough out and then start debugging it, that's what you will do (and you will produce a lot of bugs, only some of which will have to be fixed in order to compile.) You will probably learn less and more slowly, though.

Re:Ugh (0)

Anonymous Coward | about 9 months ago | (#46881011)

I first learned used card punch machines. In high school it was overnight compile and run on the city's comptroller machine running FORTRAN. If you wanted "immediate" feedback, you would go there on Sunday for a few hours to to able to edit and recompile. Later in college I bought a used card punch machine so that I could write programs at home. I also recall taking the printout of the program stack with me for lunch so I could review it. Stepping away from the lab helps you focus.

Re:Ugh (0)

Anonymous Coward | about 9 months ago | (#46880871)

I reckon you've never tried to hand-write significant amounts of code, otherwise you wouldn't think that way. It's nothing to do with being a bad programmer; without a syntax-highlighting editor to help you, are you seriously saying you think it's easy not to make any typos, or miss any parentheses or whatever in a few thousand lines of code? Maybe you have OCD or something, but normal people do not find that easy.

The sad irony is (1)

Daniel Mills (3611045) | about 9 months ago | (#46880505)

that a large percentage of "software shops" don't even compile once per day and it has nothing to do with punch cards or processors.

Re:The sad irony is (1)

jones_supa (887896) | about 9 months ago | (#46880713)

Is this true? (I'm not in the software industry)

Greenscreen era (0)

Anonymous Coward | about 9 months ago | (#46880519)

Well , I never had to use punch cards, but I did have to queue my jobs. Not a problem at the time if you checked your work, but I cannot imagine doing GUI programming that way. Things moved slower back then :)

Anecdote from the recent past. (1)

litewoheat (179018) | about 9 months ago | (#46880531)

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 hard.

Re:Anecdote from the recent past. (1)

perpenso (1613749) | about 9 months ago | (#46881325)

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.

That's how I started programming in the 90s (0)

Anonymous Coward | about 9 months ago | (#46880535)

Well, I started earlier, but in a written test we wrote a page-long Pascal program on paper, and get this: We had to wait a week to get the result back! It is actually possible to write code without compiling it after every line in a trial-and-error fashion, just like it is possible to write English without relying on squiggly lines. Besides, it is quite instructive to go even lower and manually assemble code. I wouldn't want to do it every day though.

I remember those days... (0)

Anonymous Coward | about 9 months ago | (#46880571)

I remember those days. For me though, I didn't get the results back for a week or more. Debugging spanned seasons. I remember cardpunch typists who would mistake ZERO (0) for capital-O. I remember it took weeks to get enough time on the cardpunch machine to type my own program in. I remember when Hello World in COBOL took 104 cards. I remember how the cardpunch chads made really awesome confetti. Once they went down the back of your shirt, you were going to itch for the rest of the day.

The Apple II was a step up. A huge step up. 16KB of RAM, a 1MHz processor (yes megahertz not gigahertz - that is not a typo), and 130,000 byte disks were a huge step up.

Early 60s Fortran: Cards to Paper Tape (1)

BoRegardless (721219) | about 9 months ago | (#46880573)

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.

Re:Early 60s Fortran: Cards to Paper Tape (1)

Lawrence_Bird (67278) | about 9 months ago | (#46880761)

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.

Re:Early 60s Fortran: Cards to Paper Tape (1)

perpenso (1613749) | about 9 months ago | (#46881359)

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

Even at the end of the 90s (1)

funwithBSD (245349) | about 9 months ago | (#46880605)

The system I administered did overnight compiles.

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

Golden Age (1)

Warbothong (905464) | about 9 months ago | (#46880621)

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.

Re:Golden Age (1)

Lawrence_Bird (67278) | about 9 months ago | (#46880847)

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.

Re:Golden Age (1)

ConceptJunkie (24823) | about 9 months ago | (#46880991)

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.

Re:Golden Age (1)

perpenso (1613749) | about 9 months ago | (#46881477)

Gone are the days of your PHB using successful compiles as a performance metric.

More time to think (2)

cyberspittle (519754) | about 9 months ago | (#46880637)

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.

Re:More time to think (1)

ConceptJunkie (24823) | about 9 months ago | (#46881021)

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.

Re:More time to think (1)

RabidReindeer (2625839) | about 9 months ago | (#46881655)

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, you have this smart IDE to write most of the code for you and besides, All You Have To Do Is...

Compliers?!? You got compliers? (1)

linuxwrangler (582055) | about 9 months ago | (#46880643)

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.

This article is stupid (0)

Anonymous Coward | about 9 months ago | (#46880657)

Things were harder to get done back then, but also the software getting done was retarded simple for today's standards.

I'd like to see these people try this whimsical approach on pieces of code several millions of lines long.

I work on 3D stuff and we get the same stupidity. People saying "on the old days we had 100 triangles and no textures!". I remember those days perfectly, and it was utter shit. You would lose your artistic vision in a blur of technical limitations.

Working with computers has never been better. Unless you accidentally installed Windows 8 of course.

Re:This article is stupid (5, Insightful)

jones_supa (887896) | about 9 months ago | (#46880901)

You would lose your artistic vision in a blur of technical limitations.

These days we sometimes lose the artistic vision in blur of technical abundance.

Dead-end bureaucracy (3, Insightful)

JDG1980 (2438906) | about 9 months ago | (#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:

20 GOTO 10

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.

Re:Dead-end bureaucracy (1)

SocialEngineer (673690) | about 9 months ago | (#46880809)

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 it weren't for 321 Contact, I would've never even gotten into programming.

Re:Dead-end bureaucracy (1)

Anonymous Coward | about 9 months ago | (#46881639)

Yes. This. All the things!

I'm 32. I remember skipping outdoor recess at school so I could type programs from 321 contact magazines into Apple //e machines in the classroom.

I had found a few books on BASIC and machine language, and a few other things at the library before I stumbled across the magazine, but when I hit upon BASIC Training in 321 contact... My fate was sealed.

Now I sling code as a career and support a 5 person family on it. I was getting books on pascal at the library and writing my own programs on notebook paper before we ever had a computer at home. When we did get one, within the first week of having it, I was writing programs on it. My parents didn't figure out the implications of that until a few years later. I remember my dad's astonishment when he finally saw a game I'd written at school in the lab and brought home.

Re:Dead-end bureaucracy (1)

ConceptJunkie (24823) | about 9 months ago | (#46881041)

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

I would call 1983 the end of the punch card era. (1)

MooseDontBounce (989375) | about 9 months ago | (#46880677)

I only used them in college at that time for COBOL, FORTRAN and RPG. You quickly learned NOT to leave your card stack out or someone might do a 'driveby'. That's when someone would walk by, shuffle the deck, then put it back down without anyone noticing.

The other way you could program in 1983 (0)

Anonymous Coward | about 9 months ago | (#46880717)

What? [tripod.com]

We still have once a day builds where I work! (0)

Anonymous Coward | about 9 months ago | (#46880721)

VisualStudio takes nearly three hours to compile our largest project. Add in the four hours it takes to regenerate the WSDL files with WCF, and you have once a day builds if you're making a change to the web services. I don't understand why Microsoft is so ridiculously slow with incremental builds. It shouldn't waste an entire day just to change a single line of code. Of course, my coworkers are huge Microsoft fans because they don't have to work and can screw around on reddit.com all day long.

Re:We still have once a day builds where I work! (2)

Bardez (915334) | about 9 months ago | (#46880831)

As opposed to screwing around on Slashdot?

Only ONE day??? (1)

johnnys (592333) | about 9 months ago | (#46880759)

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!!!

Re:Only ONE day??? (1)

DiamondGeezer (872237) | about 9 months ago | (#46880837)

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:Only ONE day??? (1)

stox (131684) | about 9 months ago | (#46880879)

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

Re:Only ONE day??? (1)

CronoCloud (590650) | about 9 months ago | (#46881289)

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

Re:Only ONE day??? (1)

ctid (449118) | about 9 months ago | (#46881399)

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.

Give me a few more minutes (2)

ArhcAngel (247594) | about 9 months ago | (#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.

Ha! (0)

Anonymous Coward | about 9 months ago | (#46881187)

Definitely the funniest thing I've read today!

CDC 6400 4-hour turn-around (1)

Swordfish (86310) | about 9 months ago | (#46880777)

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. I wish I hadn't thrown away my last box of 2000 cards. They would have come in handy for my current book collection.

Using the card-decks had one great advantage. It discouraged software bloat. If you wrote a 10,000 line program, that was 5 big boxes of cards. You'd need a cart to move them around. Young people these days have no self-discipline when it comes to bloat.

My College of HE used to abhor "terminal junkies" (0)

Anonymous Coward | about 9 months ago | (#46880779)

She was an ex commercial COBOL programmer, and wouldn't let us log in without code already written on lined paper.

None of your namby-pamby "interactive coding" - you got to print out your errors on the line printer and take it back to your desk to debug "like real programmers do"... taught me a lot about debugging, but I don't yearn for those days!

The guys with punch cards were lucky (1)

hunterellinger (574250) | about 9 months ago | (#46880821)

In my second main programming job, in a physics lab starting in 1968, I had two hours twice a week (during changes in experiment) plus one weekly maintenance day to work with the computer itself. The only medium was punched paper tape, so I would load the editor tape, read in the source tape, use the no-monitor teletype to make the hundred or so changes I had handwritten (in pencil on legal pads or previous printouts), print out new source tapes (typically 5 pieces each about 50 feet long), read in the compiler tape, have the compiler read in the new source tapes and print out a binary tape, then finally read in the binary tape to see if things worked. Each cycle would be about an hour, so I was ahead of the once-a-day people, but I got very good at foreseeing the consequences of changes.

That's... weird. (1)

whitroth (9367) | about 9 months ago | (#46880885)

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.


At least you had someone to compile for you (0)

Anonymous Coward | about 9 months ago | (#46880895)

I lived somewhat like that, and year actually was 1983, though I had faster turnaround. I had a VIC-20 and no assembler. I'd hand-write assembly language (pencil and paper), hand-assembled it (look up the opcodes in a book, at for the ones I hadn't memorized), and typed numbers into DATA statements in a BASIC loader that would POKE the program into memory. If I were smart and patient, I'd save the program to cassette tape before I ran it. Then I ran it, and it either locked up the machine or it didn't.

Biggest problem was computing the branch offsets: I screwed those up from time to time (it was some kind of weird "relative" address, so I'd have to count all the bytes in between here and there), and the consequences were dire: oops, I'm executing an operand rather than an opcode.

When I later found out that some viruses (and therefore realistically, probably all life on earth) have super-compact DNA where the codon triplets can sometimes make functional sense in more than one "phase" (am I describing this right? I'm not a biologist, but I mean how "ATCGATCG" can be interpreted as either "ATC GAT CGx" or "xAT CGA TCG" or "xxA TCG ATC Gxx" and all three interpretations might be actually used), my first thought was: that sounds like something a really brilliant VIC-20 coder would do (to save memory, because every fucking thing you did, was about saving memory), where the same bytes are either opcodes or operands depending on context. But I wasn't personally nearly that brilliant of a programmer.

If I'd had an assembler (to compute branches for me), I never would have thought about this kind of stuff. I'd be all, "WTF does DNA and machine language have to do with each other?" Whaddya bet some of those IBM guys went on to become biochemists?

My dad was a programmer way back when (1)

sootman (158191) | about 9 months ago | (#46880965)

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

Better than patch panels! (1)

eastjesus (3182503) | about 9 months ago | (#46881031)

At least with the forms one could see the code and make changes, but it was up to you to see any errors. Punch cards gave you one line per card and disaster if if the wind got you while you were carrying your box(es) full of cards on the way to drop them off at the computer center so you could come back the next day to pick up your syntax errors. Still, both were a big step up from patch panels. Around 1981 I was working for a large medical instrumentation company (at that point I had an Apple II on my desk and z80 and 6800 machines nearby) and one day saw the dumpster full of wired up patch panels. Curious, I asked about it and found out that those were backups of old "code" that had been stored "just in case." My department head told me that they were keeping them around for when all the fuss over microcomputers would blow over and everything would get back to normal.

Punched cards (1)

AndyCanfield (700565) | about 9 months ago | (#46881063)

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. They were free; came in boxes of 2,000 cards per box.

My first keyboard/monitor thingy was a graphics terminal connected to the Stanford Timesharing System about 1980. The boss had an Apple II in a back room.

It is worse when writing VHDL (0)

Anonymous Coward | about 9 months ago | (#46881115)

You write a piece of code. And if you lucky it finishes in a day, maybe in a week you find out it didn't fit on the FPGA.

I wrote COBOL in 1983 for the US gov't (2)

ReallyEvilCanine (991886) | about 9 months ago | (#46881119)

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.

Punch Cards! Bring 'em Back! (1)

Captain Emerald (2882375) | about 9 months ago | (#46881123)

There was one extremely useful side benefit of punch cards: Chad. The chad was wonderful stuff. As a prank (won't say who did it) a container of chad was poured into a car's defroster vent. First cold day: Instant snow globe. And it was the gift that kept on giving as a few chad would came out for years later. Oh the memories....

Mavenized projects are doing this to me. (1)

quietwalker (969769) | about 9 months ago | (#46881131)

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, have some 200 components fully uptodate and deployed locally. All very nice.

Then some folks came in and mavenized the whole thing, completely ignoring the concept of even using eclipse. Now, your only real choice in getting things to work is to make your changes to your one component, build up the jar, war, or installer for it (depending on the complexity of your change), and then overwrite your installed instances. Then you can start everything up and attach a remote debugger, with all the limitations that provides.

Of course, that's only if you're touching a front-end component that doesn't get client-side customizations. If you made some changes in a shared library, you now have to recompile the whole project and frankly, it's easier to run the installer than try to make sure you get each dependent jar everywhere it's used in the system. The compile takes between 40 minutes to an hour with tests disabled. 3+ hours otherwise. You still are stuck with the remote debugger instead of a local tomcat instance because there's no maven plugin to produce an eclipse web faceted project with all the libraries and dependent projects properly crosslinked. It's painful enough to try to set up the 30 plus dependencies and smattering of configuration settings required on one component, but then the next change comes through and I have to do it all over again - and that's only if the change introduces a dependency breaking change, or else I won't even know to update things in the first place.

I don't miss those days. (1)

hodagacz (948570) | about 9 months ago | (#46881143)

I worked as a university key-punch operator as part of my work study in 1982 and the noise is ingrained into my soul.

I hate punch cards with a passion and I eneded up working with them until the end of the 80s (insurance industry).

ICL 1900 (1)

Sesostris III (730910) | about 9 months ago | (#46881229)

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 Operating System was called George III.
Once compiled and stored, you could book your half-hour per day on the teletype! We did hear stories about terminals, but we didn't have any. This was the time you could do your daily compile, and then wait for the compilation listing to come back.

I've still got a few of the punched cards, along with the flow-chart template. They live at work and I bring them out occasionally to show the young 'uns.

By the early 80s I was on a team working with one of our first mini-computers (a Perkin Elmer). This lived in it's own air-conditioned room, with a large wardrobe-height CPU unit, an equally bit tape unit, and two massive removable disk drive units - big both physically (desk height) and in capacity (300 Mb each!). Input was via a terminal (so no more punched cards). Also, enough terminals for all us programmers ('programmers', not 'developers'). Again in COBOL.

One final part, I got an email circa 2003 to say that the first program I ever wrote, in 1979, had just doe it's final run (system EOL). 20 something years - not bad (although how much of my original code was left is anyone's guess).

One interesting technology that came and went was graph plotters. You could get desktop versions of these connected to early IBM PCs. They were fascinating to watch. Replaced by ink-jets and laser printers.

So in short, my journey; started with COBOL on 1900; continued with COBOL and some ICL specific 4GL (that I can't remember the name of - AML or something) on 2900; C (on DEC), VB6 in 2001 (yes, after 20 odd years I progressed to the dizzy heights of Trainee VB Programmer!), and currently Java.

I think I prefer the Java!

When I was a lad (1)

alanw (1822) | about 9 months ago | (#46881317)

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 could use a hand punch.

There's a good page with a photo of one here: http://www.staff.ncl.ac.uk/rog... [ncl.ac.uk]

By my first job in 1979, we had VT52's and then VT100's, as well as a LA120 for the console.

Yet another option (1)

rijrunner (263757) | about 9 months ago | (#46881343)

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... (1)

strangeattraction (1058568) | about 9 months ago | (#46881363)

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:)

It was fun(?) (1)

mstrohbehn (109161) | about 9 months ago | (#46881371)

I remember those days, although we punched our own programs on an IBM 029 cardpunch. Our data entry folks were befuddled by coding sheets, and you would have to take several shots at them punching a program. If you messed up a character while punching a card, you duped the card up to there and keyed the rest on a new card, discarding the old one.

You did learn to think out your program before coding this way. Especially since large programs could take hours to compile.

Ahh, the good old days! :)

Programming in the Early 80s (0)

Anonymous Coward | about 9 months ago | (#46881379)

I did a Masters in Comp. Sci from Indian Institute of Technology, Madras, India in 1980 (There were no Bachelors course yet). We had one of the most powerful computers of that time , an IBM 370 with 512K memory. As Comp. Sci students, we got 2 runs a day as opposed to the rest of the Student population, which got one run a day (A run consisted of submitting a deck of cards and if you're lucky, you didn't get a JCL error or compilation error) .
          After graduating, I (and 2 of my classmates) went to work at a Software start-up in New Delhi. Our first project was to develop a FORTRAN IV compiler for a 8085-based microcomputer. The development was to be done in 8085 assembly code. We had no computer in the entire organization but had access to a Data General Eclipse minicomputer on which we could run a 8085 simulator. The only problem was that 1 hour of Computer time on the minicomputer cost as much as my monthly Salary.
            So we wrote 8085 assembler code on sheets of paper and about once in 6 weeks, we would get our code assembled and get an object dump which could then be run on a simulator or the hardware prototype. My team (consisting of 3 people) managed to write about 36K of 8085 assembler code in about months and show the compiler working at a Trade Show.
              That was certainly a very interesting time. It was also, when the Tracy Kidder book 'The Soul of a New Machine' came out.

Since when was 1983 the dark ages? (1)

wonkey_monkey (2592601) | about 9 months ago | (#46881383)

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...

many languages including C/C++ on micros by then (2)

mr_mischief (456295) | about 9 months ago | (#46881397)

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.

Run, Print, Wait (1)

Schnapple (262314) | about 9 months ago | (#46881445)

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) so every year our generation program had to be updated.

What I got handed was basically a program which drew the form and then printed the data on the correct parts of the form. And when I saw drew the form, I don't mean we had a PDF or JPEG or whatever of the form, we actually recreated the form with whatever bog standard graphics package we used. Like, you would literally say go to (X1,Y1) and draw a line to (X2,Y2), then a line from (X2,Y2) to (X3,Y3), etc. It was like programming in LOGO, but for a legal purpose and without the cool turtles.

This doesn't sound like such a big deal, and it wasn't too bad, but what was tedious was the fact that you would program all this in, then run the program against a single fake student's data, and then you headed to the printer. The printer, in this case was the print room and it was three floors down and a few hallways away. Then you waited for the printout. Which would print as soon as anyone else's job who was in (virtual) line in front of you was done. The time it took to accomplish this was basically random.

And when you found out whatever small change you made didn't work, had the wrong effect, got the numbers backwards, etc. you got to do this all over again. Make small change, compile, run, wait hour(s) for result, lather, rinse, repeat. All with no GUI, no preview, no nothing. Oh, and the program I had, comparing the form printed last year to the actual 1098-T form from the IRS' site was not a 1:1 recreation - it had basically the same info as the source form but it wasn't a dead-on match. I'm guessing this was good enough for the IRS, and either no one had ever bothered to make this thing picture perfect, or the motivation to do so got lost along the way. Lord knows I wasn't going to do it either.

Over time of course you started to average out how long it took to get the printout and you'd wait at least that long before going to get it. And of course this wasn't anywhere near as bad as "come back tomorrow to see if it worked", but that whole process sucked and I don't miss that job at all.

Oh, and this was in ~2002 or so. I didn't really want to be a mainframe programmer but I had little experience in a shitty economy and I was told/promised that they'd be moving to an "all new web-based system within the next six months". When I quit two and a half years later to move to a better gig, it was still "within the next six months". I learned a lot from that job, I guess.

Punching and compiling (0)

Anonymous Coward | about 9 months ago | (#46881453)

In 1968 in high school we were punching cards for FORTRAN II programs, carried them across the street to the H.D. Lee company which didn't user their computers during the lunch hour. Compiled and ran the program, carried the green bar print back to high school. We had traded the use of 5 school parking spaces for the use of a IBM 026 keypunch.
1970 punched cards for WATFOR/WATFIVE system at CMU, handed in cards, got back output in 1 hour except when the stoplight was red. The computer center had a stoplight that displayed the system status, green was running, yellow unknown, red system was down.
1975 punched cards on IBM 029 card punch, great improvement, didn't actually punch until end of the line, brought up RJE terminal at night and we could get turnaround as soon as we loaded deck. Turned over greenbar output paper to let us print pictures. Loaded scanned images via 800 bpi mag tape, great picture of homecoming queen.
1976 Loaded punched cards with DEC assembler or FORTRAN code into PDP11-20 system, we could edit on VT05, compile and run using DEC DOS-11, then display output on RAMTEK color display bit bit images, 3 bits red, 3 bits green, 2 bits blue. Eventually we edited jobs directly from scratch into VT05.

whippersnappers! (1)

dmallery (150862) | about 9 months ago | (#46881457)

back in '67 at RCA Global, we wrote out maintenance programs in 501 machine code (octal, of course),

then we went and punched the lot out on paper tape on a flexowriter. the 501 sans operating system would just suck up the paper tape and run.

mainly we wrote machine code because a cobol compile took an entire SHIFT! if you had a big cobol program you wrote machine code patches for it for about a year before the next compile. if there were any compile errors, you patched around them.

men were men.

Similar experience at school (0)

Anonymous Coward | about 9 months ago | (#46881497)

In 1985/86 I was still at school (real school, not university "school" like they use in the States).
We wrote our code on cards and they were sent to the local college to be entered in and run, and we'd get the results a week later. Yes a week later! Invariably the result was "syntax error on line 7" or something like that.

Very frustrating.

Punch Cards in College - and Poor Peggy! (1)

Spinlock_1977 (777598) | about 9 months ago | (#46881579)

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 often see students lined up at the card reader, waiting to read in their programs. The first six columns of a punch card for Cobol programs was reserved for an optional sequence number, equivalent to a Line Number today. Nobody filled those in - not even our instructors. If you had to re-order your program, you really wanted to avoid having to re-type cards with new sequence numbers.

However, at the end of the last semester, minutes before the final assignment was due, my fellow student Peggy came running in to the data center with her purse and coat in one hand, and a six-inch deck of Cobol cards in the other, tripped in her haste to the card reader queue, and scattered 2000+ cards across the data center floor. And on the final day of the final semester, we learned why its sometimes good to put sequence numbers on your punch cards.

And btw, nearing the end of each semester, it ALWAYS took 24 hours to get a compile back.

Punch card repair kit (1)

Arethereanyleft (442474) | about 9 months ago | (#46881589)

I started college in 1978, but I was lucky enough to get a job in the CS department where I learned how to use a terminal. While my fellow CS students had to type in punch cards, submit their jobs, and then wait for a printout, I was able to type my programs in using a text editor and submit the jobs so that the output went to a file. When it was time to turn in my assignment, if the instructor required cards to be turned in, I knew how to submit a "punch" request to get the cards.

I remember one day someone showed me a list of things you could buy outside of the job submission window, and one of the items was a "punch card repair kit". Someone bought one and showed it around. It consisted of a little metal rod that could be used to punch holes in a card and some little tape stickers to cover holes. I thought it was a joke, and told my dad about it. To my surprise, he told me that when he was in college (same college, same building) 30 years earlier, he actually used these. Back then, you would write your code on a form and submit it to the keypunch operator. When you got your cards back, you would carefully proofread them and submit any incorrect cards you found for retyping. If you only had a small mistake and the line was long for re-types, you would get out your punch card repair kit and fix the card yourself.

Pick Fail (1)

dugb (10154) | about 9 months ago | (#46881597)

In Arlington County, Virginia of the mid-1970's, 7th and 8th grade math students were treated to a week-long exploration of BASIC programming, complete with access to a
HP 9830A [old-computers.com] , and an HP 7260A Optical Mark Reader [hpmuseum.net] . We used HP Educational BASIC Cards [uiowa.edu] .
So, the drill was: write your program on paper, transcribe it to the cards with #2 pencil, then get in line to put your cards in the reader. Inevitably the Reader would choke on a card, and issue a "Pick Fail" error. That could be due to a damaged card or to the number of erasures and rewrites on a card. Pick Fails were always accompanied by three honks from an alarm inside the Reader. Moans from students waiting in line for card reading usually followed. The best you could hope for was one iteration of your program per day, but realistically you got 2 or 3 runs during programming week, what with all the Pick Fails.

Yes, how horrible (0)

Anonymous Coward | about 9 months ago | (#46881607)

You had a good office job sitting at a desk. You had good working conditions, were revered or at least respected, had bonuses, decent working hours, health insurance and outsourcing and the 6 month learn or die cycle didn't exist yet.

How horrible, glad those days are over.

Now let me get back to work coding social apps for telephones and hoping I don't get outsourced to some Chinese kid in Brazil. As opposed to coding the systems that get people's retirement cheques delivered or some such nonsense.


Heh, I started as an Operator (1)

Anomalyst (742352) | about 9 months ago | (#46881635)

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 reading assembly from SOC7 hex dumps, good times, good times. Also used PANVALET on 3270 terminals to code and had to enter changes from the bottom up or the system would get confused about line numbers after an insert/delete and did horrible things to the cardfile. Still make changes bottom up to this day, once bitten twice shy.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?