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