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..
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?
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
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.
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.
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.
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.
http://www.geoffreylandis.com
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
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.
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
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.
I feel sorry for people that don't drink, because when they get up in the morning, that's as good as they're gonna feel
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.
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.
As opposed to screwing around on Slashdot?
Perception is the thin dividing line between reality and fiction.
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.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
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
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.
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.
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.
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.
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).
>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.
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.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
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! :)
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.
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.
Why is there an "insightful" mod and why isn't it "-1"? If I wanted insight, I wouldn't be reading
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
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.
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
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.
Socialism: a lie told by totalitarians and believed by fools.
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.
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
In 1987, university budgets and aged professors made for an experience that was not much faster. PCs were a precious resource. Grad students got PC AT clones (286s) and undergrads sometimes got the use of an old PC XT clone.
But at least one old professor didn't believe in PCs, so for his classes students shared an IBM mainframe (a 3090 as I recall) with admin. We had green screen terminals, but results were printed and the printout placed in 1 of 100 pigeonholes, according to the last 2 digits of your SSN. Admin had 2 levels of priority on mere students. The system increased the priority of an unrun job every 3 hours, so between 8 AM and 5PM, it took 6 hours for us to get back the results of a job run. After hours, performance was on the whole much better, but could still vary. Might get a result in a few minutes, or might still have to wait an hour or more. Couldn't continue working after midnight. University budgets dictated that computer labs had to close for the night. Each dorm had 2 or 3 terminals available all night long, but there you couldn't get back any printouts. You didn't want any evening classes, as that cut into the best times to use the mainframe. Weekends were good, if you didn't mind giving up the best times for a little leisure.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
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.
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.
You didn't need MVS to do time sharing. 4300 series IBM mainframes ran VM/CMS which wasn't as hefty as MVS, true, but it could support many users.
I feel sorry for people that don't drink, because when they get up in the morning, that's as good as they're gonna feel
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? ;-)
I had a job as late as 1994 writing programs for company with an old IBM System/38. The AS/400 that IBM would sell to replace it was one they considered useful for up to about 15 concurrent users. We had 200-300 on our System/38. I would send a 4000 line RPG program to be compiled to the queue at 9 am and it would finish at about 4 pm. The three other programmers and my boss were all in the same boat. We tried to make the case to even get a tiny 15k dev AS/400 box, which would have an ROI in less than 5 months, but the senior management just saw the dollar figures and balked. That's how I learned to program in C on Unix, since I was friends with some people in product engineering who had some Sun boxes and pretty much had nothing else to do for 6 hours a day.
Never underestimate the power of stupidity. :-)
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
More like 3K for a terminal, and 5K for a PC.
Want a sig like mine? Join ACM's SigSig today!
$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 guess that the language where you could shuffle your cards is DYNAMO.
Yes, 1983/4 was probably the last year of the punch card machines in government.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
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
Yes, they were.
Any sufficiently unpopular but cohesive argument is indistinguishable from trolling.
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.
You couldn't do much with it, certainly not much related to mainframe programming.
I suspect you could have used them as full-screen editors for mainframe code, and to punch out whole programs automatically. I've read somewhere about people who were doing just that to avoid the hassle with punch card accidents.
Ezekiel 23:20
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 :)
Guess again, the IBM System Unit 5271 (commonly called the 3270 PC) was PC XT with card it in to hook to mainframe and emulate 3270 was *introduced* by IBM in October of 1983.
The University I attended still had punched cards for the Honeywell mainframe in 1983, they finally got terminals the next year.
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.
See: http://terminals.classiccmp.or...
You also had bitmap terminal options like Bell Labs Blit/Jerq and BBN Bitgraph that had Motorola 68000s but used them as display processors, sort of like an X Window System terminal, but with their own custom windowing systems.
By 1983, Sun, Apple, and dozens of other companies were selling fancier personal computers with UNIX and other OSes based on the Motorola 68000 series and other CPUs, but their cost was more like $10,000-$30,000.
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...
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.
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.
Prior to 1980, I worked in a shop that ran DOS/VSE on a VM/CMS machine, can't remember which model of IBM 360 it was though. Under VM/CMS, you could do time sharing. No need for punching up cards.
I got started on an 8-bit Sinclair machine. I grew up on a farm and I remember taking my notebook (the paper kind) with me everywhere on the farm and working on little programs on my breaks. When I finished and typed it all in I wont pretend it always worked but I had a lot of fun and learned a lot.
It was actually several years later when I got access to a punch-card system, and by that time no one wanted to use that one, we were all on the new system, an early Vax minicomputer IIRC. It took up most of a room and then there were two more rooms on either side full of glass teletypes. Or you could access it from other terminals e.g. in the library. Fun times.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
A Commodore 64 was $595. :-P
Gamingmuseum.com: Give your 3D accelerator a rest.
You might be underestimating the cost of a PC. I bought my first PC in 1982 and it came out to almost exactly $3000. That *was* upgraded a bit -- it had *two* floppy drives and they were double sided. *And* I upgraded the memory to 256K, and got a CGA card and an amber monitor.
I was still using punch cards in school (FORTRAN and PASCAL) as of 1978, but turnaround was much faster than overnight. It seldom took more than two or three hours to run my several hundred millisecond program.
Ignorance killed the cat. Curiosity was framed.
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.
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.
And THAT, along with the VIC and TRS80 is what REALLY caused computers to explode and become as common as they are today. Sure your big monolithic businesses had their IBM 360s but there wasn't enough of them to spur huge growth, IIRC an IBM exec in the late 60s predicted selling a couple dozen units a year, with those numbers everything is gonna be conservative.
But then came commodore and Tandy and suddenly every SMB was getting PCs. I started out writing a basic bookkeeping program for my dad's TRS and the next thing you know I'm supporting and servicing half the SMBs in town and suddenly computers were everywhere, and it was all thanks to the gamers snatching them up and keeping the competition high and prices low. i would argue that is why we see X86 everywhere now, DOOM,Quake, the rise of the 3D cards, I had customers from 94-06/07 who were going through a PC a year or more chasing that ultimate FPS and all those extra cycles made it easy to write good business programs, one market helping the other grow. Hell look at what is pushing the mobile market, its all those people wanting to play cool games on their tablets and phones. Hell if all you want to do is surf and watch YouTube a phone from 2011 can do that, want to play the latest game? You better have some decent hardware.
For good or ill I think that will be coming to an end soon, just as X86 became so powerful that a 5 year old CPU and $150 GPU can run just about everything out there so too will the mobile chips hit the same wall, where you just can't get any better without blowing the power budget or making games inanely expensive to develop, what will come next? Will it be a "how low can you go" attempt to drop power, or will it be bringing more and more features into the chip like what AMD is doing? Who knows but it should be interesting to watch while looking back on how far we've come.
ACs don't waste your time replying, your posts are never seen by me.
My CS finals in the late 90s were generally on paper. Including a couple varieties of assembler. The digital design final was in the lab though. Using the compiler as an error checker was frowned upon.
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.
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).
" IIRC an IBM exec in the late 60s predicted selling a couple dozen units a year, with those numbers everything is gonna be conservative."
I think he said there was only a need for about six computers worldwide. Period. Didn't see any business in it, from what I recall reading. And it was much earlier than that, before the 360 project.
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.
PCs were surprisingly common in 1983. Consider the Apple II and various CP/M machines had been around for quite a few years at that point.
Sure, they were still struggling to gain entrance to big businesses which were bastions of the mainframe (although more like with 3270 type terminals than card decks by that point), but small businesses loved them. Businesses were buying Apple II's as "Visicalc machines" in huge numbers, let alone the number of Wordstar boxes out there. Sure, it would be another few years before everyone and his dog had one, but by 1983 there were plenty around.
-- Alastair
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.
I had customers from 94-06/07 who were going through a PC a year or more chasing that ultimate FPS
Well, I hope you're enjoying the house I helped you buy. :)
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.
From the IBM History FAQ, page 26: "Q. Did Thomas Watson say in the 1950s that he foresaw a market potential for only five electronic computers? A. We believe the statement that you attribute to Thomas Watson is a misunderstanding of remarks made at IBM’s annual stockholders meeting on April 28, 1953. In referring specifically and only to the IBM 701 Electronic Data Processing Machine -- which had been introduced the year before as the company’s first production computer designed for scientific calculations -- Thomas Watson, Jr., told stockholders that “IBM had developed a paper plan for such a machine and took this paper plan across the country to some 20 concerns that we thought could use such a machine. I would like to tell you that the machine rents for between $12,000 and $18,000 a month, so it was not the type of thing that could be sold from place to place. But, as a result of our trip, on which we expected to get orders for five machines, we came home with orders for 18.”
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"
In 1983, I was using a modem to log into tymnet to get to compu-serve to play games, chat, etc. There were multiple bbs system around etc The Apple and commodore had already been out for years. And this was all consumer stuff. I remember playing star trek games on the mainframe terminals as far back as '76. To think that there weren't plenty of ways to remotely access a system at this time is clearly someone that didn't play with the stuff at that time. By the time the IBM PC was introduced in 1981 there were already loads of people running bbs's for fun. IBM was rather late to the show personally.
/* TODO: Spawn child process, interest child in technology, have child write a new sig */
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.
Sadly no house because while you were chasing FPS I was chasing the ultimate bass tone and British amps be expensive yo ;-)
ACs don't waste your time replying, your posts are never seen by me.
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.