So, if you’re like me, the first time you look at code, you will cock your head and let out a confused whine. “What is this gibberish?” you will ask. The short answer: definitions and instructions. Programs need two things: definitions and instructions.
On a recent family trip, the fiancé and I were trying to explain to my dad something about programming. He kept on getting stuck on one particular point, until my mom piped up with, “Because computers can’t climb a chain of inference.” (Side note: This is not strictly 100% God’s own truth, but, as with most basic programming courses, we’re going to hand-wave that bit. You just need to be a damn good programmer to make it so. Most of us are mere mortals and cannot whip up a program in 2 hours that will turn your computer into HAL. Be thankful.)
I started to describe it in these terms: think of telling someone how to make a peanut butter sandwich. Now, think of how you’d tell someone to make a peanut butter sandwich if, like Amelia Bedelia, they could only follow instructions literally. (Put jam on the bread? Better hope you told them to get out the bread, uncap the jam, and use a knife, and that you’ve told them how much jam to put on.) Now imagine that not only does this person follow your instructions purely literally, but they do not know what bread, peanut butter, and jelly are. They don’t know that there are things that you spread on bread. They don’t know what a sandwich, a knife, or a jar are. Like Jon Snow, they know nothing.
And not only that, but if you give the person something unexpected, the world will end. It might end quietly, or it might end loudly.
For example, imagine going to your favorite deli and ordering a turkey club. The person at the counter brings you a brick. You will probably point out their mistake and ask them politely to bring you the turkey club you asked for. They will promptly go out, club the turkey with the brick (*rimshot*), and make you your sandwich.
On the other hand, a program in the same situation, if it has not been told that, presented with anything other than a turkey club, it should, in fact, ask again for a turkey club, will probably do something at least akin to one of a few things:
a) Try to eat the brick, breaking all its teeth in the process.
b) Stare at the brick quietly. It might eventually leave money there, and return and tell you that lunch was fine, only to pass out later from hunger. Or it might just stay at the deli until you come to get it, by which time, it has also probably passed out from hunger.
c) Glance between the brick and the person at the counter wildly, slowly freaking out more and more until it runs out of the deli screaming.
d) Give a blood-curdling scream, smash the display case with the brick, and collapse, sobbing incomprehensibly.
Now, if the program were presented with something edible, depending on what exactly you told it to expect, it might be able to cope. If you presented it with some other kind of sandwich, you’re probably in much safer territory. So, yeah, computers… aren’t smart. They need telling what to expect, and what to do if it’s not given exactly what it expects (or rather, when it’s not given exactly what it expects. Always assume someone will give you bad input).
Back to our peanut butter and jelly example. If you’re telling someone who at least knows what bread, peanut butter, jelly, sandwiches, bags, jars, and knives are, they can probably infer how what you mean when you tell them to put peanut butter and jelly on the bread, put the peanut butter and jelly sides together, and enjoy. Heck, they might even know how to go to the grocery store for those things!
So, let’s try this thinking like you’re telling a program who knows none of these things what you want and how to get it. First, procurement of the goods. For simplicity’s sake, we’ll assume you don’t have to completely build a house from scratch, order some silverware from Macy’s, or get transportation to the store. However, you already wind up needing to tell the program a lot of things:
1) Where the store is, and how to get there and back.
2) What peanut butter, jelly, and bread are, what kinds you want, and where they are in the store. (You probably also want to tell the program how to ask for help and process that help in case they’ve moved things around, lest your program follow option d of our deli example.)
That doesn’t seem like much, but unpack it—it’s a lot.
Moving on, your program is back, and it has the correct items. The store remains standing and unscathed, so you don’t have to deal with an angry shopkeeper. Now the real fun begins. The instructions will probably be something like the following.
1) Take the twistie off the bread bag. Open the bread bag. Pull out two slices of bread (or, more accurately, while you have less than two pieces out of the bag, pull another piece out–yay, control flow!). Close the bread bag and re-twistie the bag.
2) Find the peanut butter. Unscrew the lid from the jar of peanut butter. Use the knife to extract the desired amount of peanut butter, being careful not to fling it at the ceiling. Use the knife to spread the peanut butter on one side of one of the pieces of bread. Set that piece aside. Screw the lid back on the peanut butter jar.
3) Find the other piece of bread. Repeat the same instructions from two in order and exactly once, replacing every instance of “peanut butter” with “jelly”. (Yay, refactoring code!)
4) Take the two pieces of bread and put the sides with the spreadables (yay, interfaces and/or abstract classes!) together, such that the bread is oriented in the same direction if it has a shape such that this would be a good idea.
Okay, so that’s four steps, but that’s four long steps. Steps full of things you and I don’t have to tell each other when we yell “Make me a sammich!” Aren’t you glad you don’t have to describe literal-word-for-literal-word how your sammich needs to be made each time your robot servant makes it for you?
This is what programming is: breaking down a problem into all the requisite parts, including the ones you know are small and stupid but actually could really botch the entire thing if left out or messed up. It’s problem-solving in a way or on a level most of us just don’t need to think about in our day-to-day lives (well, unless we’re programmers). That doesn’t make programmers smarter or better or more observant, though; it just makes us people who have probably gone to school to more or less re-learn how to do these things with some amount of finesse and elegance, rather like any degree. It’s a specialization, and it’s certainly not for everyone, but it’s a good exercise in learning a certain way of thinking, and understanding why it is that that program is running out of the deli screaming when presented with a brick.
Figuratively speaking, of course.