Programming Logic for the Impatient, Part 1

I am not a programmer. I very much enjoy programming and trying to solve problems, but I’m not a programmer. I really like manipulating code to do cool things, but I’m not a programmer!

The reason I’ve decided to write a (series of) blog posts about programming logic is because I know many others who are damn smart but don’t have a firm grasp on how machines think. I think everyone should at least have some real-world grounding in this idea. There’s an entire hidden world right at our fingertips.

Please note, this is not going to be a technical explanation by any stretch. I am not going to use many technical terms at all – in fact, I am challenging myself to write no code whatsoever as I go forward. My definitions are going to come right off the top of my head. I am going to make every possible attempt to explain how machines think without forcing you to go click to other sites in order to follow along. I am prepared to get my eyebrows burned off by the searing rage of professional programmers that think I’m a fool because I didn’t tell you about error handling, threading, or inheritance. That’s all okay by me. My goal is to get you to think like a machine thinks. After we’re done you’ll hopefully be able to go off and start learning the language of your choice with a good grip on the conversation you’re actually having with the machine following your orders.

Let’s start off with my first homemade definition.

What programming is

Programming is just a series of instructions given to a machine with the express purpose of performing some task. If I want a computer to open a web browser, I need to carefully explain to the computer that I want it to do this on demand when I push a button. It’s pretty basic stuff, and I can’t assume that the computer understands what I’m talking about unless I set down ground rules.

“Follow these orders, exactly as I’ve written them down.”

Make sure you read that correctly, because this is quite literally as tough as it gets.

Follow these orders, exactly as I’ve given them to you.

That’s a statement loaded with meaning. The biggest problems and confusion in coding come from the fact that we do a poor job of explaining ourselves in general. Can you think of a time in your life when you were unclear about something that you wanted and the end result got screwed up? That’s what happens with code all the time. Machines never make mistakes (well . . . ), but they do get confused if we don’t explain every single detail to them. They always follow orders exactly as we’ve given them.

How machines think

Machines are like children with no bias about anything. If I tell you do go play fetch with a king cobra, you will not do it. Why? Because there are many pieces of information that flow through your head immediately after I issue that order.

  • Snakes are predators
  • Cobras are poisonous
  • If you mess with a poisonous snake it’s going to bite you and you’re going to die
  • If you get too close it’s going to chase you
  • A snake won’t chase a stick, and it probably wouldn’t bring it back if it did
  • Why is there a snake in our yard
  • Isn’t there a dog park near here
  • I should probably do something about this snake

Now, if you were to tell a very young child to do the exact same thing, they may actually do it. Nothing is defined for them, they have no experience, and they don’t know about the dangers. As far as a kid knows, a poisonous cobra would make an amazing companion.

That’s how a program functions. It only knows what you tell it. If you write code that tells the machine to do something, it’s going to do it. Unconditionally. Programming logic isn’t that complex compared to what we do – it’s just a lot clearer. Psychology spends decades trying to unravel very complex things into very simple ones. I guess they’re really just trying to debug mental illness!

Variables are just buckets of stuff

Let me give easy way to understand the notion of a variable, because you won’t get far if you don’t generally understand what they are. Let’s build on what we’ve already discussed.

Consider this: If there’s a fire, and you have a bucket of water, and you want to put the fire out, you pour the bucket over the flames. Easy.

As humans we speak in a very symbolic language. This is a pretty fantastic shortcut to understanding variables that I’m about to totally exploit.

Let’s reread that thing about the fire again for just a second. You’re pouring the bucket on the fire. Shouldn’t that mean you’re pouring the water in the bucket on the fire? Stay with me in this moment, right before the light bulb goes off in your brain. Our symbolic way of thinking about things is the key. Anything could be in that bucket right now, including:

  • water
  • sand
  • nothing
  • gasoline
  • dynamite
  • a puppy
  • a cobra
  • and so forth.

We’ve got a fire, it’s raging, and I am issuing you a direct order to pour that bucket over the flames! Why? Because earlier, when we were preparing ourselves for this crisis, I filled that bucket up with water. Now all I have to do is say “take whatever is in that thing and do this other thing with it”. The variable is defined somewhere, we can change the value of that variable around any way we want, and then we use that value however we need to. I grab a bucket to put things in, I tell you what’s in the bucket, and now we can use the contents of that bucket to do other things. All I’ve got to do is help you keep track of what’s in which bucket. Make sense?

I’ll see you next time when I offer a basic, non-programmer’s explanation of conditional statements and loops!


Join the Discussion

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s