So imagine you are hungry and you ask a friend to make you a peanut butter sandwich.
Okay, sounds good, right.
You just say, hey, could you whip me up a PB and J. Yeah, And they just do it. They know to walk to the pantry, they get the bread, they unscrew the jar.
Yeah, and they use a butter knife, not a spoon. It is all entirely seamless.
Exactly because you both share this massive amount of unspoken human context.
We really do. I mean, we rely on intuition to fill in the gaps of our communication every single day.
But now imagine asking a painfully literal robot to do that exact same thing. Oh boy, Yeah, you say, put peanut butter on the bread. The robot grabs the unopened glass jar and just smashes it directly into the loaf of bread.
Crunch, glass and peanut butter everywhere.
Everywhere, because you know, you didn't explicitly tell it to unscrew the lids, so it didn't.
It is basically the perfect recipe for disaster. When we try to talk to machines, we realize very quickly just how much we take our human intuition for granted.
We really do.
Yeah, we speak in generalities, but machines they only understand absolutes.
And that is exactly why you are joining us for this deep dive today. We are looking at a world completely devoid of human.
Intuition, a very literal world.
Super literal. The mission for our deep dive is to explore how humans and machines actually communicate. And to do this, we're using Steven R. Davis's book CLUS plus for Dummies seventh edition as our guide today.
Which is great because it serves as a fantastic foundation for this whole topic.
Absolutely, but just to be clear to you listening, our goal today is not to have you memorize code or like learn syntax.
No, we aren't building a mobile app here.
Right, No apps today. Instead, we want to look under the hood of C plus plus to understand the really fascinating, highly literal way that computers actually think.
We are going to see how a programming language acts as this ultimate middleman, you know, translating our messy human intentions into cold, hard binary reality.
Because the underlying truth of computing is that processes are incredibly fast, but they are also incredibly stupid.
Right, they do not speak English, They don't understand the concept of a sandwich.
At all, not even a little bit.
No, they only understand machine language, which is really nothing more than an endless see of microscopic electrical signals turning on and off billions of times a second.
Okay, let's unpack this, because if they only speak voltage and we only speak human language, we obviously need a translator. We do. It is like we need to draft a peace treaty for this ultra efficient but painfully literal alien species. And that, I guess is the role of an intermediate language like C plus plus N.
That is a great way to put it. You, as the human programmer, write what is known as a source file in a text.
Editor, and that looks a bit like English, right, Yeah, it looks a.
Bit like English combined with some heavy algebra. But the computer still cannot read that source file. It is still too human.
So what happens to it?
Well, a specialized program called a compiler has to step in to bridge that gap.
Okay, I always hear that term compiling. Yeah, but what is it actually doing mechanically? I mean, it is not just reading the text aloud to the computer.
No, it is entirely reconstructing it. The compiler takes your human readable source file and meticulously translates it into object code.
Object code.
Okay, right, but it doesn't stop there. It then performs a process called linking.
What does linking do think of linking?
Like taking different chapters written by different authors. Maybe you wrote one chapter and a standard C plus plus library provided another chapter. Oh I see, yeah, and it binds them all together into one cohesive, executable book that the computer's processor can actually open and run.
That makes sense. And C plus plus is uniquely positions for this kind of heavy lifting, isn't it. Yeah, because the source mentions it is certified as a ninety nine point nine percent pure standard.
Yes, and it is considered a low level language.
Which honestly sounds like an insult, like it is less sophisticated or something.
It does sound bad, But in this world, being low level is a massive compliment.
Really. Why is that?
Because being low level means it operates very close to the physical hardware of the computer. There are fewer layers of abstraction between your code and the actual silicon chips.
Oh wow, so you are right down there near the metal.
Exactly that proximity to the metal is why C plus plus is heavily used for things where performance absolutely counts, things like high end video games, graphics, rendering, direct hardware control.
So it is blazingly fast.
Extremely fast, but because it sits so close to the hardware, it forces the programmer to be incredibly precise.
It demands that precision because, like we said earlier, it totally lacks that human intuition. Right.
A computer does exactly what it is told, nothing more and nothing.
Less, and C plus plus enforces this reality through some incredibly strict grammar rules.
Right, oh, violently strict. For instance, the compiler will completely ignore all the blank spaces or tabs or empty lines you put in your code.
Wait, really, even if I format it nicely so I can read it yep to.
The machine, that is just called white space, and it just throws it out. It does not care about your formatting. But it is obsessively strict about capitalization.
Right the case sensitivity, because if you type I int in all capital letters, it means absolutely nothing to the computer.
Nothing at all. It will just stare at you blankly and probably throw an error that crashes your entire bills.
But if you type in in all lowercase letters.
Suddenly it understands you perfectly. It knows you are giving it specific vital command.
That is wild. This strict literal nature really dictates everything about how we interact with the machine.
It dictates everything. We can't just throw vague concepts or you know, floating ideas at a processor.
So what do we do instead?
We have to package our data, our numbers, our text, our logical states. We have to put them into very specific, rigid containers before the machine will even acknowledge them.
Okay, so if the computer is this pain fully literal with our commands, how does it handle our actual information?
Well, it uses variables, right.
But if I think about basic algebra, a variable is just the magic box. You say x equals one, and then later you can say x equals an entire sentence, and the math just rolls with it.
Yeah, human math is flexible like that. But C plus plus does not allow that kind of freedom, not at all.
You have to tell the computer exactly what shape the box is before you are allowed to put anything inside it exactly.
C plus plus is what we call a strongly typed language.
Strongly typed.
Yes, every variable is essentially a holding tank and you must declare the exact type, the exact physical dimensions of that holding tank in the computer's memory before you ever use it.
And the most common box is that lowercase T we just mentioned right, which stands for integer.
Right, whole numbers one to negative fifty.
But relying on integers introduces a massive mechanical flaw. The book calls it the truncation problem.
Yes, this is where the literal nature of the machine really bites the programmer.
Let me use a real world analogy to explain how bizarre this is to you listening. Imagine you are trying to split three leftover pizzas among three friends.
Okay, you, me and another buddy.
Right, But the accountant managing our pizza party only understands whole pizzas. They are literally incapable of comprehending a fraction.
They do not have the mental architecture for a slice.
Exactly an integer. Only accountant handling the catering.
That sounds terrible.
It is. So we have three pizzas. I take the first one and divide it by three people. The account looks at it and says, one divided by three is less than one whole pizza. Therefore, the result.
Is zero, and they physically take the slices and throw them into the.
Trash, right into the trash. You take the second pizza divide by three, the accountant truncates it again zero into.
The trash, and our buddy does the same thing zero exactly.
We started with three hole pizzas, we divide them up to eat, and the computer mathematically calculates that we now have zero plus zero plus zero, which is zero pizzas.
It is infuriating to a human, but it is flawlessly logical to the machine.
That is so frustrating.
It is if you use integer math in C plus plus to divide one by three, the fractional part isn't rounded down, it is simply lopped off.
It just vanishes.
It vanishes into the ether because the integer holding tank literally has no physical memory space to store a decimal point.
Wait, so if it just throws away the traction, I am literally losing data every single time I do basic.
Division, every single time.
Why on Earth can't the computer just figure it out? Yeah, why can't it just see that one divided by three is a third?
Well, the creators of the language did provide a tool to handle fractions, but it comes with a significant architectural.
Catch, of course it does. What is the catch?
To store decimals, you have to use a completely different type of holding tank, a variable type called a float, which is short for floating point number.
Oh, or you can use its bigger cousin the double right exactly.
The boxes are specifically engineered to handle the decimal point.
Oh. Perfect problem solve, Then we just use floats for everything and fire the integer account.
If only were that simple. There is a constant, unavoidable trade off in computer science between speed and accuracy. Ah the catch right, Integers are lightning fast. The computer's processor can crunch millions of integer calculations in the blink of an eye because they are so simple exactly. Floats require vastly more computational work. But the real danger isn't just the speed. It is that floats introduce round off errors.
Round off errors because a computer, as a physical object doesn't understand the concept of infinity precisely.
Mathematically, one divided by three is point three three three repeating forever right infinitely. But a computer only has a finite amount of physical memory. A float variable can only hold about seven digits of accuracy before it runs out of space, so it just stops. It stops. It stores that infinite concept as a very finite three point three three three three three three. And if you take that float and multiply it back by three, you do not get ten. You get nine point nine nine nine nine.
Oh well, think about that. If you are checking out of an online cart or looking at your banking app, someone is stealing fractions of ascent.
Yeah, the math just doesn't add up perfectly.
Or worse, if you are calculating the trajectory of a spacecraft returning to orbit, nine point nine nine nine nine is not ten. That tiny missing fraction could mean missing the atmosphere entirely.
It is a real problem. Now, the larger double box tries to mitigate this.
How much larger is it?
Well, an inbox has a limit of about two billion, which sounds enormous until you realize modern processors perform billions of operations every single second.
Right, they chew through two billion instantly exactly.
The double box can hold massively larger numbers, up to ten to the thirty eighth power.
That is a staggering number.
It is huge. But even the mighty double starts losing accuracy and generating garbage data after about thirteen or sixteen digits, you just can't win. You really can. You can have massive numbers with loose precision or small numbers with type precision, but the physical limits of memory mean you cannot have both.
So we are basically forced to store our data in these inherently flawed containers. We have integers that are blazingly fast but throw away fractions, and floats that are mathematically precise but slightly inaccurate.
That is the reality of the hardware.
But once you have your data sitting in those flawed boxes, you have to make them interact. You have to get the computer to actually make decisions.
And getting a machine to make a logical choice based on that flawed math is surprisingly dangerous. I can imagine decision making is what makes a program appear intelligent. You know, if this specific condition happens, execute that specific command in C.
Plus plus ah. The core of that decision making process is boolean logic, isn't it, which is handled by a tiny variable type called bool.
Yes, named after George Boole, the nineteenth century mathematician.
Right, and a bool variable is the simplest box of all. It can only hold one of two values true.
Or false exactly, though in the early days C plus plus just use integers to represent this logic.
How does that work?
A zero meant false and absolutely any other number meant true.
Oh that is interesting. That still works under the hood today. But using the words true and false makes the code much more readable for humans.
It definitely does.
But here's where that strict, unforgiving grammar comes back to haunt us. Let's talk about the catastrophic difference between typing a single equal sign and typing two equal signs.
Oh man, this is a rite of passage. Every programmer makes this mistake at least once. Really, Oh yeah, A single equal sign is an assignment operator. It is a command. A command right, It means take the value on the right side and violently shove it into the box on the left side.
Shove it in there, okay.
But two equal signs is an entirely different concept. It is a question. It means are these two things currently identical?
So if I am writing code for an e commerce site and I want to ask the computer is the user's shopping cart equal to zero? But I accidentally use one equal sign, then you are in trouble because I'm not asking a question anymore. I am actively emptying their cart. I am commanding the computer to set their cart to.
Zero, and the compiler will happily execute that command. Even if you buried it inside an if.
Statement, It just does it.
It views the destruction of the shopping cart as a highly successful operation. It ruins the entire logic of your program.
That is terrifying.
It is. But even if you master the grammar and use the double equal sign correctly to ask a question, you still run headfirst into the math quirks we just discussed. Oh right, You should virtually never use the equality operator the double equals to compare two floating point numbers.
Because of the roundoff errors we talked about. Exactly, if the computer is asking is ten exactly equal to nine point nine nine nine nine, it will boldly shout false, even though any human looking at the equation knows the math was supposed to result in ten.
Exact equality is a total myth when it comes to floats, because of the microscopic inaccuracies and how they are stored, you always have to ask if they are close enough. Close enough, Yeah, you have to write extra code to check if the difference between the two numbers is incredibly small. Rather than asking if they match.
Perfectly, that is so tedious. But the way the computer evaluates multiple logical questions at once is where it gets genuinely wild.
To me, Oh, you mean short circuiting.
Yes, C plus plus is secretly incredibly lazy.
Well, we prefer to call it ruthlessly efficient. In computer science, we call this short circuit evaluation.
Okay, let me give an example. Let's say you have a logical A and D statement. For example, I will only go outside if it is sunny. A and D I have my sound glasses.
Makes sense.
Both of those things must be true for the whole sentence to be true.
Right In C plus plus A, you represent that A and D with a double Ampersand.
Now if I look out the window and it is pouring down, that first condition is its sunny.
Yeah is false, completely false.
And because it's an A and D statement, the entire operation is already ruined. Doesn't it matter if I have my sunglasses in my pocket or not, I'm not going outside.
And the computer's processor recognizes this inevitability, it does yes, to save precious microseconds of processing power. If the first condition in an A and D statement evaluates to false C plus plus completely ignores the second condition.
It just skips it.
It's short circuits. It refuses to even look at the rest of the line of code. The same logic applies to an our statement too. If the first condition is true, it skips the second one entirely because the overall statement has already succeeded.
But think about the massive trap hidden in that laziness. The side effects, Right, What if that second condition wasn't just checking a value. What if it had actual operational instructions baked into.
It, like the increment operator.
Exactly, the plus plus which tells a variable to increase its value by one.
This is a classic example of silent failure.
Explain how that works.
Imagine you write a complex statement that says, is variable A greater than variable B A and d is variable C plus plus greater than variable D.
Okay, So if variable A is not greater than b, the computer stops dead in its tracks.
It never even glances at variable C, which means variable C never gets incremented.
Never happened if variable C was supposed to be tracking, like how many times a player tried to log in, or how many seconds had passed, that data is just gone.
It is lost forever.
The program didn't crash, it just silently failed to do its job because the computer was trying to save a microsecond.
And this is why we have to ask, how do you build a stable, reliable digital world when your foundational tools behave.
This way it seems impossible.
The answer is a philosophy called defensive programming.
Defensive programming, Yeah.
Writing code isn't just about getting the syntax right so the compiler doesn't throw an air. It is about deeply anticipating how the machine will stock yiberally lazily optimize your logic.
You have to outsmart it.
You have to actively protect the program from the machine's own ruthless efficiency.
It's almost like you have to stop thinking like a human and start thinking like the machine just to control it.
You really do.
And all of that ruthless efficiency, you know, the stript rules, the flawed math, it all stems from the physical hardware.
Itself, the actual silicon, which.
Brings us to the very bottom layer of our deep dive. Today, we've talked about how C plus plus translates human logic, but what is it actually translating into down at the absolute bottom.
It is translating it all the way down to the metal to pure binary.
See human math feels so absolute, like a universal law, but it's totally biological when you think about.
It, very biological.
We count in base ten the decimal system, we use the digit zero through nine. Why do we do that because we have ten fingers.
If human beings had evolved with twelve fingers, our entire mathematical foundation from birth would be base twelve.
That is so weird to think about it.
But computers don't have human hands. They essentially have two fingers. They are built out of billions of microscopic electrical switches, and a physical switch can only exist in one of two states, on or off, true or false one or is zero.
Base two binary. You know, there's a great joke in the source material about this. If my dog had invented a number system, it would be base eight or octal base eight. Yeah, because if you look at a dog's front pause, he's only got eight visible toes.
That is hilarious but completely true. It illustrates perfectly how arbitrary counting systems really are.
Totally arbitrary.
The math works identically in any base but reading base two is a nightmare for human eyes.
It can't even imagine, like the number.
One twenty three in our familiar decimal system translates to zero one one, zero eleven in binary.
That's just visual noise.
It is your eyes just glaze over trying to parse a screen full of that.
So how do programmers deal with that visual noise without going completely cross eyed?
They create mental bridges. First, they group those individual binary digits, which we call bits, into packages.
Of eight and that is a byte.
Yes, an eight bit package is a byte. And to make those bites readable to humans, programmers use hexadecimal.
Hectadesimal, which is base sixteen right, and hexadecimal uses the numbers zero through nine, and then it borrows the letters A through f to represent the numbers ten to fifteen right exactly.
By using base sixteen, programmers can compress that long, dizzying string of ones and zeros into something short, punchy, and recognizable like seven.
B seven B That is way easier to read.
It doesn't change the underlying on and off switches. It just acts as a visual shorthand a bridge between the physical silicon switches and human comprehension.
Wait, we don't just process numbers. What about characters, text, the alphabet, All of that has to become numbers too.
Right, Absolutely it does. When you declare a chart variable in C plus plus to hold a single letter or a wide char for bigger characters, the computer is secretly just storing a number that corresponds to that letter in a massive index.
Oh, like a secret code.
Basically, the capital letter A might just be the number sixty five.
Okay, I see, But as.
Software expanded globally, we needed much bigger boxes to hold thousands of unique symbols for complex languages like Chinese or Arabic.
Right, sixty five only gets you so.
Far, exactly. That is why encoding formats like UTF eight, UTF sixteen, and UTF thirty two were created.
I've seen those terms in my browser settings. Yeah.
They use more bits, meaning more physical switches to provide enough unique numerical combinations to represent every single human symbol on Earth.
Wow. When you really step back and look at this entire system, all of those strict C plus plus grammar rules, the intruncation throwing away pizza slices, the float round off errors, dropping digits, the lazy short circuiting a and d statements. It is a lot to take in, it is, but they all exist because we are attempting an impossible magic trick.
How do you mean?
We are taking the incredible, complex, nuanced analog reality of human existence and we are forcing it through a tiny, rigid physical pipe of billions of microscopic switches that can only ever say yes or no.
That is exactly what programming is.
And what does this all mean for you listening to this deep dive right now? It means that every single app you use on your phone, every high definition video you scream to your TV, every digital photograph you've ever taken of your family, it.
Is all ultimately just a carefully orchestrated illusion.
It really is. It's a towering, fragile skyscraper built entirely out of microscopic ones and zeros, bundled into bytes, abstracted into hexadecimals, managed by flawed variables, and meticulously translated by compilers.
And that skyscraper is kept from collapsing every single day by programmers who have learned exactly how to draft those piece treaties with the alien intelligence of the processor.
C plus plus is our strict, uncompromising translator in that relationship. Today we've explored the literal minded nature of data variables, the hidden changers of computer math, the lazy efficiency of short circuit logic, and the binary reality beneath the metal.
We covered a lot of ground, we did.
But before we wrap up, I had this realization during our conversation about the increment operator. You know, the plus plus we talked.
About earlier, Oh, the one that gets trapped in the short circuit right.
Adding one to a number is the most common mathematical action in all of programming. But the reason the plus plus operator actually exists in C plus plus is because early microprocessors in the nineteen seventies physically had a specific hardware instruction wired into them just for adding one.
It was faster than general addition exactly.
Hardware memory and processing power were so unbelievably limited back then that saving a few micro instructions was a massive deal. So the software language evolved to include plus plus specifically to take advantage of that one physical wire.
The physical constraints the hardware literally dictated the vocabulary of the.
Software, which leaves me with a chilling thought to end on for you listening, if a physical wire from a nineteen seventies microchip permanently altered how we write code today. How much of our modern cutting edge software is still being shaped by the past.
That is a great question.
The very code running global high frequency finance, or simulating protein folding, or powering the artificial intelligence that is fundamentally changing our world right now, how much of it is still being steered by the invisible ghosts of nineteen seventies hardware limitations.
It really makes you wonder who or what is actually giving the instructions it does.
Next time you ask someone for a peanut butter and jelly sandwich and they intuitively know not to smash the glass jar into the bread, take a moment to be grateful for human intuition. Absolutely, thank you for joining us on this deep dive. Keep questioning the digital world around you. We'll see you next time.