Programming Logic for the Impatient, Part 2

Thanks for reading through to part 2 of this hasty primer to programming (you can get part 1 here). It’s a poorly planned and half baked idea, the way most legendary code begins.

Here’s something totally counter-intuitive to think about. We are bombarded by ideas about complexity in technology, marketing in the 80s and 90s fostered the idea that technology is complicated and sophisticated and it’s okay not to understand it because of this. We think to ourselves that machines are complex and some kind of nebulous threat. I even fell for that for a long time!

But it’s totally wrong. It doesn’t actually get more simplistic.

Number Munchers. The bar was set very high.

In programming, a piece of code takes one small bit of information and makes some decision about it. That’s it. That’s literally it. The difference between a decision made by the human mind and a piece of code processed by a machine is that the machine can do it as fast as it can order the processor to perform. It’s light years beyond comprehension (for our purposes). Why is this important? Because it’s fundamental in seeing how machines understand the world – bit by bit.

Big decisions, but not really

Routinely you will see statements such as the following if you read your way through code.

  • If x and y are true, and z is less than some number, do this thing.
  • While x is less than y, do this thing. Otherwise, do these other 2 things, and maybe this other thing too.
  • If x is true, check the value of y. If y is less than 1, do z until y is greater than 1.
  • For everything in a list z, while y is greater than x, do this thing. Then after these things are done, do this other thing.

If this does not immediately make sense to you, that’s okay. Consider these alternate statements:

  • If you’re hungry, go to the fridge. Don’t go to the fridge more than 3 times a day, and wait at least 3 hours between visits.
  • If your bladder reaches max capacity, go empty it. If you empty your bladder, flush the waste from the toilet you used (and maybe lower the seat at some random interval because you’re courteous).
  • When the phone rings, answer it. If it’s your mom, stop everything else that you’re doing, sit on the couch, and talk to her.
  • Go to 6 meetings today and do these 10 important tasks, and then go home, but not before you’ve completed everything in some capacity.

These are referred to as conditional statements. They exist in absolutely everything, if you took math in 2nd grade you’ve seen things like “greater than” and “less than”. You can’t decide anything without them. You used one when you started reading this:

  • I have ten minutes. I don’t have anything else to do at this moment. This article is something I want to read.
  • If I estimate that reading this will take me no longer than 10 minutes, I’m reading it.
  • If it gets boring, I’ll stop. Otherwise, I’ll finish it and share it with a friend.

This process happened so fast you barely even noticed it.

Now consider the following things you are probably familiar with, written as simple decisions and instructions:

  • If it is 7:00 am, wake me up.
  • If there is no coffee, don’t drink anything.
  • If there is a Dunkin Donuts, go get coffee.
  • If you are awake, go brush your teeth.
  • When you see the highway, get on it.
  • If you are going to work, travel west.
  • When you get to work, go inside.

These are just simple conditional statements. As building blocks, we can clearly see that they are just small bits of information to base decisions on. True or false, yes or no. In many cases these bits are actually so small that they may be without context – but that’s why we have descriptive variable names to perfectly understand what it is that we’re doing. Remember our last article? If I know what that bucket is supposed to be holding, I can refer to it by name.

We can add these statements together, and since we’re thinking like a machine we are going to be able to do all these things very quickly. I’m not going to add too much additional information but we need to make sure that every outcome is covered so that we don’t do the wrong thing correctly like we talked about in part 1. There are tricks and transformations that we should be using to make this even easier to understand (if you can believe that) but I choose to avoid them to make my point. I also committed myself to no code, but I don’t think formatting something as code is that big of a deal. So,

  1. if you are going to work and if it is 7 am,
    1. wake up
    2. drink coffee and then brush your teeth
      1. if there is no coffee
        1. brush your teeth
    3. if the time is later than 7:45
      1. leave the house
    4. if there was no coffee and you see a Dunkin Donuts
      1. get coffee
      2. if you weigh less than 200 pounds
        1. maybe a donut too
    5. when you see the highway,
      1. travel west
    6. when you arrive at work,
      1. go inside
  2. roll over and go back to sleep

When we nest all this together we can see that it’s not terribly sophisticated at all. We did leave several outcomes out, but for this train of thought that’s okay. Just know that one of the fundamental building blocks in coding is making complex decisions by combining simpler ones. You are already doing this constantly!

One last thing about conditional statements. I have one more observation to make about machines. Doing the same thing over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over and over again (my wrist hurts from all that Ctrl-V-ing) would destroy a human being’s brain eventually. We’re lucky that machines are willing to do this type of thing thanklessly for us. In programming we call such monotonous repetitions loops. They’re actually just another type of conditional statement in which you order a machine to do something repeatedly until something else changes.

I’m a really big fan of outdated technology books. I don’t know why. They’ve got this weird anachronistic quality about them that I can’t get enough of. I have a Novell Netware book from 1994 that’s 6 inches thick propping up my monitor at my desk. I sometimes find gems floating around at thrift stores and I can’t resist.

I can’t (and wouldn’t) visit a thrift store every day, though. My wife would go crazy. Let’s talk about this in terms of a loop:

  1. I don’t have a 700 page book on WordPerfect published in 1990 yet.
  2. Until I find one, I’ll go to every thrift store every day.
  3. I’ll search through every book until I have one.

That’s a loop – do this thing constantly until you meet the reason to stop that I’ve given you. In this case, searching through every book at every thrift store is the thing to do, and the reason to stop is when you find that sweet sweet WordPerfect book that I can use to bookend my Visual Basic volumes and my TAG book about a self programming robot named Rodney.

Next time we’ll cover objects and functions. I hope you’re keeping up with this, let me know in the comments below!



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