- Top 10 Recession-Proof IT Jobs
- 7 Hot IT Jobs That Will Land You a Higher Salary
- Link Building Strategies and Tips for 2014
- Top 10 Accessories for Your iPad Air
Network World - As long as I can remember, I've had an interest in computer programming. I started tinkering as a kid back in the early 1980s with a TI-99-4A and Atari XL Series (remember those membrane keyboards?), Atari STs and Apple II's. Most of that was just goofy kid stuff, sorting baseball and hockey cards and stuff that was Star Trek related.
It was in college, though, in 1984, when I began to learn to program. I attended the University of Victoria in British Columbia (that’s in Canada, eh) and at the time the school had an IBM mainframe running UNIX. I took Fortran, COBOL, Pascal and, everyone’s favorite, assembler language where you actually program at the machine language. While all of these languages were different, there were a few similarities. First, the editor was VI, a command-line editor made up of cryptic key commands. Second, every student was allocated a certain weekly “budget” to program with, which was really a proxy for CPU cycles. Here, if you write a program with some sort of cyclic loop, you would burn through all of your CPU cycles and not be able to complete a project. There was a catch though - once you hit zero, you could stay logged in and go into the negative as long as you don’t log out. So if you wrote some crap code, you had to stay in the lab all night long until you finished or you would have to wait until the next week to get your new allocation of CPU cycles. The third commonality was that the debugger was crap. The printout you got just gave you the last line of code that was executed and you had to figure out why.
|Apple's Mac: The Post-PC PC?|
|30 years of Apple’s Mac computer|
|The Mac Evolution: Looking back at Apple's 11 most intriguing computer designs|
|Celebrate Mac@30: For $110-$140|
|Full list of stories looking back at 30 years of the Mac.|
What this meant for programming was that you had to do an immense amount of pre-work before you started typing anything into the mainframe. All the code had to be documented, flow charts had to created, and mock “runs” had to be done to see how the program flowed. The program would then run, invariably fail somewhere, and the whole process would be repeated. I would say for every hour of actual computer time, I would need to spend about four to five hours working with paper.
But then in my last year the school’s attitude toward programming changed. The university invested in a Mac lab, complete with brand new Motorola 68000-based Macs, the crème de la crème of personal computers, if you will. My attitude towards programming changed.
With the Macs, there was no allocation of CPU because the CPU was dedicated to that machine. That meant one could write a subroutine or two, run it, see how it performed, tweak it, and then move on to the next task. The debugger was fantastic as well. Programming in 68000 assembler was dead easy compared to the IBM mainframe since it gave you an actual view of the contents of the registers and allowed you to walk through the code line by line.