Object-Oriented Programming vs. the Teletype Punch

Or, Recurrent Insanity vs. Good Engineering

image link-blank-sf0.jpg

The Teletype punch is a miracle of sound engineering. What it must do is up to punch five (six for the Teletypesetter) holes across a paper tape, repeatedly (plus another smaller hole for the sprocket). It must do this millions of times, without error, often in harsh conditions. Punches aren't easy - they're hard to make. Indeed, the very code used by Teletype was laid out initially by the earlier inventor Murray specifically to minimize the number of punches (and the wear on his punch mechanism). The Teletype punch simply worked - reliably, in industrial and military circumstances, 7/24, for decades.

The way that it works is to have push-pull rods under each of the five (or six) punch-pins of a "punchblock." For each character position to be punched, the mechanism sets these levers in or out (corresponding to hole or no hole). Then a single hammer punches all of these push-pull rods simultaneously. They transmit (or do not transmit) this blow up to the punches, and the tape is punched appropriately.

The principles here are these:

Now, how would an object-oriented program implement this?

Each punch would be an instance of the class Punch. Each would operate asynchronously, waiting for messages to punch. There's no other way to do it in OOP; if you do it otherwise, it isn't OOP.

Of course, the punches assume that there must be some external mechanism which generates punch messages. No doubt that could be built. Most programmers would stop here, but if it was necessary to verify that the punch messages were in fact correct, and that there was only one source of them, and that all of them were obeyed, and that none of them were disobeyed (or ignored, or not received) then an external monitor would need to be implemented. This would be a complex piece of logic, and so in practice would never be written.

The simplest OOP mechanism is already more complex than the Teletype mechanism (multiple independent punches, all competing for resources, an underlying general-purpose message transport system rather than rods, and a coordinating punch-message generator). The real problem isn't the increased complexity of OOP, or its decreased efficiency. The worst problem is that it simply cannot be reliable. Without a complex supervisor hovering over everything and crosschecking it, there is no way to know if anything ever worked correctly in the first place. Errors would be random and untrackable. Basically, the system would produce wrong answers undetectably, and ever so often would become so unstable that it simply crashed. (This in fact sounds very much like a modern computing environment.)

This litte exercise took a physical object (the punch) and tried to envision transforming it into a programming one (an OOP punch). How, to conclude the argument, would one in fact implement an OOP punch as a physical object? Would it look at all like a TTY punch?

Nope. The way to accurately implement an OOP punch in the physical world would be to get five or six trained monkeys and give each of them a punch. They should, if they keep listening, punch the tape when called upon to do so. Perhaps they would, but without a superviser watching them constantly, you'd never know, would you?


Select Resolution: 0 [other resolutions temporarily disabled due to lack of disk space]