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!



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!