Let’s jump right in at the only place we can: the very begining. The programs we write every day are based on orchestrated algorithms and data structures that all have their roots in a single thing: LOGIC. Let’s quickly explore some basic logical rules as we’re going to build on them later on.
Logic… What Exactly Is It?
The first, most obvious is question is how are we defining the term “logic”. There are a few different definitions so let’s start with the first, offered by Aristotle.
In trying to come up with a framework for thinking, Aristotle described what are known today as The Laws of Thought.
The first is The Law of Identity, which simply states that a bit of logic is whole unto itself - it’s either true, or false, and it will always be equal to itself.
Here we’re describing this as
x === x, which… yes… I know seems perfectly obvious but stay with me.
The next law is called _The Law of Contradiction_, which states that a logical statement cannot be both true and false at the same time. Put another way - a true statement is never false, and a false statement is never true.
Again - this is perfectly reasonable and seems obvious. Let’s keep going with the third law: Excluded Middle.
y to true and false and playing around with different operations - the only thing that is returned, based on those operations, is
false - that’s Excluded Middle in action.
And right about now some of you might be bristling at this.
undefined. The idea here is that there’s a third state, that’s neither true nor false - which is undefined. You can also think of this as
null for now even though, yes, null and undefined are two different things. We’ll lump them together for the sake of defining what’s known as “ternary logic” - or “three state logic” which kicks Excluded Middle right in the teeth.
Aristotle had a problem with his logical system - it only deals with things that are known. The only things we can know for sure are things that have happened already and that we have witnessed somehow… even then there’s a question of whether we truly know them. Let’s sidestep that rabbit hole.
When asked to apply his Laws of Thought to future events - such as “will Greece be invaded this year” Aristotle replied that logic cannot apply to future events as they are unknowable. An easy out, and also a lovely transition to Ternary Logic.
Let’s bring this back to programming. You and I can muse all day about whether Aristotle’s brand of logic - which we can call “binary” for now - is more applicable or whether the world can be better understood with the more flexible ternary logic. But I don’t want to do that because I’m here to talk about computer programming and for that there’s only one system that we can think about - a deterministic system.
If you read the first Imposter’s Handbook you’ll likely remember the chapter on determinism (and non-determinism). If not - a simple explanation is that a deterministic system means that every cause has an effect and there is no unknown.
Programs are deterministic because computers are deterministic. Every instruction that a computer is given is in the form of groups of 1s and 0s… there are no undefined middle points.
This is important to understand as we move forward - the math that we’re about to get into and the very advent of computer science is predicated on these ideas.
I know what you’re thinking though…
What About Null, None, Nil or Undefined?
Programming languages define much more than simply true or false - they also include the ability to have something be neither in the forms of null, nil, none or undefined. So let me ask you a question… is that logical?
Let’s take a look.
What about being equal to not-not itself? Well that’s false as well which makes a bit of distorted sense because
!y is false so
!!y returns true… I guess. But if something is
We can short-circuit our brains thinking about this but let’s not…
The Billion Dollar Blunder
The creator of ALGOL, Tony Hoare, is credited with creating the concept of
null in a programming language:
I call it my billion-dollar mistake…At that time, I was designing the first comprehensive type system for references in an object-oriented language. My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.
Have you ever battled null problems in your code or tried to coerce an undefined value into some kind of truthy statement? We all do that every day.
Computers aren’t capable of understanding this. Programming languages are, apparently and at some point the two need to reconcile what
undefined means. What makes this worse is that different languages behave differently.
nil and has a formalized class, called
NilClass for dealing with this unknowable value. If you try to involve
nil in a logical statement, such as greater or less than 10, Ruby will throw an exception. This makes a kind of sense, I suppose, as comparing something unknown can be … anything really.
But what about coercion? As you can see here,
nil will be evaluated to false and asking nil if it’s indeed nil will return true. But you can also convert nil to an array or an integer… which seems weird… and if you inspect nil you get a string back that says “nil”. We’ll just leave off there.
null operations as it will try to do it’s best to give you some kind of answer without throwing an exception.
10 _ null is 0, for instance… I dunno…
It’s the last two statements that will bend your brain, however, because
10 <= null is somehow false… but
undefined are abstractions on top of purely logical systems. Each language gets to invent it’s own rules.
null is you’ll get
object back - which isn’t true, as MDN states:
Let’s take a look at a more “structured” language - C#. You would think that a language like this would be a bit more strict about what you can do with Null… but it’s not! OK it DOES throw when you try to compare null to !!null - that’s a good thing, but when you try to do numeric comparisons… hmmm
And null + 10 is null? I dunno about that.
So, what’s my point with this small dive into the world of logic and null? It is simply that null is an abstraction defined by programming languages. It (as well as undefined) has no place in the theory we’re about to dive into. We’re about to jump into the land of pure logic and mathematics, electronic switches that become digital… encoding… encryption and a bunch more - none of which have the idea of null or undefined.
It’s exciting stuff - let’s go!
I'm a big fan of testing, but I get lazy sometimes and it ends up costing me money, directly.
TDD is one of those things that people talk about, argue about, and think is interesting. I'm one of those people, so I asked Brad Wilson to clear it all up for me.