CASUAL, IN THE NY'R STYLE
I’m teaching myself ActionScript, a programming language used with Adobe Flash. Unless I flunk myself, the reason will appear in a post not too far into the future.
ActionScript is an object-oriented language.
OK, I know that I just ran the risk of losing 90% of you. Trust me, there’s a funny story to follow…
The term “Object Oriented” today refers to a concept in computer science where a programming language is structured so that building block “routines” written in it have very well defined and tall “walls.” For example, if you write a part of your program to, say, draw a rectangle on the screen, all the other parts of the program interact with the Rectangle Routine in very well specified ways. They don’t get to muck around with Rectangle Routine’s internal bits. They can only tell it where on the screen to draw it, it’s dimensions, color, and that’s it. Each routine is like a little castle; what goes on inside is its business.
Well, while Object Oriented Programming was around when I was working toward my computer science degree from SUNY Stony Brook. We learned about it as a theory, but I never used it. It’s application in common practice lay a dozen or so years into the future. (It took hold in the 90’s.)
But, at the significant further risk of terminally dating myself, allow me to explain that there were objects that were very much involved in my programming, back in the day.
They were called punch cards. One’s pictured right over there on the left. Real time access to a computer was a platinum-precious resource in those days. The way you typically interacted with one was to write out a program’s set of instructions, sit down at a console like the one over there on the right (that’s not me), and type out a punch
card for each and every line of code in your program (the more complex the program, the more cards), and then take your “stack” of cards to someone who would feed them into a machine that would present them to the computer for processing. A few hour later, you’d get a printout (on “Green Bar” paper). If something didn’t work, you’d have to figure out what was wrong, fix your program, go back and type out the new cards, insert them in the right places in your deck (their order was as important and their individual contents), and hand it over to run again. Another three hours later, you’d find out if you’d fixed the problem.
Well, as you might imagine, this was pretty tedious stuff. Especially with very large, complex programs.
I labored through much of the fall and into winter of 1977 on one such large program, a Senior Project, with success in it a requirement for graduation. The program grew large, there were many, many retries to get it just right, and my stack grew larger and larger.
By the time I finally got it all right, on a particularly cold December afternoon, my stack of cards measured somewhere around eight inches tall.
When I looked down at the Green Bar printout, and all, excepting some minor formatting issue, was as it should be, I did some 70’s version of a Tiger fist pump, and rushed out of the building to drive home.
Finding my Mazda RX-3 in the parking lot, I tried to open the door. No luck — dead frozen. Fortunately, this was a known problem, and I had a can of spray de-icer at hand. I put the card deck and printout on the roof, and set about gaining entry to my car.
It took awhile, maybe 10 minutes. I was freezing and it was getting toward dusk. When my key finally turned turned in the lock, I jumped into the driver’s seat, flipped the ignition and cranked up the heat.
A few minutes later, I had warmed up enough to drive. I reversed out of the parking spot, turned toward the exit, and gunned it…
…only to see each and every one of my stack of cards fluttering behind, like their accompanying snow flakes, in the rear view mirror.
Never slowed down, even a little. When you screw up, you gotta move on.
The next day, I sat for God-knows-how-many hours, retyping each and every one of those objects. I passed the course.