|
|
|
“The Sourcerer’s Apprentice” |
Just about sixty years ago now, in 1940, Walt Disney produced the animated film Fantasia, which included as a short segment, set to the haunting orchestral music of Paul Dukas, “The Sorcerer’s Apprentice.” The story is a cautionary tale, ostensibly about students trying to run before they can walk and the virtues of doing your own housework. But I wonder if any of those involved in the storyboarding and animation thought it would become advice for future computer programmers—a job that had then not yet been invented.
The first lesson for a programmer is: Debug your code. Don’t release a program on the world—or to your customer base—before it has been debugged, tested, debugged again, beta-tested with select and knowledgeable users, and then debugged a third time. I know from working with, not just new programs, but with a new application on an existing and well understood programming platform, that an application must go through successive rounds of testing and debugging before its release. And that testing must include a range of unusual situations—some of them clearly not meant to be encountered during regular use—that might break the program or cause the user to obtain faulty information if not actual harm. Mickey Mouse putting on his master’s magic hat, waving his arms at a dormant broom, and getting a response hardly counts in this testing process.
A second lesson: Make sure that your DO and DO-WHILE loops are properly defined. These loops governing actions repeated a certain number of times, or while a certain condition persists, are powerful programming tools. But failing to set them up properly, so that the repetition stops at the right number or when the governing condition—in Mickey’s case, when the parameter “cistern level” reaches “full”—is met, can lead to disaster. The fact that Mickey’s enchanted broom went on filling the cistern and overflowing into the laboratory indicates a faulty DO loop.
A third and related lesson: Make sure that you enter an executable STOP code. This is not only the point at which the program has completed its tasks—if that point is ever reached or if it even applies, as it might not in the case of a word processing or spreadsheet program, where there is always more to do—but also the point at which the user is finished with the program and wishes to terminate it, usually indicated by a pulldown command of “Stop” or “Quit.” If Mickey had installed such a command, he could easily have frozen the broom in its tracks.
And a final lesson: Clean up your deleted code and comments. After Mickey chopped the enchanted broom into a thousand pieces, the splinters remained energized and came to life, each as a separate and completely functional broom, and they all tried to complete the task. Code fragments from old compilations and deleted subroutines—along with the programmer’s internal comments that once applied to them but are now probably meaningless—are not necessarily going to come to life and function as zombie programming. But useless junk in the working code creates headaches for later programmers and developers.1 And of course, unlike the master sorcerer who came in, stopped the brooms, and then left the problem there, be sure to document—offline—your code, your issues, and your solutions.
However, “The Sorcerer’s Apprentice” is more just than a set of object lessons for future programmers. It captures—as do all tales of magical spells and demon summoning—the essence of programming itself. From my early days with small computers I had the opportunity to fool around with the BASIC language, which is governed by line numbers, and then with Pascal, which is a structured language. Both involve calls, subroutines, and loops. And like any programming language of any brand, they call forth in the programmer’s heart a kind of wonder.
Like magicians of old, the programming language and the software platform is a form of remotely controlled power. With it, the competent magician can formulate and cast spells. He or she can summon powerful agents, composed of other spells and programs, that can perform tasks. And as with the casting of spells, the language punishes inattention and carelessness. A missing or misplaced comma, semicolon, or colon, or a misspelled command word, or an omitted, misplaced, or misattributed variable or parameter can all render the program inert or send it off into unexpected and damaging functions. The errors can be—often are—subtle and take much study and many retries to find and correct. The only good thing is that, unlike an inappropriately summoned demon, a command-line error will not snatch the programmer by the hair and drag him or her down to Hell—although too many errors and botched codes will have the programmer looking for another job.
For years, the writing of programs—casting of computer spells—was limited to information tasks like word processing, number crunching, and data recording and retrieval. These are functions that exist solely in the realm of zeroes and ones, and they reveal themselves only on display screens and in paper printouts. And unlike setting stupid brooms loose in the laboratory, they usually can’t hurt anyone—although a computer error in your bank balance or in processing a contract document can lead to major monetary damages. Still, no obvious blood.
But from the early days, what we think of as a “computer chip” has always had a secondary purpose as a control processor.2 These chips—usually with hard-wired, solid-state programming called “erasable programmable read-only memory” (EPROM)—now control the engines and brakes in our cars, the functions of our televisions and DVD players, the timing and power systems in our microwave and toaster ovens, the battery charging in our electric shavers, and a slew of other devices in the home.3 But previously programmed processor chips are only the beginning.
Self-actuated robots are already among us—they just don’t look like human beings or smooth skinned C-3POs, with heads having paired visual receptors and vocal chords, two arms with hands and fingers, two legs with feet, and the ability to talk and walk upright. In many factories, however, stationary robots that perform a limited range of functions like welding, materials handling, and packaging are already common. The military now uses drones that are under human control as to what they will do but under internal computer control as to how they will do it. And some of that technology is now available for personal use: think of toy drones and self-guided vacuum cleaners. Almost every car maker is working on systems that will make the family automobile—or one day a machine that you will not personally own but will call for, like a taxi—self-driving and autonomous.
And by that time the root programming—the casting of the spells that will make the automaton move (how it works)—will be done somewhere before the machine leaves the factory, while the refined programming (what it does) will be provided by touchpad inputs on a smartphone and voice commands spoken in the machine’s presence.
And all of it was prefigured—that is, subtly and slyly inserted into our collective consciousness—by the image of Micky Mouse putting on a magic hat, waving his hands and sending sparks toward a dormant broom, and making it perform a simple household task.
1. What? You thought you were going to be the only developer to work on this project? Or that it would be your baby for the life of the product? Think again!
2. The original “microprocessors” that became the heart of small, hobbyist computers like the Tandy RadioShack TRS-80, the Apple II, and the various S-100 backplane systems were originally meant to control mechanical functions like automobile fuel injection and brake systems, rather than respond to keyboard inputs and display output text on a cathode ray tube.
3. My father, a mechanical engineer, used to say that the 20th century saw the rise in the number and use of small motors in people’s lives—for example, how the car went from having one large engine and hand cranks for everything else from windows to windshield wipers, and even for starting the engine itself, to having a dozen small motors placed around the engine and passenger compartments. Copy that into the home with small motors for electric fans, furnace blowers, air conditioners, vacuum cleaners, refrigerator pumps, and even electric shavers. In the same way, the late 20th and early 21st centuries have seen the rise in the number and use of small processors and robots in our lives, so that even the coffee maker has its computerized functions.