From Power Looms to Punch Cards
Information technology and computers have changed the world. As I have described in the previous two articles in this series, the foundations of these changes occured during dangerous times - World War II and the Cold War. The Information Age itself brings new dangers. This article begins to describe why and I hope that the average lay person will take the time to absorb the slightly technical information here. I believe that your patience will have its rewards. Please note that certain industry-specific terms are in this color.
Many of us know that punch cards are associated with early computers. In fact, punch cards got their start in the textile industry during the 19th century as they were used to program power looms - also called Jacquard Looms for weaving patterns. Music is also a pattern and player piano rolls worked in a similar fashion.
- Both off
- Both on
- Left on, right off
- Left off, right on
It's beginning to sound like an activist chant!
If we add a third switch, the possibilities double to 8, and if you install a wiring scheme in your house that has a switch plate with 8 switches, there's going to be 256 possibilities. That's a lot to keep track of. Wouldn't it be efficient to get a bunch of cards that have holes punched in them so that if you were to force a card down on the switch plate, you would have the desired settings? This is now a metaphor for how instructions are sent to the computer's CPU and it is in reality how it was done in the early days of computing. That switch plate is a metaphor for what is referred to as a 'byte'. Those instructions that are now fed to the CPU by a programming language are composed of bytes.
The invention of programming languages began to aid and eventually replace punch cards. The use of programming languages meant that the computer specialists could type instructions directly into the computer or type a series of instructions which were then fed en masse to the machine. Whereas a set of instructions in any programming language became the equivalent of a stack of cards - not all of which might be used - the process of data abstraction continued to increase.
The development of programming languages made the progamming and maintenance of computers much more efficient. And also much more critical. When we speak in a syntax that is not entirely what we intend, the human brain (still the most powerful computer in the known universe) has the ability to infer. Computers don't infer and CPUs don't guess. The difference of one character of computer code could be like the difference between turning the radio switch and the wiper switch in your car.
Such differences can cause errors in the way that a computer works. Today we call such errors bugs. The term was first used by Admiral Grace Hopper, who invented the COBOL programming language. Ms. Hopper diagnosed a problem with a computer under her supervision which was caused by a moth in the machinery - thus the term "bug". Never mind that a moth is not a bug. Programming languages are used to create computer programs. No longer do we insert a stack of cards and options of what is really sent to the CPU continues to increase.
Such malfunctions of an operating system can have unexpected consequences. One case in point: In 1996 my brother had a neighbor who had a very nice and very talented wife. This fellow's wife was clever enough to earn a degree in education and responsible enough to get a job teaching. Furthermore, she was nice enough to bring home the bacon while her husband did what he did best. Stay home and stay stoned. Let's call him "Stoney".
About the same time in another part of the country, another malfunction occured. As you may recall from an earlier article, computers were extensively used from early on in the telephone industry. As programming languages used on these computers became more complex, the process of data abstraction became more profound. In other words, a computer program or operating system dedicated to phone line switching might have millions of lines of code and some of those lines might be read (or executed) by the computer very rarely. It is the job in the programming discipline to test (or execute) every line of code as it is being developed.
This "no stone unturned" process is not unique to computer programming. In 1992, I was part of a construction survey near Palmer, Alaska. This project was to correct problems resulting from an earlier survey by another organization.
If necessary, refer to the end of the previous article.
Next : SCADA on Thin Ice