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.

Dead-end bureaucracy

[JDG1980]

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.

Re:Huh?

[jellomizer]

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

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

Re:Ugh

[Arker]

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

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

Re:This article is stupid

[jones_supa]

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.

Re:Huh?

[cardpuncher]

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

No they weren't.

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

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

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

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

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

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

Re:In the late 70s

[Arnold Reinhold]

The punched card era ended for me in 1975, when I started working on Data General Nova minicomputers at Computervision. But I spend more than a decade before that with cards and keypunch machines. I never let anyone else punch in my programs, as I usually found some errors when I typed them in myself. Card decks weren't dropped often and it wasn't that big a deal. Dropping a deck is not an effective way to shuffle it. I'm more nervous about my online source files being munged by accident. The overnight or 24 hour turnaround was common, but possible to work around. I spend many nights after mid-night at the MIT computer center in the late 1960s, when hour or even half hour turnarounds were possible. One spent the time waiting socializing or helping others find their bugs. During summer jobs at NASA MSC, I found a Honeywell 316 that wasn't being used much and could get time on it all to myself when needed. In the early 1970s my employer had an IBM 1130 and we took turns using it, so turnaround was not an issue there, though it could be when software was to be installed at a client. Finding ways to get around obstacles in your path was a valuable skill then as now.