DEV Community: Christopher Sannar

How to Think in Computer: Why They Do the Way They Do (Part 1)

Christopher Sannar — Sat, 25 Apr 2020 21:34:33 +0000

This article is for anyone who just started learning how to program and is struggling to get their brains wrapped around why computers do what they do. It is a guide to help you understand how a computer works and how to get it to do what you want.

Sound good? Awesome. Let's start with some Linguistics.

The Sapir-Whorf Hypothesis

Language is way more powerful than we give it credit for. That's what Sapir and Whorf proposed in their theory of Linguistic Determinism: Your perception of the world is determined by the language you speak. That meaning, your view and idea of reality is limited to your vocabulary.

The neat thing about this theory is that it goes the both ways. When you change your language, you change the way you perceive the world. The more a physician learns about latin and its application to medical language, the more he will begin to perceive the world in a medical context.

You might see where I'm going with this. Computers speak a specific language, a language of numbers and algorithms. As you learn the syntax and semantics of programming, you'll begin to think in computer and approach problems with an algorithmic mindset.

If you start talking in Computer, you'll begin to understand it better.

But what exactly is the language?

Mathematics: The Language of Computers

Yup. That's right. Computers use math, and lots of it. But why math? Couldn't we use something easier like Japanese or Arabic? Well, turns out computers are very very fast (like "count from 1 to a billion in less than a second" fast), but only at doing one thing in particular: computing. They are damn good at multiplying two stupidly big numbers together, but not so good at understanding why I cry while listening to Between the Bars (shut up, I know you do too).

Math is fine and dandy n' all, but not all of us are interested in solely adding numbers together all day. Thankfully a badass in history found a way to apply it to a real world problem which helped saved us from the Nazis. This man alone took computation into a whole new level and built an actual machine to 'compute' numbers as opposed to calculating them by hand; drastically increasing the speed at which we can perform computation.

Since then we've been finding new ways of representing information in a numeric and mathematical context. In short to say, everything you work with on a computer is some kind of representation of a number. Each pixel on your screen is some sort of color that corresponds to a set of numbers. That music you like to listen to (on a computer) is just a collection of numbers that are interpreted into various sounds. Even the letters of this article are just a string of numbers that the computer converts to text for you to read.

Computers are fast. Computers use only math and numbers. We convert information into math and numbers to use computers.

With me so far? Good. Let's keep going.

Information: What We Use Computers For

If you think about it, computers do only one thing: handle information. Checking your bank account balance online? Getting Information. Sending a text message to your friend? Transmitting information. Deleting your browser history? Removing information. A good way to understand what a computer is doing, is to take step back and think in terms of what information is involved.

I could go into a whole other series explaining why we should care about how well we use information, but I'll try not to get too distracted here. Information is important because the advancement of human civilization coincides with how well we can share info with each other. Computers help that progression by providing an extremely efficient way of handling such information. We can see this by how technology evolves alongside the speed of computers. Given I understand it's not the only factor of societal advancement, but it is a very compelling one.

Everything computers do is some way to manipulate information. Information is important to society.

But... Why are Computers so Complicated?

Computers at their fundamental level are actually quite simple. Technically you can compute any mathematical problem with only six operations, but we'll expand on that in the next article. For now, we can understand their complexity in this analogy:

Let's pretend you're the boss at a big company. You're in need of a secretary to handle the menial tasks while you work on the big decisions, so you ask your HR department for a reference and they give you Steve. Before sending him over, they mention two things about Steve: He is very specific, and he is very fast. You thank them, and before you hang up the phone you hear a knock on the door.

It's Steve. Huh, that was fast.

He enters and with a blank look on his face asks what he can do for you. You weren't expecting so quickly, but you manage to scramble up some forms that need to be filled out. You want to keep him busy, so you hand him a stack of about a hundred, show him how to fill each one out, and then send him on his way.

You close your door and head back to your desk, but before you can sit down he knocks on the door. Thinking he might have a question you open up and there he is with a stack of completed forms in his hands. He can't be done, can he? Sure enough though, each and every form as been filled out exactly as you instructed him.

Wow, Steve is very fast.

Completely satisfied (albeit surprised) with his work you send him home for the day. You sit down to inspect the forms he completed, but then you realize a problem: you made a mistake and told Steve to fill out the wrong fields. You're about to call him back, but there's another knock on the door.

Could it be? Yup, it's Steve.

Confused as to why he's back, he tells you he did exactly what you told him to. He went home to sleep, but after napping for 2 months he felt it was time to get back to work. Stunned you stammer out something about the forms and which fields are incorrect. He nods, takes the forms to fill them out correctly.

While he's doing that it gives you a second to think. You begin to realize how much of an asset Steve is, how much work he could get done. However you remember the mistake he made and how careful you have'll to be so it doesn't happen again. Before you can start day dreaming about the company's potential, Steve opens the door and asks for his next task.

From here on, you begin to make a long list of things for Steve to do. You begin to realize that some tasks he's able to do quickly, while others take him a few minutes to get done. Overall he's so fast that instead of doing your normal work, you spend your day thinking of more complex things for Steve to do. Sometimes you make a mistake and have to give him instructions on how to fix it, and sometimes there are some tasks he simply can't do, but overall his work is very quick. Thanks to this efficiency, your company grows and you get to spend more time on your back swing than you do in the office.

As you can guess, Steve is a computer and the boss is you: a programmer. Steve isn't necessarily complicated, his complexity comes from taking advantage of his speed. Learning to code is partly about knowing how computers work, but mostly about the systems we've created to utilize the computer's efficiency. These systems are the field of study known as Computer Science.

Hopefully this article gives you basic idea of why computers do the way they do. In the next article, we'll talk more about the basic rules of computation and how you can approach getting a computer to work.

7 Beginner Debugging Practices I Learned as a Tutor

Christopher Sannar — Tue, 24 Mar 2020 18:47:56 +0000

Here is a list 7 simple debugging practices I picked up as a tutor. I hope they are as useful for you as they were for my tutorees.

Start with a Running Program

The first thing you should do when you start with any project is a “Hello World”. The level of complexity can vary with how you do this (e.g. starting with a template), but the idea is the same: have something running. It is much easier to debug when you have a running program because you can get feedback in the form of print statements.

But what if the program doesn’t even compile? I’m glad you asked.

Comment till it Works

Let’s say you started coding for a bit, changing things here and there, but all of a sudden your program won’t compile. It’s giving you some strange error on line 127, which is odd because your code is only 50 lines long. You start looking around to find the bug but you can’t seem to spot it. You can’t add print statements because the program won’t run, so what do you do?

Start commenting out your code. Begin from the bottom and work your way up, continually re-running it to see if you caught the bug. If you did step 1 right and started with a running program, there must be some point that you introduced a bug. Now it’s time to dig it out. I like to employ a Binary Search to hunt down the defect but use whatever technique that floats your boat.

Sometimes the commenting gets pretty extensive. You might even have to go all the way to your main function before it begins to work. If at this point your code still isn’t compiling, then you have an IT problem and that is something you’re gonna have to figure out on your own. I would suggest you start over with a new (running) project and copy your code over one bit at a time.

Alright, you’ve narrowed down the bug. What’s next?

Read the Damn Error

I know, I’m guilty of this too. So often we just glaze over the novel on the console, but unless you’re coding in C or C++, most compilers have rather helpful messages that will help you identify the error. You might even get lucky and the compiler will give you suggestions on how to fix it. Just don’t dismiss that jumble of words for nonsense, unless of course it’s C/C++.

More often than not, the bug will have an error code that you can google to get a specific fix. If that doesn’t work still try to read the error! Even if you don’t quite understand what the compiler is saying to you, you’ll start to recognize what errors are tied to which bugs. That way, in the future, you can fix your code without having to google it.

Great! So you’re code is running now! What about your run-time errors?

Print, but do so Intelligently

Printing is a great way to debug. Given there are better methods such as using a debugger, but at this point and time it’s important that you get comfortable with printing. Now it’s tempting to print every value you come across so you can keep track of it all, but that’s a recipe for confusion. Just as important as getting the value is making sure it’s the value you’re looking for. Too often I have found myself with 10 or so printed value that I couldn’t quite remember what they were each for. Label your outputs, your 5 seconds future self will thank you for it. So will your 30 minute future self: they’ll be working on another section of code and will realize the printed value is from a statement you should have deleted.

Print to your hearts content, but remember to label an equal amount.

Sanity Checks

Never fully trust your code. How many times have you said “Well my variable should be * ...” but you still get an error? I’ve learned very quickly in my life that the word ‘should’ is very dangerous and needs to be handled with military grade dicipline. Even when the value is staring you right in the face, make sure it’s the right one at the right time. You can do this by (intelligently) using print statements to verify your values. This goes for functions too. It’s good practice to throw a print stub at the beginning of each function to make sure it’s being run. I usually just put the functions name, but again, do whatever floats your boat.

Just remember, every time you say ‘should’, do a sanity check.

Talk to a Rubber Ducky

Once you have made enough sanity checks, it’s time to talk to your therapist. Given a coding buddy is better at helping than an inanimate object, but they’re probably working on their own project at the moment and (let’s face it) what you need isn’t another programmer, but a friend.

Rubber duckies are excellent buddies. They don’t talk back to you, they’re always smiling, and they don’t drop out last minute on your group project. Your rubber ducky is here to help, here is how you can use it:

Talk to the rubber ducky.
Explain what you’re doing. Tell them how you did it.
Go through each line of code you’re having trouble with while explaining what you’re doing.
Realize that you didn’t make the right function call.
Correct the error.
Thank your rubber ducky and then continue coding.

Look, I get it. We all get lonely sometimes, and there is no shame in talking it out with your fellow bathtub companion. You’ll realize you have more in common than you thought and that you make a great coding team. One, a brilliant coder, the other, the perfect confidant.

Never be ashamed to talk to your rubber ducky.

Walk Away

Well, I guess it’s come to this moment. You’re at the end of your rope unsure as to why the code isn’t working. You have tried everything and yet you still don’t seem to be making any progress. When you’re at this point, the best thing you can do is walk away for a bit. Your brain is an amazing machine, it can work on problems without you even realizing it. If you just take a breather and focus on something else, your subconscious will keep spinning on the primary task at hand. After a few minutes, give or take an hour, come back to your code and give it another go. You’ll be surprised how useful a fresh perspective is.

Your subconscious is a powerful tool. Let it do it’s job.

Final Thoughts

I hope you can tell I’ve pulled my own hair out many times because I failed to follow these practices, but now I’m a better coder because I learned from my mistakes. Eventually the more you code, the better you’ll get at spotting these bugs before they happen. You’ll also employ better debugging practices such as TDD (Test Driven Development) for quicker, more efficient programming. However, the most important thing you can do now is be patient and keep coding, you’ll get there eventually.

Cheers