You're driving down the freeway on your way to work, and your tire blows out. You wrestle the car out of the speed-demon's lane, through the daily commuter's late, and over into the granny driver lane, and pull off onto the shoulder. You see that the tire has shredded and needs to be replaced. You do all of the things that the average person does in this situation, like rant about the cost of replacement tires, curse about how late you're going to be to your second day of work, kick a big spray of dirt and rocks off the shoulder and into the desert, kick the tire, kick the car, and slowly cool off. It's now time to replace the tire.
What is the very first step in replacing the tire?
"Get on the cel phone, call the husband or AAA, and have them come and replace the tire." Hey, no fair, that's not in the spirit of the test!
"Oh, okay...*sigh*...umm...Remove the flat tire." Nope, wrong answer. The tire is firmly attached to the car.
"Raise the car to get the tire off the ground?" Um...it's kinda heavy, can't do that.
"Remove the lugnuts." What, with my fingers? They're on there really tight.
"Oh...get the jack and lug wrench out of the trunk." I can't, the trunk is closed.
By this point, the non-programmer is seriously peeved at all the wrong answers, and shouts "Open the *&^%&* trunk!!"
If this was your first answer, congratulations, you have the makings of a fine programmer.
Okay, so maybe it seems like a stupid example. But it does the job of explaining how a programmer has to think in order to design and develop his code.
What a programmer does is break a problem down into smaller and smaller chunks, until he reaches a level that a computer can do. To stick with the flat tire analogy, here's the "program" for changing the tire:
1. Remove the old tire
2. Mount the new tire.
But, as we saw above, this doesn't quite work. We need to take this to a deeper level to get a step-by-step procedure, like this
1. Remove the old tirea. Jack up the car
b. Remove the lugnuts
c. Remove the tire
Still, this doesn't give us the level of detail we need. This has to be broken down yet again:
1. Remove the old tirea. Jack up the car--Open the trunkb. Remove the lugnuts
--Retrieve the jack and lug wrench
--Place the jack under the car
--Crank up the jack until the car is off the ground--For each lug nutc. Once all lug nuts have been removed, remove the tire.--Attach the lug wrench to the lug nut
--Rotate both counter-clockwise until the lug nut comes off
--Store the lug nut someplace safe so it doesn't roll away
This is now a set of directions that can be followed. This is our program, and since the "programming language" is English, this actually has a technogeek name: Pseudocode.
(The dirty little secret of the programming world is this: language is irrelevant. If you can pseudocode--that is, program in English--then you can program in anything. There will be a learning curve while you learn the idiosyncracies of each new language and syntax, of course, but most programs can be translated to another language with pseudocode and a reference manual. But I digress.)
Our example above even has some intermediate programming tricks in it. Notice the things that have to be repeated ("crank the jack until the tire is off the ground" and "for each lug nut"). In the language of computer geeks, these are called Loops.
A Do Loop is something that repeats until a goal is reached, like cranking the car off of the ground or sanding a piece of wood until smooth. Computers don't get bored, so it's easy to say "do it once, then check to see if it's done. If it's not done, start over again." The danger here is in getting stuck by using a sloppy goal ("Sand the wood once. Check to see if the wood is purple. If it's not, start over again."). There was a popular soft drink commercial that depicted this perfectly: "Insert dollar bill into the machine. Check to see if a can of soda popped out. If not, start over again." This is called an Endless Loop, because the computer gets stuck and can't get out of the process.
(Now you know why the old programmer joke is so funny. "Programmer found dead in his shower. He apparently tried to follow the instructions on his shampoo bottle and starved to death--Lather, Rinse, Repeat.")
What if you know in advance how many times you want the Do Loop to run? That's actually a different kind of loop called a For Loop ("For each of the five lug nuts"). In general, the concept is roughly the same, but instead of testing for a specific goal, you're just checking to see if you've run out of lug nuts.
And notice that the For loop ("For each lug nut") actually has a Do Loop within it ("Rotate counter-clockwise until the lug nut comes off."). This is a very common programming practice called Nesting. Nesting can get pretty interesting:
--For each car in the police station parking garage--for each tire on the car--next car--jack up the car--next tire
--for each lug nut--remove the lug nut--remove the tire
--put a block under the axle
--remove the jack
An Iteration is one trip through a loop. I wonder how many iterations someone could get through before getting arrested?
So, what have we learned today? We've learned that programmers take large problems and break them down into bite-sized chunks of pseudocode to solve them. We've learned that no matter what programming language is being used, it's still made up of a series of basic structures, like Do Loops and For Loops, chained one after another, or nested one inside another like a Russian wooden doll-within-a-doll.
And we have learned that almost any negative experience can be converted into a learning experience and a programming lesson, like the blowout I had on the freeway a while back.
-=ad=-
No comments:
Post a Comment