Slashdot Mirror
One-a-Day-Compiles: Good Enough For Government Work In 1983
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.
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..
Wow. You do know that terminals and PCs where common in 1983. Great way to make work.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
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;-)
That was in the 60's and early 70's.
SJW's don't eliminate discrimination. They just expropriate it for themselves.
Let me say that again: the next day you could find out if your code compiled or not.
So not much has changed, then.
How can I believe you when you tell me what I don't want to hear?
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
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.
If Slashdot were chemistry it would look like this:Cadaverine
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...
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.
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 :)
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.
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. 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.
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.
The system I administered did overnight compiles.
It was just not grunty enough to compile during the day and do development.
Never answer an anonymous letter. - Yogi Berra
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.
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.
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.
~~~~~~~
"You are not remembered for doing what is expected of you." - Atul Chitnis
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.
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 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.
What?
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.
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!!!
Sometimes the "writing on the wall" is blood spatter...
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.
As soon as this compile of Gentoo I started in 2010 finishes I'll tell you whether I have 'fond' memories of the experience.
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
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.
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!
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.
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
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?
He told me how it was to do things by hand because programmer time was cheap and machine time was expensive.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
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.
that was a cdc 6400 in 1968
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.
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.
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.
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....
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 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).
Definitely the funniest thing I've read today!
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!
You never know what is enough unless you know what is more than enough. - Blake
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...
By my first job in 1979, we had VT52's and then VT100's, as well as a LA120 for the console.
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.
What, you did not punch sequence numbers on the cards so you could drop them into the sorting machine? :-)
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:)
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! :)
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.
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...
systemd is Roko's Basilisk.
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) 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.
Schnapple
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.
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.
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.
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.
- The Kessel run is for nerf herders. I can circumnavigate the entire Central Finite Curve in a lot less than 12 parse
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.
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, and an HP 7260A Optical Mark Reader. We used HP Educational BASIC Cards.
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.
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.
Hurray.
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.
There is no right to feel safe thru security vaudeville at the expense of everyone's freedom, privacy and tax money.
We need to bring back those days of long compile times: xkcd - Compiling
When I started coding in 1966, the only device on my desk was a telephone. Nobody had ever heard of a monitor, and the only keyboards were on keypunch machines (those were the machines that punched holes in cards).
To write a program, you filled out a large form with your code and sent it to the keypunch department. The next day, you got back a deck of cards. You couldn't really do anything with those cards except pass them on to the man who operated the IBM 7044. But first you had to add some more cards to the beginning of the deck to instruct the computer on what to do - such as invoke the FORTRAN compiler, link the result, and run it.
The next day (two days after you wrote the code), you'd get back a printout and two card decks: your original source deck and an object deck (what we now call the object file). The printout (the "listing") showed the results. If there were any compile errors, you repeated the process. It could take a week to get a clean compile.
Lots of things could slow you down. Sometimes I'd get my job back with a note from the operator that said "looping". That meant that he, on his own, had decided that my code was in an infinite loop and had cancelled the job. Those old computers ran only one job at a time - the operator couldn't run my job until yours was finished. So he often had nothing to do but stare at all those flashing lights. When the pattern of flashes repeated itself over and over, he decided that it must be in a loop. Whenever I submitted a large sort, I had to include a note saying "Don't cancel for looping".
I could go on and on. But I remember the day when I experienced the future. I got a consulting job in 1974 to develop code for a Datapoint 2200 (the precursor to the Intel microprocessors). It had a screen and a keyboard and astounded me with instant results. I was so grabbed by the process that I spent a solid seven hours at that computer oblivious to everything but coding and testing. I collapsed on the office couch at the end of that day, but eventually I got used to it. I had no idea at the time, but I had just experienced a typical day in the life of the new developer.
OKsofar
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 what the compiler thought of it. We had immediate turnaround, which meant you could go through ticket cards that much faster.
I now program mainly in C on Linux boxes. The programs I create are orders of magnitude more complicated than what I created then. My interactive productivity is much higher too. I'm not sure I'd even attempt much of what I do now if I didn't have much more powerful computing and debugging facilities available.
...laura
You needed enough "cheap" memory to hold 5x7 raster character set in permanent memory (ROM). That would be five bytes per printing character or 360 bytes at minimum. Thats three 1K ROM chips. New memory generations started at $50 - $100 per chip, then falling to about $5 once they became commodity. So terminals became "commercial" at about $1000 where a third of that was memory. This would be about $5000 in 2014 prices.
I remember one of the clever thing about the Apple II three years after that was using spare bits in a byte for storing color imformation. That made graphics programming somewhat contorted.
Early 70's, I was an undergraduate in Chemistry helping faculty and grad students program some FORTRAN applications such as non-linear least squares and some very, very early quantum chemistry apps (I recall one was called Gaussian). Since we had a Univac 1108 mainframe and most of the apps were written in IBM FORTRAN IV (G1) and we used Univac's FORTRAN V compiler, there was quite a bit of work to do getting these applications to run (also, 36-bit vice 32-bit words!).
Fortunately, we had one of a handful of terminals on-campus, a Univac DCT-500 (http://bitsavers.trailing-edge.com/pdf/univac/terminals/brochures/U5220_DCT_500_Brochure_May70.pdf). THREE HUNDRED bits per second baby! We rocked and rolled while nearly everyone else was using IBM 29 keypunches.
The bad news is that some of our applications ate ALL of the available memory - no virtual storage on the 1108, just hand-coded segmentation.
So compiles were OK (but really slow), but executions were off-limits until the Computing Center was closed for the night and we could get "standalone time".
Those were the days...
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 on printouts of the code I was modifying.
Lost at C:>. Found at C.
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.
As well as filling in the sheets, if you were lucky you could punch the cards, too. Before even writing code, though, you would do your program flowchart to make sure you knew where you were going. From your previous stash of cards, you would pull the appropriate JCL headers instead of having to go through that particular piece of hell. Want a printout with that? I worked for a college doing this stuff. One day, I was told to mount a new disk for a project. Going down the lines of drives, I finally found a bay that was not marked. I stopped the drive, pulled the 25 pound disk out and put the new one in. Then the system crashed. The only "free" unmarked pack was the OS. Students came by for weeks looking for their lost work. Must have been the gremlins, you know? ;-)
In 1981 I had the change to play with an HP system on its way out of production. To make a program you had to:
Load an editor from a punch (paper) band
Type in your programme
Save the source to punch tape
Load the compiler pass 1
Load the source
Run compiler
Save intermediate code to punch tape
Load compiler pass 2
Load intermediate code
Run compiler pass 2
Save compiled code to punch tape
Load linker
Load compiled code
Run linker
Save executable to tape
Load programme and test run
Pål
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.
The Kruger Dunning explains most post on
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.)
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
$2K for a DEC VT100 terminal.
A lot $ for an IBM 3270 terminal.
Dave Barnes 9 breweries within walking distance of my house
The person giving me the assignment also wrote programs in some kind of simulation language where the lines could be in any order. Sometimes he would shuffle the cards while standing in line for the cards to be read, just to make fun of the other waiting.
I had to start by coding in COBOL making sure that nothing appears in columns
1 thru 12, and nothing goes beyond column 80 (even written out). Then
you would submit your program to the mainframe, and it would either
produce output, or give you an abend (short for abnormal end). It was
often better to go through your software with debugging statements and
see which ones produce output and which ones don't, and by that
method, you could get a rough idea of where your program was failing.
It could also produce variable values. You usually had to be careful though,
because you were usually given a total of 12 compiles to get a program
working fully.
I guess that the language where you could shuffle your cards is DYNAMO.
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.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
If you haven't seen this, you should check it out: http://www.masswerk.at/google6...
The punch card machine had a "multipunch" option to prevent the card advancement. So we could punch out all the rows and all the columns of the punch card. We punch many such cards, staple them together to form a large sheet, fold the sheet into a cylinder and staple the seams too. Our hostels had naked incandescent bulbs hanging from the ceiling providing the only illumination to the hostel room. We would hang this hole punched cylinders of punch cards as a lamp shade. Casting beautiful dots on the wall, and a flood of illumination in the center of the room. We would use transparent plastic sheets, (cellophane paper in Indian parlance) to color the lamp shade and the illuminated dots on the wall.
We would have beaten Martha Stewart in the creativity department of making lamp shades! I still have my ID card to the computer center.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Took a programming class in college back in '89....teacher made us write our programs on coding forms and run a set of data through everything, step by step, manually following the code, before being allowed to enter it into the computer.
Needless to say, I dropped that BS course.
When I got banished to summer camp, I was fortunate to have at least a notebook and pencils.
So I wrote a message board system, for a Commodore 64 dial-up BBS.
Iterated and debugged over and over, following every code path while tracking variables by hand.
When I got home, I was able to transcribe it, and it worked great, running the (206) New Hong Kong BBS for a couple years.
It wasn't as bad as people think. You desk check your code. Editing your code meant key punching new punch cards to replace the bad ones. Or using a utility program to replace the one lines with new line. A new program might take a day. But once that was done you could get a few compiles in during the day.
High school senior in 1979: 1) Get assignment on Monday 2) Write code on paper. 3) Wait for punch machine to get freed up 4) Type in code 5) Give teacher punch cards on Monday 6) Teacher takes a box full of cards on Friday 7) Teacher picks up cards Sunday night 8) Get paper results and cards at Monday class. 9) Rinse and repeat until it compiles. I wrote TWO great programs that semester :)
I used to edit my programs with ed/xed on a UCB Unix V6 system on a PDP-11/70, and use some software that was written to convert to EBCDIC and submit to the IBM 360 using a RJE protocol emulator. My SYSOUT would get returned to a spool file, and with the magic JCL comment card, would find it's way back to my E-Mail for my review. /usr/bin/gus took a lot of headache away from me, and saved several small forests in typo'd keypunched cards. I was able to get more than 1 compile a day, too.
It was before the Great Renaming and USENET/EMail SPAM. Good times...
I still have a thrashed deck of cards (all holes punched) somewhere.
I was a physics major in the 1960's-70's. Programming was done on punch cards with the often one day turn around. I believe most of the students doing programming were actually engineering students.
As the quarter went on, the students programs got more complex and the card decks got bigger - often quite large.
So, one day I was headed across campus at the end of the quarter and a rain shower sprang up. People started running and this one guy tripped on the curb. His cards went flying into the mud. He scrambled around trying to pick them up; this was no doubt his final project. He suddenly sat down and started crying.
As I stood there watching, I thought, "If this is what computers do to people, I will have nothing to do with them".
Many years later, as I was sitting alone on the floor in the data center at 3:00 AM after a power failure trying to bring up countless cranky Windows NT servers running on Compaq boxes (why isn't the SQLNT starting?), I remembered my failure to obey that oath taken so many years ago.
I had only just last week found one of the first programs that I wrote in 1972. We were lucky that our engineering school had a reconditioned IBM1800 with only a small cadre of us who knew how to use it so we got plenty of hands-on machine time in the late evenings when the official jobs had finished. You can see a printout of it on http://2eo.blogspot.ie/2014/04...
I remember how back in the pre Y2K the news was saying the problem was due to programmers trying to save memory, so they only used 2 digits for the date.
Maybe somebody did, but the main reason was that this stuff was originally written to use punch cards for data entry. You only had 72 columns, so taking off the two digits of "19" from the year to was a big savings in the amount of data that you could encode on one card.
Also, it sucks to realize that talking about Y2K makes you an old-timer.
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.
I was a civilian employee at a supply base for the US Navy Polaris missile submarines in the 1970's
The programmers there got only one compile a night with their punch card deck. If you got a syntax error on a compile, you got called in to explain. Two, you got written up. Three in a month and you were no longer a programmer. But, hey, that was the Navy.
n 1974 I was a new hire at Lawrence Livermore Laboratory. since I was fairly green (OK, really,really green), I had a daily routine to support a group of developers who lacked security clearance needed to get to the equipment for which they were developing. All they had was a keypunch and a Digital GT42 graphics system (PDP11 with VT11 vector graphics, 19" display, and paper tape reader).
You may notice that there was no paper tape punch or card reader. Also, no compiler/assembler was available. This made getting new code to the display station a bit awkward, so I had the following daily job:
1. Pick up card deck at Bld.415
2. Drive to Bld 113 and use the PDP-1 (not a typo) to read in the cards,run a small program to do character translation and punch out a paper tape (actually paper covered mylar)
3. Drive to Bld.131. Load tape into the PDP-11 running DOS (no relation to the later Microsoft DOS), and assemble. Punch out paper tale of the binary
4. Drive the cards and tape back to Bld.415 where it was loaded onto the GT-42 for testing and debug. The code was heavily loaded with NO-OPs to allow debugging using the switch register on the front panel of the PDP-11.
5. Note required fixes and additions and update the card deck as needed.
Repeat.
Life got easier when the developers got security clearances so they could access the real development system. It has DECtape and ran RT-11. All development could be done right there and the entire code base could be compiled (now written in FORTRAN IV except for low level graphics code). Note that the system lacked a disk. DECtape was a random access magnetic tape system and ran RT-11. The compile was started every evening at about 16:30 and usually completed about the time I came in at 7:00 the next morning.
For all the kids reading this, you can research all of the terms I used that you don't recognize. You can actually see them at the Computer History Museum in Sunnyvale, CA, though they only have the GT-40, a much more popular, smaller version of the GT-42. They have every other item I used including a running PDP-1. (Play Space War on the DECUscope!) Probably nothing running RT-11, though.
I used punch cards in College and had to wait hours to get my turn.
For work . . . we started a Machine Monitoring System for the factory floor around 1985. Back then a "compile everything" on the older Motorola Versados computers took five and a half hours.
Now on the PC-Linux its running on, that same "compile everything" takes . . . 3 minutes 23 seconds.
100 times faster . . . is a nice change.
No, I don't remember your name. But the memory mapped screen on a TRS80 from 1977 is from 15360 to 16383 if that helps.
I wonder if it's the old-schoolers that termed YAGNI and repurposed KISS, as it seems like continuous integration has made it possible for hobbled code to work even in an unmaintainable state. It's a different mind-set to "dumb down" your implementation so that next to nothing can go wrong, and that apparently doesn't taste good to developers who love complexity.
Load assembler from tape (3 mins)
Type in assembly language source code (including own code to do things like put a character on the screen pixel by pixel)
Save source code to tape in case it crashes (2 mins)
Assemble
Save object code to tape (2 mins)
Restart machine
Load object code from tape (2 mins)
Machine hangs (no error messages)
Load assembler from tape (3 mins)
Load source code from tape (2 mins)
Pore over it to work out why it crashed
Loop
In the mid 1980's our 360 assembler class had to use punched cards to run programs at an off-site mainframe facility. For security reasons they didn't want a wired connection. Thus the turn-around time was a day.
Since we did have an onsite VAX with a card reader, I decided to write a Pascal utility to pre-check for bone-head syntax and naming errors to reduce the failed attempt cycles and made it available to other students with teacher approval.
And I got a nice little award for that to put on my first resume.
Table-ized A.I.
Then I had a transformative experience through a one-week stay at the University of Waterloo, where we spent all our time in front of teletypes programming in APL. Boy those teletypes were noisy, especially with a room with twenty of them going at it full blast. When I went to bed my ears would still be ringing. Yes, APL was my first programming language, and frankly the trauma hasn't worn off yet.
When I started university in 1980 at McGill in Montreal, there still were punch card machines and punch card readers at the computer center, and its satellite centers. However, pretty much everyone at the school had a "computer code", ie an account on the time sharing system called MUSIC: see wikipedia. It was a lovely system, and you could run commands interactively. It came with Fortran, Snobol, Pascal, Lisp, IBM 360 assembler, and, of course Adventure!
I spent many hours playing Adventure, and of course mapped the whole cave in detail.
At McGill, there were two kinds of terminals: video terminals for the lucky people, and paper terminals from Digital Equipment called DecWriters for everyone else. The former had wisiwig code editors, on which you could prepare your source code and, when ready, "submit" your program to be compiled, run and printed. You would then walk down to the basement of Burnside Hall, where a surly operator would hand you your printout. That's when you learned that you had a typo in your code. Needless to say we were told over and over to WRITE YOUR PROGRAMS OUT before you typed them in, but nobody listened then, and nobody listens now either. In any case, the turn-around time from "submit" to picking out your printout was in the order of 15 minutes, not overnight as in TFA.
The design of Watfiv fortran focused on fast compilation. Your code wouldn't be optimized, but that was OK, because as a student the majority of your runs would have compilation errors. Typically you only ran your program, fully implemented, once or twice, after dozens of botched compile runs.
All in all, it was a great experience. What I appreciate the most, in retrospect, was that CS students were required to learn IBM assembler. Higher level languages don't fully make sense until you know what's going on at the CPU level. I still can't fathom how an intro course in Java can give you any true knowledge of how computers work.
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.
We're talking small state school, not MIT (no CS major yet), but things were similar. We had to punch and submit our own decks (limited number of keypunch machines was a big problem.) The computer, a pair of 370-158's IIRC, was about 200 miles away over a phone line, and we shared it with the state Poison Control Center, among many other things of much higher priority than our classes, so latency was unpredictable. If a job got in before lunch, it was usually back by next morning.
We had a single DecWriter (fancy dot matrix teletype) that did APL on the same remote computer; it was sufficiently expensive per minute and hard to get a slot on that we didn't use it lightly, and mostly with handwritten programs we did the night before.
The school also owned a PDP-11/40, but access was limited to DEC BASIC and most terminals were 1200 baud or less. My last year or so we got a couple of dual floppy Apple IIe's with Apple Pascal. They were overall the most useful, again when time on one was available. From 10-11:30pm (when the building closed) were best.
I still remember my first source debugger, around 1986 or '87. I finally got enough memory (at $500/MB!) on a Mac II to run one.
Worked at Hughes Aircraft in Fullerton. Sent punched cards off to an http://en.wikipedia.org/wiki/I... in Culver City and got the printout back the next day. Not exact;y doing http://en.wikipedia.org/wiki/T... back then.
vice chair orange county java users group (ocjug.org).
I had written my 1st BASIC programs then, iirc, leasing time from a DEC PDP-11 (?), line #'s & all & shortly after wrote COBOL on a VAX-1180 midrange during my freshman year in collegiate academia (dating myself) in 1984. I don't miss the "required" divisions extra bulk or the limited scope of the language (but it was the best I had my hands on @ the time & trends were in its favor for usage - so I went with it). I do Windows now though (C++ &/or Delphi = my fav tools for GUI development in it), e.g. -> http://start64.com/index.php?o...
* :)
(Just when I was thinking I was one of the truly "oldsters" around here? You came along (from the sounds of it)).
APK
P.S.=> I bet you're outta the punchcard era too, aren't you? I saw a guy CRY when he dropped his shoebox full of those once @ a parent's workplace (parent operated county gov't. computers in refrigerated rooms with tape drive streamers etc. & dumb terminals, but the coders did punchcard work - smart ones used a marker to draw a line across them if they dropped their stack of them)... apk
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 development time might be a bit longer but, dammit, the code would be a hell of a lot better.
Perhaps we should go back to that system.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
I've done more than my share of batch programming using punch cards and paper tape on machines from the Amdahl 470 to the original PDP-8 (pre-integrated circuits). I remember how advanced a 10 character per second Teletype terminal seemed. And I sure as heck don't miss those days! Give me my Python interpreter any day! :-)
-- Art Z.
I used punch cards in college in the mid '70's. While in an RF engineering group at a large defense contractor, we were told by "corporate information management" that we had to buy IBM for computing. So I ordered some HP9000's with IEEE488 ports as RF test set controllers :-) Had access to Cray stuff as well, but it was heavily scheduled and costly.
Left that outfit before the old Soviet Union derailed, and jumped over to an outfit doing MRP, MRPII, integrated manufacturing and financial software for a few years. PC's with IRMA cards for mainframe, had an HP3000 and a VAX785 to use pretty much as I needed. Good access to VM/CMS, DOS/VSE, and OS/MVS boxes, RACF admin privs, operator privs on the local 4300. No problem with the VAX or HP, just needed senior management approval for the PC, as it was a status symbol. The goofy corporate world, a PC was "status", but having a VAX to call your own wasn't even within their cognitive level. Wonder why that business sector tanked? ...
It's a completely different development model today. In some ways far better, in some ways not so much. Understanding of how it all works down cozy to the metal has faded for those not doing embedded sorts of things.
Oh Well, the early days were in many ways more fun, although I would have killed for the hardware we have today!
Jr high school after school fortran programming class, we would write the programs on programming paper then use the library keypunch and give the program to the teacher. They let us run one batch per week.
Cards could also store the object code in "binary" form. Ordinarily the card held one character per column, but in binary mode each row of each column (about 12 rows if I remember correctly) was a bit, and either had a hole punched in it or not. You didn't punch in the binary yourself, you wrote the program as characters and then when the job ran, the computer (if you asked it to) would write the object code onto cards in binary format. Binary card decks were considerably smaller than character cards. It also saved compilation time, just load, link, and go. You could even get the machine executable on cards, that was more bulky because the cards had to include bits for all the allocated storage. (This was Fortran, no dynamic memory allocation in those days, all the ram for all the variables was allocated at compile time.)
The great drawback of binary cards was that they were unmodifiable, but when running the same program a number of times that didn't matter. Some flexibility was possible because you could have several versions of some subroutines which you could swap in and out. The main problem with binary was the card reader, reading binary cards was much slower and more noisy because of the greater number of holes per cards. The error rate was higher too, some "user" card readers were almost unusable since they continually misread cards. In those computer centers you gave the binary deck to the operators because their card reader was much better.
Another thing about card punch machines was how noisy they were, like manual typewriters but worse. They didn't just hit paper with a key, they punched a hole in card stock, truly high impact printing. Even though the card punch was bolted to the table it was on, the table would shake.
At that time I was working on a 'real time' Unix, writing C and compiling running testing via a green screen terminal. Not fast tenough, we shifted over to a 68000 based system, running PDOS, this time PASCAL / assembler, again normal (today?) edit/compile/test loop.
I suppose that when terminals cost the price of houses, and the computers lived in air-conditioned pens with white-coats at hand, and boas under the floor, computing time was scarse.
Technology depends on how far one lives out from the main stream. I used punched cards and paper tape when i went through my course in the seventies. I used a teletype machine at work, it had a fairly large recriprocating mass, it used to "walk".
Still, it amuses me to think back then we talked about 'Automatic Data Processing' (ADP), but every bit was expensive and one spent a good deal of trying to get as much information into the available data space. Now-days, data is cheap, and everyone calls it "Information Technology". Its rather silly really. Most IT people spend their time pouring data from one jug to another, with little regard to 'information' or how to optimise things.
I still know how to find the main cycles of a program and bum speed out of it. You did that in the ancient days, and because i wanted to run the cycle a couple of thousand millions of times, it is of some profit to do this even today.
OS/2 - because choice is a terrible thing to waste.
I was working for a service bureau. We sold time on CDC computers and I was visiting with a prospective client with the Navy. They were using a computer at another site since they didn't have one of their own. I was talking about while we didn't have a guaranteed turn around time for jobs (time between reading the cards in and getting paper back out) being usually in the range of 1 hours for routine priority works. Quicker if you paid a bit more. He laughed at this. I said that was better than average for our industry, is that a problem? He explained that his turn around time averaged about a month.
They were made of exceptionally high-quality paper and took fountain pen ink wonderfully --- I've exhausted my supply (which I use for note-taking) and am still looking for a (reasonably-priced) replacement.
Sphinx of black quartz, judge my vow.
At the far right hand of the family table of FPGA's, 10 to 20 hour compiles to close timing are commonplace. Plan your work, work your plan.
An Altera Stratix5 A7/AB (or similar from Xilinx) contains more discrete logic elements than the entire 1970's and the beginning of the 1980's did.
One day the printout came back with a simple JCL error, so I went to pick up the deck planning to resubmit it. As they brought the boxes forward they dumped them all over the floor, as I stood there watching. Ooops.
Of course, they had actually taken an old set of cards and dumped them, this was my second time being involved in a prank while working with data centers. The first time, I was the pranker, so I had it coming.
Another story involves a pranker feedback loop. Using SimScript back in the day, punch cards with turnarounds measured in hours.
Student gets his printout back and finds the report includes a printed line "Eat my shorts". He rifles through his card deck, and finds a card that his buddy had slipped in. Running the card through the punch, he adds the words "... you scum sucking pig" and inserts it into the suspected pranker's submitted deck.
Cue lunch. The Sargent from data center window comes to our lunch table to tell the original pranker (now the prankee) that they killed his job after it printed a several foot high stack of "Eat my shorts you scum sucking pig" (oops, forgot to look for programming loops before just dropping the card into the deck). He is to report to the Commander at 2PM to explain himself.
Original prankee falls all over himself apologizing, promises to go with the original pranker to explain, lots of recrimination, etc. Sargent, having stood there silently, finally interrupts to note that they really only printed a few pages, and this abuse of government equipment need not go any higher.
Lessons learned? (1) Do NOT prank carelessly. (2) If you must prank, keep the sysops in the loop.
"There is no god but allah" - well, they got it half right.
I too had not so fond memories of trudging over to the "computer center" with a box of punch cards and spending many a day waiting to use the punch card machine just to type in the "code" (ah Fortran - my dear friend); hoping that I didn't typo too often since even at pennies per card it was still monies spend on something other then BEER. Once I did type in the code - off to the operator drop station "maned by the CS undergrad major - who was having second thoughts on HIS major choice" to hand in my hours of work. Only to be called back realizing I forgot the job declaration stack of card that was needed to submit the jobs to the "mainframe". Once submitted, out the door for a beer across the street (gotta love OU!). After many rounds of Asteroids and several beers later you realized your job should be ready to process. You'd head back over for a scan of the output bins - hoping to find your job sheet. If you were lucky it was there and then you'd scan for the results - praises to the almighty compute god, otherwise, BUGS and wash-rinse-n-repeat. This went on for 2 quarters until I found out from the Psych grad students that they had access to a "TERMINAL" that was connected to the mainframe. You had access into some sort of editor to code your job; and the TSO (i think) environment so you can do the job management and submissions. For some reason grad students had higher rights then the lowly undergrads and when you submitted you job it processed inside of 20 minutes or less. Way cool, even doing Fortran. It was so cool. Taught myself some of the basics of mainframe job control, SPSS for data analysis, COBOL and wasted way too much time playing a Star Trek game in ASCII instead of doing my coding assignments. (http://www.codeproject.com/Articles/28228/Star-Trek-Text-Game)
STAR TREK
ENTER 1 OR 2 FOR INSTRUCTIONS (ENTER 2 TO PAGE)
ENTER SEED NUMBER
INITIALIZING...
YOU MUST DESTROY 17 KINGONS IN 30 STARDATES WITH 3 STARBASES
COMMAND
(partial copy )
In 1975 at "The" Ohio State University on an Amdahl 470 coding PL/C , a horrible "teaching" language version of PL/I that auto corrected syntax errors. That meant that the errors you got on compilation were not the errors you coded, but the ones the compiler added for you. Lots of fun.
Anyway, when you started a class you were given an account with a certain amount of "money". Money was required as each compilation "cost" a certain amount of cash to compile and run. The more resources you used (not just CPU time or memory but also things like disk space ) the more you had to pay. If your account ran dry, you couldn't run any more jobs. You had to go beg your TA for more money so you could finish your programs. This of course affected your grade.
I will never forget sitting in the hallway of the computer center watching the monitors for when my job ran, literally praying that the damn thing would run this time and running to the A-Z mailbox for my output to see if I got what I was looking for.
Well, the alternative was to connect the teletype to the acoustic coupler, dial up the college where the compilation and running was done, and run the program directly. But since the cost of the phone call (20 miles, at 300bps) exceeded the budget for the entire computing class (communications budget was zero pounds and zero pence per class per year). The budget for paper, and the mimeography to make the blank coding forms could be hidden in the rest of the school's running costs, but the cost of getting a second phone line into the school and of paying the phone bills couldn't be hidden.
Obviously, all the equipment was donated by local companies. But they couldn't cover the phone bills. So the forms went to the college when one of the teachers drove past on his way home, got processed in the college's computing centre's (on the good will of their hearts), and picked up a few days later to come back to school with us.
A hell of a fankle. So, after a few months, the headmaster (EN_US : principal) knocked the course on the head, telling us that, as we were likely to go to university in 4 years time, we'd be able to do computing there. (He was dead proud - before our year's intake, the school had not had a single pupil go to university. That's non-comprehensive education for you.)
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
When I was still at school I did work experience at a South Australian Government office which still used punch cards. It was very similar to what was described above. The programmers wrote the programs out on paper (coding sheets), and then sent them along to the girls (there were no guys) in the typing pool to create the punch cards to be feed into the machine. (They also did the typing for a lot of other things. A request to create punch cards was something the typing pool only got once or twice a day. I think only one or two of the girls usually did it out of about fifty of them).
Think the procedure went:
*Guy (there were no girls) wrote the program,
*Sent it to the typing pool on the same day.
*Next day they received their punch cards back.
*Feed them into the machine to have it compile etc and see if it works.
From what they told me they seldom had any problems.
When my friends and I visited a University (whilst at school) for some sort of experience day thing, they were still using punch cards. By the time I got to Uni they'd just installed a new machine (an Amdahl) which you could use terminals for, so punch cards were only just phased out. By the time I got to working full-time in IT (I had a detour into a professional music career for a while), punch cards were long gone, but some of the older PA's etc would recall the old Hollerith machines they used to create the punch cards.
Sure enough, the cow costume was hanging up next to the superhero outfit and sailors uniform. (S,Spud)
If you have a big project running on an FPGA, you still might get compile times that might sound surreal to CPU programmers. On a CPU each source module can be compiled seperately and only the last step - the linking - ties them together. In hardware description languages, on the other hand, the "compilation" of a single source module into the net is only a small first step. everything after that has to take all modules into account. A simple change in one module might lead to a felt eternity of compilation (like in: starting on friday, looking for results on monday). Luckily, most basic errors are caught in the first compilation step. But the hairy ones will just make the system attempt longer and longer untill it eventually gives up.
tl;dr With FPGAs, overnight compiling is no stranger even today.
Good Enough For Government Work In 1983 isn't good enough, even for government work.
In the mid- to late-70s, our XDS Sigma computers (https://en.wikipedia.org/wiki/SDS_Sigma_series) were doing everything online (unless you really wanted to do it offline for some reason). As many as 16 offline ("batch") jobs ran at one time with (in our environment) about 60 to 70 online users. And this was with one CPU and two megabytes (yes, 2MB) of memory.
People knew how to code operating systems well with few resources back in those days.
Circle the wagons and fire inward. Entropy increases without bounds.