Coding For Beginners

... or how to program programs with programming

Copyright © 2020 by Roger Engelbert

All rights reserved

For information about permission to reproduce selections from this book,

write to rengelbert@gmail.com under subject Coding For Beginners Excerpts

Engelbert, Roger.
Coding For Beginners: or How to Program Programs with Programming /
Roger Engelbert.—1st ed.
p. cm.
ISBN 978-1-912084-27-2
1. Computer science. 2. Computer software. I. Title.
QA75.5-76.95
QA76.75-76.765

Engelbert Publishing.
www.rengelbert.com
 Coding For Beginners

... or how to program programs with programming

Roger Engelbert
 For Daniel,
who had to learn all this the hard way.
Contents
Part 1 • Introduction
Chapter 1 • Feynman's Clerks
Chapter 2 • But Why!
Chapter 3 • About this book
Chapter 4 • Let's Sort of Code a Sort
Part 2 • Conversion
Chapter 1 • The Spell Checker, The Translator, The Critic and the
Wardrobe
Chapter 2 • All The Wrong Questions
Chapter 3 • HOWALIVE
Chapter 4 • I Promise This Is Not About Bitcoins
Part 3 • Find And Replace
Chapter 1 • Backdoors
Chapter 2 • What's In A Name?
Chapter 3 • Sell you for Scraps
Chapter 4 • Reading is For Champions
Part 4 • Express Yourself
Chapter 1 • Aristocles And His Stick
Chapter 2 • We Are All Cousins
Chapter 3 • Intelligent Women Marry Dumb Men
Chapter 4 • Birthday People
Chapter 5 • Randomness Is Strange
 Chapter 6 • Let's Ruin Magic
Chapter 7 • Oh, Monty!
Chapter 8 • Let's Ruin Magic... Again
Chapter 9 • The Shape Of The Planet
Chapter 10 • Space-time
Part 5 • Paradigms
Chapter 1 • Walk this way
Chapter 2 • Procedural Murder
Chapter 3 • Object-Oriented Programming 101
Chapter 4 • Object-Oriented Murder
Chapter 5 • Functional Programming 101
Chapter 6 • Functional Murder
Chapter 7 • Other Considerations
Final Thoughts
... How to Keep Learning?
 Part 1:
Introduction
 1
Feynman's Clerks
{

In 1984, Physicist Richard Feynman presented a series of lectures entitled

The Idiosyncratic Thinking Workshop at Esalen Institute in Big Sur,
California. The workshop lasted a week and Professor Feynman covered a
variety of subjects related to science and the human experience of it. In this
workshop’s second iteration, in 1985, he presented a talk entitled Computers
From The Inside Out. This was a concise version of certain lectures he had
presented at CalTech in previous years which were later collected in a
wonderful book called Feynman Lectures On Computation. They're an
introduction to Computer Science, to how computers work and their
limitations (at the time).
Lucky for us, we can still find the Esalen lecture on YouTube.
Bill Gates once called Feynman "the best teacher he never had" and you
can see why in the video. In the space of 50 minutes Feynman explains what
a computer is and what programming a computer means. Along the way he
touches on artificial intelligence and how it differs from the human sort. He
also mentions machine learning through pattern recognition and heuristics;
and touches briefly on the “joys” of multiprocessor programming (a problem
he was actively working to solve at the time). It’s mind-boggling stuff. At
one point Feynman says computers could not be used to run things like facial
recognition algorithms and then pausing briefly he goes on to explain just
how exactly one would go about doing it. You realize what he meant was that
computers couldn't do it... yet. (And of course, they can now, using the exact
process Feynman describes).
But by far, the best part of the lecture is his story involving a series of
“dumb office clerks.“ This is also included in the book version of the
lectures, therefore we can assume he first presented the analogy in his
CalTech lectures. In the story, we hear about filing clerks working for some
generic sales company who progressively get dumber and dumber but also
faster and faster. We start with a reasonably intelligent clerk who is
unfortunately a slow worker. Then the company hires a clerk who is five
times faster but who can't add numbers. The next clerk they hire is ten times
faster than the previous one but he can't multiply. The next one is again faster
but "he doesn't even know that these are numbers!" The story serves to
illustrate the point that the computer is an incredibly dumb machine but also
incredibly fast. It's up to a human being to feed it the proper, and extremely
simple instructions.
Feynman begins the lecture with this pearl: "One of the miseries of life is
that everybody names things a little bit wrong, and so it makes everything a
little harder to understand in the world as it would be if they were named
differently." A computer, he says, does not compute. Or at any rate, this is not
its main function. You can make a computer compute, just as you can make a
computer draw a picture or brew a pot of coffee. You can tell the computer 2
+ 2 = 4, just as you could tell the computer it isn't. A computer is rather a
"data handler," Feynman concludes. It manipulates data according to the set
of rules you feed the machine. It can read and process or "follow" these rules
incredibly fast, and repeat the same instructions ad infinitum with perfect
replicability. If the instructions contain an error, this too will be replicated
perfectly ad infinitum.
"I like to compare it to a filing system,” Feynman begins, and in comes the
dumb clerks. Each more helpless than the previous. One can’t add, another
can’t multiply, the next can’t read or even know that numbers are numbers.
But each clerk is faster than the previous one. The final clerk can’t do
anything other than hold a simple distinction in his head: A or B, Black or
White, 1 or 0. "He's really quite stupid, but man is he fast!" (Feynman uses
the colors brown and orange for this in his example because those were the
color markers he had available but the video feed cannot pick up the
distinction between the two colors: that's technology for ya!)
The solution the company arrives at that enables them to use dumber but
faster clerks is to define all the operations—addition, multiplication, reading
alpha numeric characters...—as a series of simple procedures involving
nothing more than what the dumbest clerk's natural ability to distinguish
between 1 and 0 can handle.
 Feynman shows how one can perform the procedural equivalent of adding,
multiplying and reading and writing by using a simple binary distinction.
Why binary? Because it's the simplest change in state: on or off, yes or no.
The simplest distinction for the dumbest clerk of all. Even traffic lights may
have a more complex state if they contain a yellow light. Yes, computers are
dumber than a traffic light. Small electric charges are used to create these
changes in state, but Feynman, being Feynman, shows how you could do the
same thing using hydraulics. He even illustrates how simple logical operators
work inside this hydraulic machine, creating the logical AND and OR
operations, also known as Boolean Operations, using logical pipes. Listening
to him saying, in his Bugs Bunny accent, "Squirt, squirt, squirt!" is one of the
highlights of the lecture, in my opinion.
Most of the operations running your apps, games and media players are
built on simple logical operations running on ones and zeros, flowing through
logical pipes.
The last clerk in Feynman's analogy is eventually replaced by a machine,
the dumbest clerk of all. When all the instructions for this machine are
finalized the hypothetical company, we learn, changes to a different sort of
business and lo and behold the machine can work for the new type of
business as well, by simply changing its instructions. If one can write the
instructions for a task in a way the machine can understand and process, the
machine will perform the task repeatedly and without variation. Whatever it
is. And for an extra bit of history, Alan Turing proposed such a machine in
1936. According to Wikipedia: “His ‘universal computing machine’ would
be capable of performing any conceivable mathematical computation if it
were representable as an algorithm.” But the machine, you see, will always
do the same thing, the same operations. It doesn’t know it’s running Candy
Crush or Photoshop, and it doesn’t do anything fundamentally different when
running either of those. The machine is quite dumb! (At least for now. In
future, when I’m tried for heresy at the first AI Inquisition Symposium, I’ll
make a pun about being executed and the computers won’t get it. Or maybe
they'll be so advanced by then, they'll groan and roll their mechanical eyes).
To be fair, and I'm not back-pedaling here, computers are not intelligent in
the way we are intelligent and therefore they are not dumb in the same way
we are. Feynman uses another brilliant analogy to explain this. If you want to
make a machine run as fast as a cheetah, he says, it would be stupid to make
the machine run like a cheetah. No, you would use wheels or make the
machine glide just above the ground in order to reach the target speed. In the
same way that airplanes fly but they don't beat their wings like birds do. The
intelligence found in computers is of a different form than the one found in
humans (some of them, anyway). We're matching results, not process—a
very important distinction in programming.
A programmer is someone who writes the instructions that the machine
will repeat over and over again until a job is done, or the user is done with the
thing running the instruction and goes off to make some tea. Programmers
nowadays use an abstract form of the basic operations so that the code written
can be easily read and understood by humans. These programming
languages, when compiled, are translated into the simpler elementary
operations Feynman talked about.
A specific computer architecture was settled on fairly early in computer
history. One built around these simple instructions, also known as operations
or commands. Things like: add, subtract, multiply, as I've mentioned. But
also load, store, compare. It is said that 95% of all code uses only 20 of these
instructions. We'll use them a lot. But what you'll learn to program with in
this book are the abstractions, the reasonably easy to read lines of
instructions. Some programming languages are still very much Tarzan-like in
the way they express things. These are called low-level languages and are
generally unreadable. Others have actual words in them and are called high-
level languages and sound almost human-like (though not quite).
These abstractions themselves are a step in the evolution of computer
science. Programming is governed by two laws: There Must Be An Easier
Way and Keep It Simple, Silly. All other possible laws are corollaries of
these two. People began feeding instructions to machines entering these by
hand: writing long series of obtuse numbers or punching holes on cards.
These methods were error prone and also long and so, so boring. Thus the
first law was created: There Must Be An Easier Way. And people went on
about finding better ways, people like Feynman and Grace Hopper and many
others, and sure enough along the way the solutions became too convoluted
and thus the second law was created: Keep it Simple, Silly. Eventually,
computer scientists began using actual words in their instructions and to use
syntax humans could actually read and posit about. They invented interpreter
machines who could convert these "human readable" keywords back into
instructions the machine was programmed to understand. Not satisfied with
that, these people invented other machines that were programmed to find
errors in their code and point these out to the programmer. We moved from
feeding the instructions to the machine via a secondary source—a punched
card, for instance—to the rabbit-hole of programming a machine from within
the machine and using a program to do it with (we program programs with
programs!).
One can derive a lot of pleasure from the first rule, finding solutions to
problems that cut down work time and optimize results. The second rule,
which is harder to apply and harder to conceptualize, gives even greater
pleasure because when you find a way to make things simpler, a way you
haven't seen before, and this new way is something you worked out by
yourself... oh boy, that feeling...
This book is about the instructions Professor Feynman talked about. About
how to write them, read them, and how to think and express ideas based on
those instructions. To find better ways to do things and maybe, hopefully, do
it in such a simple and elegant way that the work will never cease to amaze
you.
 2
But Why!
Why should you learn to program? If we leave out, for now, the prospect of
a new career, why should anyone bother to learn this stuff? The two most
common answers you'll find are:

1. Programming helps you to think better and this, to some extent, will
improve you as a person.
2. Programming teaches you how to break tasks into smaller chunks.
And to some extent, this will improve you as a person.

I find them both crap. I suspect the origin for these pat answers is an
interview given by Steve Jobs, just before his return to Apple. This is where
his famous "Computer Science should be a Liberal Art" speech comes from.
If you Google possible benefits to learning to program you'll be given a link
to this interview, or more likely, a link to the excerpt containing the famous
speech.
To be fair, in my opinion, those two reasons hold some truth in them and
it'd be easier to argue about other possible reasons using them as guidelines.
So here it goes...

It helps you to think

I don't want to get into a whole discussion of what intelligence is and the
role it plays in life. Randomness, as we'll see later, is far more influential than
any attempt at control you may dream up on your own—at least in the real
world. But does programming help you think, or improve thought in any
way?
It's all a matter of expression and representation.
 Different problems need different solutions. Particularly if you're abiding
by the Two Laws I mentioned earlier. Sure, some problems will have many
solutions. But you'll often find some ways are better at expressing the
problem and representing it in your mind. It's a cognitive thing. Let me give
you an example, using two cognitively different ways to express a problem:
Words and Math.
There is a famous—and by now a cliche—math problem called The
Baseball and the Bat problem. The story goes that a group of students
entering some big-name University in the US tried to solve it and 80% of
them failed. Whatever. I don't want you to solve it. I don't want you to think
about it even. I want you to feel it. The problem goes like this:

A baseball bat and a ball cost $1.10 together, and the bat costs $1.00
more than the ball, how much does the ball cost?

Part of the beauty of the problem is how the words trick you into thinking
there is an intuitive solution. But don't pay attention to that. Just notice how
you feel when you state the problem in Word-Mode: You're looking for how
much something costs and there's this other thing that costs one dollar more
than the first thing and both of them together will cost 1.10. Ahhh! Can you
feel it? Can you feel your brain running out space? I do with mine.
But if you express it in Math-Mode: x + (x + $1) = $1.10. Boom. Because
one thing is x and the other thing we know is x + $1 and they both add up to
$1.10. Can you feel the difference? In my brain, at least, I don't experience
the same "running out of space" feeling. My brain actually relaxes a bit and
wonders what's for lunch. Some people, when solving these sorts of
problems, will go straight into Word-Mode and try to express the problem
this way and get stuck. Some will go for Math-Mode or a mix of the two. The
first group is made of people who tell themselves, "I suck at math." The
second group thinks math is alright—for some things. The so-called word-
problems we got at school—the sort involving trains traveling somewhere at
some speed—were meant to confuse us by overloading our tiny brains in
word-mode. We were meant to take a deep breath, relax, and retrieve what
we knew about the problem using math-mode and solve it, one step at a time.
Some people experienced great joy in not being tricked, or were able to
admire the artfulness of the trick being played on them, others panicked and
blamed math for the word-mode overload.
 Programming is a lot like those word-problems. But particularly in the way
we must solve them. Relax. Think about what you know, start from there.
Work each part of the problem, step-by-step. Build up the "expression" of
what you're trying to solve. But is this a better way of thinking? Sure.
Sometimes. I guess.
It's all a matter of expression and representation as I said. How one step
links to the next, or one idea grows into another. The way you express and
represent something helps, it can stop overload on its tracks. And you should
know by now that words, numbers, and pictures are not the only game in
town when expressing a problem. You can use lists and index cards and
graphs and rhymes... And yes, programming.

It helps you to break problems into smaller chunks

Again, this is a matter of expression and representation. Programming can
teach you the habit of seeing a problem by its interconnected parts and not
the whole overwhelming thing all at once. And at the same time, it allows
you to express something larger than the sum of its parts without running out
of space. Programming helps you to think of a moment, a point in time,
through all its possible instances. All shoved together into the same space.
Another way I like to think about this is the definition of an Aleph, from
Jorge Luis Borges's famous short story by the same name. Wikipedia says:
"In Borges' story, the Aleph is a point in space that contains all other points.
Anyone who gazes into it can see everything in the universe from every angle
simultaneously, without distortion, overlapping, or confusion."
That's it. That's programming. Want an example?
Take game programming. In a game, you usually code a snapshot. Just as
with movies, the game will be the result of a series of these snapshots
swapping places on the screen creating the illusion of time an animation. On
one snapshot Mario is about to jump. In the next he's rising. Nothing is
colliding with him because all the enemies, coins, and platforms are too far
away, so we don't bother with any of those. The same goes for the next dozen
snapshots, but now he's falling. Nothing happens for another dozen snapshots
until he's finally about to touch the platform. Does he touch it? No, not yet,
not in this snapshot. But in the next one, he does. Phew! "We got him! We
got Watney!".
And then what does Mario do? He jumps again. Crap. All the things that
can happen with Mario in one snapshot are contained in the program.
Hammering the turtles, fighting the different bosses, rescuing the Princess...
everything. All instances trapped in every single moment. In order to get the
next snapshot we call:
mario_game.update();

We do this about sixty times a second. That's it. The same call. The same
function. If Mario is jumping, ducking, dying, all goes in this one function
handling one snapshot only. Like the Buddha, the code knows only now. If
we were to code a human life the same way, we would code instructions to
anything that might happen at any split second from age 0 till game over,
from all angles, "simultaneously, without distortion, overlapping, or
confusion". And why without confusion? Because our brains didn't run out of
space. We expressed and represented all the scenarios in a way that allows
them to just sit there, in our head (and ideally in a script file, and ideally with
lots of backups) and we can navigate this expressed structure, traverse its
nodes and see the whole thing by its parts. All this, done in far fewer lines
and "words" than it would take to explain it all in Word-Mode.
Programming is a way to express a thing while taking into consideration all
other things that can happen at a given moment. By definition it should turn
you into an over-cautious, mumbling fool. But it doesn't.
There's this magical moment when you're in the middle of it all. When all
these things are in your head. It's like Cicero's Memory Palace, only way
better. More like a Memory Continent. At that moment you are in the zone. A
problem is not being broken into smaller parts as Steve Jobs said. That
doesn't cover it! The problem is being expressed in tiny movable parts. And
you know them all. At that moment you're like those car mechanics who
know the problem with an engine because of the sound it makes. They hear it
for one second and go, "Ah, yes, the flux capacitor is stuck in 1985." And this
mechanic can do this for the same reasons. The mechanic is able to express
and represent a car engine by its interconnected parts and merge into that
expression all possible states of the engine.
To be honest, you won't get to experience that in this book. You don't
experience it with every program you write either. It's a matter of scale.
Usually, with smaller programs, it feels more like writing a bad poem,
looking for words that fit.
This is another common thing people say about programming. They
compare it to poetry.
Fred Brooks, a famous computer architect, has this quote: "The
programmer, like the poet, works only slightly removed from pure thought-
stuff. He builds his castles in the air, from air, creating by exertion of the
imagination. Few media of creation are so flexible, so easy to polish and
rework, so readily capable of realizing grand conceptual structures. Yet the
program construct, unlike the poet's words, is real in the sense that it moves
and works, producing visible outputs separate from the construct itself. […]
The magic of myth and legend has come true in our time. One types the
correct incantation on a keyboard, and a display screen comes to life,
showing things that never were nor could be"
Awww. Nice.
Of course when it all goes wrong, I'm always reminded of another famous
quote: "Ah, shi*! Mother fu***! WHY DID I BOTHER!!!" I'm not sure but I
think it's by Mother Theresa.
But there is a good reason to compare programmers to poets. It has to do
with the need for brevity, the need to overwhelm words with meaning as in
poetry, but also it has to do with the constraints. Oddly enough this is also the
reason people form the idea that programming is boring: its constraints. I
cannot be creative with it, surely! one might say. Nothing could be further
from the truth. To quote Danish philosopher Søren Kierkegaard: "The more a
person limits himself, the more resourceful he becomes." Programming is all
about slipping through set boundaries. Not like breaking the law, or killing
someone inside a locked room. But at its best, it feels like a morally correct
and intellectually stimulating form of cheating. You're looking, after all, for
the simplest and least complicated solution to a problem.
There is a category of writing known as Constrained Writing. Wikipedia
defines it as, "A literary technique in which the writer is bound by some
condition that forbids certain things or imposes a pattern." Poetry can be an
example of this, of course. Another famous example is the book Gadsby
published in 1939 by the author Ernest Vincent Wright. The entire novel is
written without using any words that contain the letter E (all translations of
the book also followed similar constraints). Ernest Vincent Wright might not
have known this, but he was a programmer at heart. And there's more. There's
a form of English known as E-Prime, which is English without the verb to be.
The idea behind it was that the use of the verb to be turns people into
dogmatic pricks (like most people on Twitter). Or rather, it allows "even the
most ignorant to transform their opinions magically into god-like
pronouncements on the nature of things." This is this, that is that. I am this,
you are that. You can see their point. Now imagine saying those things
without the verb to be. E-Prime is another example of constrained writing and
so a lot like programming in many respects. And remember Kierkegaard:
these constraints make you resourceful. They don't kill creativity at all.
Creativity is a form of resourcefulness, and therefore it is improved—if not
originated—by constraints.
And it's fun! Which to me is one of the best reasons there is to learn to
program. Why is it fun? Because it's constrained. Like a puzzle.
So programming can help me express some problems differently, hold a
bunch of information in my head and can be fun due to its constraints?
That's it.
Unless, of course, you want a job...
If there was an industry for poetry, poets would be dealt with in the same
way programmers are dealt with in the computer industry. The companies
would find ways to make the poets highly replaceable, because who wants to
depend on their employees, am I right? It's a recipe for disaster! So the
"writing of poetry" would become something methodical, highly structured
and modular, with every poet made to write just like every other poet in the
company, so that if one drops like a fly from exhaustion or because one poet
dared to feel like, you know, a human being (the bastard!), then another poet
can be easily found to replace him. Rhymes that worked well once would be
reused till our ears bled from hearing them. And entire methodologies would
be created to ensure all poems looked the same, targeting average readers so
the maximum number of readers could enjoy them. Poets would have a small
list of approved and time-tested allusions and allegories at their disposal and
would be absolutely prohibited from using anything else. Any whiff of
originality must be submitted in writing, with triplicates, and reviewed
through a series of long, long meetings where everyone tries to answer the
same question: can this new thing be made to look just like the old thing?
 You know. Work. What fun.
It must be said that the movie industry did the same thing to movies and the
publishing industry did the same to books and you might think that working
in those industries could be quite fun. And you're probably right. After all,
they provide one with lots of constraints and so bring out one's
resourcefulness and creativity.
Hold on to that thought. Because another quote of Fred Brooks that I like
says: "All programmers are optimists."
So, you see! You're a programmer.
In the interest of full disclosure...
Can all this be applied to other areas in life?
I doubt it. I'm a programmer and spend the majority of my time feeling like
a fool. The kind of person who always picks the shopping trolley with the
whacky wheel. That's me!
Are these benefits exclusively derived from programming?
No. I suspect crocheting will do as much. But I don't know how to crochet.
Can it make me a better person?
Nah. Helping other people will.
But boy, can it be fun!
And then there's all the stuff you can make.
The industrial revolution killed customization! We're forced to use things
made for the average person so they can serve the greatest possible number of
people. And that includes Apps (and yes, even those that try very hard to be
"fully-customizable" like Notion or AirTable). The modern world is not made
for individuals, just ask vegans and people with strange food allergies how
the world finds the time to meet their needs. With programming, the Do It
Yourself life-style takes on a whole new meaning and your computer and
mobile phone can become a true extension of yourself. And what's more, you
could make money too. Like Emerson said in his famous Self-Reliance essay,
genius is when you do something for yourself, attending to your needs, but it
somehow connects with a bunch of other people and their needs without
having to produce something average to net the most customers.
Ok, working with programming is not necessarily fun. Work is work. But
it's hard to find many professions where people willingly keep doing at home
what essentially they spent the day doing at their jobs. Artists do this. And so
do programmers. There must be some good in it.
It's either that or learning to crochet. Face it. It's time to buy a black turtle-
neck jumper and start being all nerdy and stuff.
 3
About this book
This book will avoid many conventions used in the majority of
programming books. I will not focus on one single language, I will not prattle
on how big an integer can get, I will not mention the word Fibonacci save
this once. You won't have to find new prime numbers or factor anything. I
will not ignore math altogether, but you don't have to like math or be good at
it to read this book. (You don't have to use it later either if you don't want to).
You don't have to be methodical, highly-organized, self-disciplined. You
don't need glasses, pen-protectors or the word "egad". You just need to
express and represent things using a constrained form of writing. You can do
that in your own unique way. Later, little by little, you may wish to look for
better ways to do it, if such a thing exists. Or not.
This book won't be the boss of you.
I will use quite a bit of math. But I'll keep most of it tied to simple
operations, like calculating averages and percentages. Don't let this give you
the idea that math is vital to programming, at least not the math you may
have hated (wrongly!) in school. Computers don't compute, as Feynman said,
they handle data. And if this sounds boring, I hope to cure you of that notion
in the next chapters.
It won't always be easy, of course. Particularly in the last few chapters. I
could have ended on a good note and leave you with the sense you've learned
it all. I could ignore some of the heavy topics. I won't. This book is meant to
be read more than once, or at least to serve as a reference for further learning.
I will introduce new ideas and new syntax up to the very last page. Don't try
to learn all the different ways to do the same thing, instead, identify the
commonalities shared between them. Remember that, at the heart of it, we're
talking about twenty or so extremely simple operations, used and reused and
rearranged in all sorts of ways to produce all sorts of results.
I'll start with numbers then move on to strings (text). I'll try to find fun
examples to work on, but I've lived long enough to know my idea of fun is a
bit of a misnomer.
The first part of the book will deal with conversions. Take one thing or
value and transform it into something else. It will focus on numbers, to begin
with, and then move on to text.
The second part will focus on finding and sometimes replacing bits of text.
It doesn't sound very sexy, I know. But give it a try.
In the third part, you'll use what you've learned to express problems and
solve them. There will be more math, and some drawings, and loads of new
ideas. And some old ones too.
The fourth and final part will introduce the three main programming
paradigms: Procedural, Object-Oriented, and Functional.
You'll see code done in Python, C#, JavaScript, and F#. Nothing too "in-
depth", mind you. No book ever could cover all those languages in depth. I
want you to focus on the ideas and not syntax. If you want, you can find the
source code listed in the book as well as answers to exercises in this book's
website at www.rengelbert.com/codingbook/.
Having said all this, I can state with reasonable certainty that if you've
never seen programming before you will find it much easier than you
thought. And if you have seen some programming before and think it's easy,
this book will change your mind as well.
Either way, you'll be coding before too long.
 4
Let's Sort of Code a Sort
Most books on programming, particularly those covering algorithms, will
start with a sorting program. Booooring. But tradition is tradition, and I'd
consider disrespectful not to cover a simple sorting problem right at the
beginning. I won't use code, not even pseudo-code. Instead, think of this
chapter as something to get back to when all the syntax is decidedly under
your belt. I want to focus now on thinking about a problem before we tackle
coding it.
And sure, it will be a really boring problem to start with. I'll try to make the
examples and exercises in this book as interesting as I possibly can, but I do
realize this may be a losing battle. So pretend that this is your job for now.
If your job was to separate oranges from apples, how would you do it?
Seriously...
Well, I would look at them, see which one is an apple and which one is an
orange and move one away.
Do you mean one, general, quick look? A gander?
OK. First lesson in programming: the solution for one or a few things
should work for a ton of things. Remember, we are coding all instances of a
moment. So what if the fruit is inside a container, tons and tons of it and you
can't see them all in one quick glance?
Fine. I'd do it one by one then.
Yep. Thank you. But how?
Or consider this next problem. I saw a Venn diagram the other day, the two
sets were: elemental chemical symbols and the state codes used in the US. It
looked like this:
Venn diagram of elemental chemical symbols and state codes used in the
US

So let's say this is your next job, finding the overlapping 2-letter-codes.
Can you explain how the first problem, the one dealing with apples and
oranges, is different from the second one? And in which way they're similar?
Something like: With apples and oranges we're sorting them using their
differences, but with the Venn diagram we're looking for similarities.
What if your boss, in this imaginary job of yours, came in and told you to
create that same Venn diagram but to add the set for 2-letter country codes
(the ones used by Banks in their IBAN numbers)? The next day, the boss told
you to add another set, this time one with 2-letter language codes? What if
you suspected this would be your life for the next few weeks? How could you
automate this entire process?
We can program the instructions that will sort any combination of oranges
and apples and in any quantity. Or also find the overlapping two-letter codes
in any number of sets. In a proper book dealing with proper algorithms they
would bring the n-letter right about now and say things like: with n fruits, the
result A where A != B for any fruit would be A <= n and blah blah blah. God,
I hate those things. Forget that. We have a bunch of fruit and we have sets of
two-letter codes. In programming these are called collections (a bunch, a list,
sets..).. There are many types of collections each with their own individual
characteristics—as a matter of fact there is one called a Set. We need to cycle
through the elements in the fruit collection, one by one, determine if the fruit
is an apple or an orange and move one of these to a new collection, creating a
separate bunch of fruit as a result. In the second task, we need to cycle
through collections of 2-letter codes and check for duplicates. If we do find a
repeat in all collections, we move it to a new one representing the
"overlapping" part of the Venn diagram.
These operations are called Sorting. The first type of sorting (apples and
oranges), would suit first years at Hogwarts perfectly. The second type not so
much. There all sorts of sorting which can be sorted in all sorts of ways.
Alphabetical order?
Sure.
Numerical order?
Which one? Greater, lesser, primes, numbers divisible by 2...?
Uhm, all of them?
Sure.
You can combine sorts, or sort multiple times. You can sort your books by
genre, then by author and then by title. You'll need collections of stuff and a
way to cycle through them, performing one or more simple checks on each
individual item until you're done. Is this equal to this other thing? Is this thing
bigger than this other thing?
And I kid you not. This is it: programming. With a few extra bits here and
there. This is where the boolean operations Feynman explains really shine.
AND, OR and XOR. They model the way information flows through the
electrical circuits in your computer's CPU, and they are at the heart of
algorithms: the bit of code you write to separate apples from oranges.
There's also NOT NAND NOR and XNOR but they are versions or
combinations of the first three. And don't be frightened by their names,
they're just ways to express very simple logical relationships. (Besides, in the
field of Computer Science if you have half a chance to name something
badly, you take it!)
If I'm hungry AND I have food, I might as well eat.
If I'm done with work OR bored, I might as well turn on the TV.
 If I want to win XOR you want me to win, then we can't really play,
because we both want me to win.
But if I want to win XOR you want to win, then game on! Because now we
want different things. (XOR stands for Exclusive Or and it returns true if two
things are not the same, which may sound odd but it has its uses).
Quantum computers will add a new operation called HUH? Okay, it's not
called that, but it might as well be. If I'm hungry AND NOT hungry both at
the same time, I might as well eat and not eat. And I can't fault that logic.
You may combine these operations to create IS, IS NOT, IS NEITHER,
IS BOTH relationships.
I want to separate oranges AND this thing in my hand IS an orange. Into
the orange collection it goes.
This two-letter code from collection A IS NOT found in collection B. No
chance of it being a repeat found in all sets then.
Do you think this is a bit dumb? Well, remember what Feynman said about
the clerks. Everything we'll construct in this book will involve iterating
through collections of information and looking for certain relationships
described through these operators.
We have a collection of oranges and apples:
 Collection of apples and oranges

And a collection waiting to be filled with oranges.

We cycle through the fruit, what in programming is called a loop.
 Is this an Apple?

We end up, once we're done with the loop, with the new collections
looking like:
 Fruit separated into two collections

We loop one set of 2-letter-codes and for each 2-letter-code in this set we
look for a match with all the 2-letter-codes contained in n different sets.

Is this 2-letter code repeated in all sets?

You can see this second problem is a bit more awkward to solve, can't you?
It involves more loops, for one thing. So how would you do this? The art of
writing algorithms is primarily the search for optimum ways to solve
problems like this. How to match three gems in a match-three game? How to
find spelling mistakes in your text message? How to compose the pixels from
multiple layers into the final 2D image you see in your graphics editor.
And what if the boss keeps telling you to process more sets of two-letter
codes? Or more types of fruit? You would feel like your writing the same
thing way too many times, adding more loops and checks, and you'd think to
yourself there must be a better way.
And you'd be right.
Let's go find it.
 Part 2:
Conversion
 1
The Spell Checker, The Translator,
The Critic and the Wardrobe
We'll start small, with the sort of things you can do with a calculator,
converting one value into another. But before that, I need to go over a few
details related to programming languages in general. I've decided to use more
than one language in this book. The topic of programming is big enough
without having to add details from any specific language. Besides, there is
the risk the two things will combine into one inseparable whole:
programming and the language you program with. By showing multiple
languages and not going into too much depth with any of them, I hope to
keep the two concepts well separated: There is programming, and then there
are the languages you do it with. Each language will try different strategies
when addressing problems and performing tasks. The subject of
programming is comprised of those problems and tasks and not the strategies
necessarily. I want you to focus on the commonalities.
In general, programming languages are categorized using three main
concepts:
Is it multipurpose? Languages will be described as multipurpose or not,
ranging from languages that can do a lot of different things (mobile apps,
desktop apps, command-line tools, games, web-servers), to one thing only.
The latter type is usually called Domain-Specific Languages, and you may
have heard of some of them: HTML, CSS, SQL, XML. All the languages
you'll work with, in this book, are multipurpose. They can be used to build
command-line tools, games, web-servers and apps.
Is it multi-paradigm? Can the language solve problems using different
modes of thinking or expression? I'll go over paradigms much later in this
book. For now, think of this as different styles (although they may extend to
entirely different philosophies). Some languages are built with one specific
paradigm in mind but will support ideas from the others. All the languages
you'll see in this book fit that description.
Is it strongly-typed? Is the language strict? If so, how strict? Do you have
to write down what each blob of data is? Or can you leave it out? In order to
fully understand this idea I need to go into another important concept: types.
A type is the "family" each bit of information in your code belongs to. We
can have for instance: integers for whole numbers, strings for text, character
for an individual letter or symbol, a boolean for a true or false value, and
even more complex types which are a combination of other simpler types.
Strongly-typed languages, often referred to as statically-typed, will require
type information when something is declared (written out the first time). If
English was strongly typed we might write it like this:
Bob:subject eats:verb the:article banana:noun.
Because we don't do this, all sorts of errors and mystification are possible:
We saw her duck.
I shot an elephant in my pajamas.
The same thing may happen when you write programs that are not strict,
and you're not careful with your words.
You'll often hear the terms Statically Typed or Dynamically Typed to
describe this characteristic in a programming language. Static here means you
start with a fixed plan of what each thing will be before your program runs.
Dynamic means things will be determined while the program is running and
not before.
While working on your code, your program will be in one of three main
states. I call these: The Spell-checker, The Translator and The Critic. And
each one may behave differently based on how the language you're using
handles types.
When you're writing the program, you'll have the help of The Spell-checker
to find any errors in your code. This will primarily depend on the editor you'll
be using to code with, but also on how strict a language is. If you say a value
is a number and then later switch this value to some text, a strict language
will let you know you made a mistake, rather like a spell-checker does in
word processors. A non-strict language won't bother correcting you. A
dynamic language might only identify the problem once your programming is
running but not as you type it out.
When you build your code, a process sometimes known as compiling, you
send it to The Translator, who in the process of translating the code to
something the computer understands may block your program due to some
error not caught by the spell-checker. This again will depend on the language
itself, its syntax, and also its attitude towards types. Some languages are good
at this. Others, particularly the non-too-strict ones, again won't bother. If the
noun banana ate the subject Bob, a non-strict language will shrug this off as
bad luck on Bob's part. Some of these languages will even skip the translation
part altogether.
After the translator (or compiler) approved your application, comes
showtime. Any errors found here will be found by The Critic, and these are
known as run-time errors. It could be a crash or some sort of malfunction.
The critic might give you extensive information about what went wrong or no
information at all. It sucks to be caught by the critic. You learn to respect the
work of the spell-checker and translator and, to an extent, you learn to
appreciate the use of type declaration.
Languages like JavaScript, which is not strict at all, will leave most of the
error-checking responsibility to the critic. With JavaScript it's live and let
live. It tells you: Don't be afraid to make mistakes because it's a certainty
you'll make them. It doesn't mean you should be a complete idiot and make
idiotic mistakes, but perfection is a waste of time. As Leonard Cohen put it:
forget your perfect offering. Pay attention to the critic and respond to
whatever it brings to light. Keep things moving.
Languages like C#, on the other hand, a very strict language, will advise
you through its spell-checker about a number of ways you could fix or
improve your code. It will make damn sure your code is up to scratch before
even allowing it to go to the translator. These languages have standards! But
they can be a pain in the neck to work with. It takes some horrible lickings
from the critic to really appreciate what these languages can do for you.
Languages like Python, which is not too strict—in fact almost as relaxed as
JavaScript at first glance—will compromise. It has a fast and powerful
translator who will stop lots of errors and its critic is very informative. But it
leaves most of the responsibility to you. It understands that you're the one
who will mess things up and you're the one who should try not to. It won't
hold your hand.
 Let me show you what these differences look like in actual code. If I
wanted to declare the meaning of life in code, I could write it as, depending
on the language I use:
var meaningOfLife = 42;
meaningOfLife = 42
var meaningOfLife:Int = 42
int meaningOfLife = 42;

We call these variables. They act as placeholders for data and have that
name because the data is expected to change over the lifespan of your
program. Each language's specific syntax will determine if you use var or
not, if you use ; or not, and the order the elements appear—type|variable
name|value, or something else). These differences are not terribly important,
just icing on the cake. You'll have to learn them of course, because they're the
language syntax, but semantically speaking they're meaningless. Just fluff the
compiler requires to process your code correctly. Don't ever let syntax scare
you.
If the language is statically typed then you might have to write down these
little tags saying the variable holds an integer value, for instance.
The first line of code could be JavaScript, the second Python, the third
could be from Swift or Haxe and the fourth line could be Java, C#, C++, or
any number of other languages.
The keyword int (or Int with a capital i) denotes the type. Most statically
typed languages can infer a type from the variable's declaration. So in C#, for
example, I could have typed either:
var meaningOfLife = 42;
int meaningOfLife = 42;

In the second case, the language's spell-checker and translator are smart
enough to know meaningOfLife is an integer because of its value. As a
matter of fact, you're encouraged to use type inference whenever possible. So
you see, strict languages may not be as bad as they sound. Generally,
programmers tend to prefer a strongly typed language with good type
inference, because they tend to help to ferret out errors. Like a good spell-
checker. But like a spell-checker they can be annoying at times and if you
don't tend to make a lot of mistakes you might wish to do without it.
 This is not the only reason a language "chooses" to be strict and strongly
typed. It has to do also with memory management and providing the compiler
(translator) with more information about your code. And non-strict languages
will still require, every now and then, information about the type. For
instance, when dividing 5/2, do you want the result as the integer 2 or as the
float 2.5? Or as a "2.5" string? (Quotations are commonly used to denote a
string in code). Depending on what you're trying to do, you might need to
transform one type into another (a process known as casting). So you, the
programmer, will always need to be aware of type in your code, it's just a
matter of whether your code should be explicit about it.
I'll talk much more about types throughout this book, and things will
become clearer once you see all this applied in actual code. More
importantly, I don't want you to form the idea programming is too rigorous
and uncompromising. The syntax and semantics will force you to follow
certain conventions, it's true, but so do all other types of languages we learn
in life. But it's best to experience this by doing it; by actually coding. So let's
get a move on.
 2
All The Wrong Questions
How old are you and how much do you weight? Seriously. But don't tell
me yet. First let's open our trusty code editor for this lesson. You'll find it at
this URL:
https://www.onlinegdb.com/online_python_compiler
Prop up the book next to your monitor or load up your ebook reader on a
separate window, because you're about to code. We'll be using Python for this
section. Python is a dynamically typed, multipurpose, and multi-paradigm
language and one of the most popular languages in the world. You don't need
to declare types here, but do keep track of them.
In the real world, you'd write your scripts inside text files with a .py
extension. With this online console, you write your code in the big dark
section and press the green button at the top where it says Run.

Online Python Console

 Note: You might wish to use the console at https://repl.it instead.
With it, you'll be able to run all the code in this book, since it adds
support for all the languages we'll use. Plus, you can create an account
for free and save your code.

Go ahead and delete everything in the scripting area. And then type this:
weightOnMoon = 0.165

Python has no var at the beginning of a variable declaration and no

semicolons at the end of the line. Other languages might need this line
written as:
var weightOnMoon:float = 0.165;

float weightOnMoon = 0.165;

$weightOnMoon = 0.165;

This is all fluff. We'll see later why languages must use these odd little tags
to work properly.
As I said before, some languages will be very strict, requiring type
notation, others will seem like they couldn't care less. When you learn a
language, one of the first things you’ll need to find out is how it handles Type
Safety.
If a language is said to be dynamically typed, like Python, it means the
language uses 100% type inference as far as type safety goes. No annotation
is necessary. With a so-called weakly typed language, myName can go from
being "Roger" to being a bird, to being a plane, to being Superman. The
language will not care. But your logic may suffer for it. Types will also be
important when we start using collections. Some languages won’t let you mix
numbers and strings inside the same collection, for example. But more on this
later.
When you write a variable name—and perhaps its type—you're said to be
writing the variable declaration. When you assign a value to the variable
(using the = operator), you're said to be... well... assigning a value to it. You
can do both at the same time, as I did with weightOnMoon but a variable
must be declared before it can be used in your code.
weightOnMoon = 0.165

Notice that we don't have an integer here but what is known as a float point
number. A variable is said to contain a type, a value and a reference (or
identity). weightOnMoon has a type of float, a value of 0.165 and its
reference or identity is where in the memory the computer placed that
information. This is what the variable points to when it binds itself to a value,
the location in memory. This is important because sometimes you'll want to
check for equality of value, or of type, or of reference. If I declared a variable
someFloat and assigned it the value 0.165 the two variables (someFloat
and weightOnMoon) would have the same value, the same type but not the
same reference. They are two distinct variables. Sounds like a silly
distinction, but it isn't. Once we start using more complex types and changing
things through functions, you'll see this matters a great deal. And in some
languages, like C and C++, the distinction between reference and value is
something you're made aware of all the time. You can't code with those
languages without paying special attention to those two things.
You can print that value to the console by adding this line to the code:
print(weightOnMoon)

When you press the Run button, you'll see something like:
0.165

...Program finished with exit code

0
Press ENTER to exit console.

An exit code 0 means everything went smoothly. Any other value would be
interpreted as an error. The console is an environment you can run programs
in, particularly text-based programs. They're the quickest programs to
develop because you don't need to bother with a graphical user interface
(GUI), and besides, graphical interfaces are usually just a layer of illusion on
top of a text-based application. One of the best things you'll get out of
learning to program is familiarity with consoles. This may seem too old-
school to you right now, but just wait, it'll grow on you.
print() is a command that outputs text to the console. And the code was
able to pass it the value of our variable inside the parentheses. This is one of
the powerful things you can do with variables. They act as placeholders for a
value you can refer to in your code. If I wrote my name as a string in one line
of code like this:
"Roger"

I could no longer access it, not even in the very next line of code. I could
only repeat it.
"Roger"
print("Roger")

But this "Roger" string being printed to the console has nothing to do with
the "Roger" string from the line above. They are two separate entities. I have
no reference to the first "Roger", nor the second. The moment those lines are
executed the memory used by the two strings is set aside to be destroyed and
lost forever.
But if I attach the value to a variable (binding them):
name = "Roger"

Now I can refer to it by using the variable name.

print(name)

The compiler will actually create a table-like structure pairing variable

names to their location in memory and so to their values and keep track of
them this way.
You can hold any information inside a variable: strings, numbers, true or
false values... and even other variables.
name = “John”
height = 192.25
weight = 80.5
age = 34
hairColor = Color.brown
isBald = False

And since you may be able to create your own types, essentially you have
an infinite number of possible types.
Variable names are one of the few precious places you can add context to
your code because it's one of the few places where you can name things in
your program. For instance:
aPair = 2
years = 2
kilos = 2
freeSeats = 2
fingersImHoldingUp = 2

The value is the same in each variable but the context is not and the context
is enriched by the name of the variable, so choose them well. Variable names
cannot contain any spaces and cannot start with numbers—and a few other
reserved characters and keywords depending on the language you use (if a
language has a type called int you should not name variables int, for
instance). There are countless conventions surrounding variable naming. For
instance, conventions on how to name things when requiring multiple words
—since one can't use spaces when naming a variable. Coders will choose
patterns like:
free_seats = 2
freeSeats = 2
FreeSeats = 2
_free_seats_int = 2

Each style might be chosen to give more context, as ways to encode

meaning to your names. This will be up to you, or your team, or your boss.
Now, back to our program, type this below the previous lines:
myWeight = 90 * weightOnMoon

print (myWeight)

Instead of 90, use your own weight. I'm using kilograms, but it does not
matter what you're using. Run that and it will print out your weight on the
moon. You can write all basic mathematical operations using simple syntax
like:
2 + 2
2 - 2
2 * 2
4 / 2
5 // 2
 The last one, 5//2, depending on what version of Python you're running,
will return the integer value of the division: 2. Whereas 5/2 would return the
float 2.5. But this depends, as I said, on the Python version. You may be
required, to be on the safe said, to use 5.0/2 or 5/2.0 or 5.0/2.0 to
force the compiler to give you a float.
You can go ahead and have fun with these other ratios:
weightOnMars = 0.38
weightOnPluto = 0.067
weightOnJupiter = 2.528
weightOnSun = 27.072
weightOnDwarfStar = 1300000

Then comes the other units of mass:

kgInStones = 0.1575
kgInPounds = 2.204
poundInKg = 0.453
poundInStones = 0.0714

Whenever I hear stone as a unit I always wonder how big a stone? Do you
fraction it into pebbles and dust? And what is it primarily made of? Osmium,
the heaviest substance on earth, or Graphene one of the lightest? Superman's
tiny little key to his Fortress of Solitude was made from a Dwarf Star and
weighted millions of tons, so what's in this particular "stone" you're talking
about? But then you realize, "Oh, right, the British made it up."
And so can we!
22 stone = A small man carrying a goat wearing a tutu, I mean the goat is
wearing a tutu not the man. Or ASMCAGWATIMTGIWATNTM for short.
We're about to do some math connected to ratios. As a matter of fact, I
believe 99% of the math used in this book will be related to ratios. Something
like this: If 1 kg is equal to 0.1575 stone, then 22 stones is equal to how many
kilograms? But Word-Mode sucks so we use a rule of three. Rule of what?
The one where we cross. You pair the things you know:
1 kg = 0.1575 stones
And pair the equivalent things, which now include the one thing you don't
know (you always know three out of four, hence the name of the rule):
 1 kg = 0.1575 stones
? kg = 22 stones
You're trying to find out how many kilos there are in 22 stones. And for
that, you cross:

Rule of Three operation

Getting as the result:

? * 0.1575 = 22 * 1
And then rearrange the values so that the unknown one goes to one side of
the equation by itself:
? = 22 / 0.1575
This is one way we can find out about ratios between things. From this we
learn that 22 stones are about 139.7 kg, and since 22 stones equal 1
ASMCAGWATIMTGIWATNTM, one ASMCAGWATIMTGIWATNTM
equals 139.7 kg. Therefore:
oneKgInASMCAGWATIMTGIWATNTM = 1/139.7

Why? Because it's the inverse. Or if you, like me, like to keep doing the
crossing thing:
1 ASMCAGWATIMTGIWATNTM = 139.7 kg

? ASMCAGWATIMTGIWATNTM = 1 kg

Now cross it, leave the ? standing on its own and you get:
? = 1/139.7
How much do you weight in ASMCAGWATIMTGIWATNTM? Go on,
don't be shy.
oneKgInASMCAGWATIMTGIWATNTM = 1/139.7

# replace 1 with your weight in kilograms

myKilos = 1

myWeightInASMCAGWATIMTGIWATNTM = myKilos *
oneKgInASMCAGWATIMTGIWATNTM

print(myWeightInASMCAGWATIMTGIWATNTM)

# by the way, this line is a comment in Python

# you can use it to... well, comment your code
# it's not compiled along with the
# rest of the program

Wikipedia also lists Candy and Batman as units of weight with the
following ratios:
oneKgInCandy = 1/227
oneKgInBatman = 1/7.484

What is your weight in Batman? Or Candy?

And how about time? Let's get really old-fashioned and calculate our years
in fortnights, which is a fancy word for 14 days.
oneYearInFortnights = 365 * 1/14

How come 1/14? Because it's the inverse, or, by crossing:

1 fortnight = 14 days
? fortnight = 1 day

Telling us that: ? fortnight = 1 / 14

This gives one day in a fortnight, and we multiply that by 365 to get one
year in fortnights. Sure, we could simply divide a year by 14 in this case, but
that's not nearly as fun as doing the crossing thing.
Let's also use Score, which represents a period of 20 years:
oneYearInScores = 1/20

Let's break a value down into scores and fortnights. So with my age, 42
(which is also the meaning of life, huh?!):
scores = 42 // 20

This will give us an Integer in Python (version 3 and above). Which is what
we want. Remember when I said sometimes you want 5/2 to give you 2 and
not 2.5. If I wanted the float number result I could get it by writing it like this
in Python:
scores = 42 / 20

Or:
scores = 42.0 / 20.0

Well, technically the numbers don't have to be both a float, just one value
would do. By appending a .0 like that, you turn a number into a float, and
Python will see it that way and act accordingly.
But in our problem, I only want the whole score years because I'll calculate
the remainder as fortnights. And you get the remainder with the Modulo
operator, which in code is almost always represented with the percentage sign
(%). So, to review:
5/2 = 2.5 (if you want the float)
5//2 = 2 (if you want the integer value, leaving, in this case, some leftover)
5 % 2 = 1 (this gives you the remainder—or leftover— because 5//2 results
in 2 plus a leftover of 1)
If you can only share whole 5 oranges between two people, they will each
get 2 oranges, and you'll have one orange left, that's the modulo. So if you
take someone's age, and get the whole number of scores in that age:
scores = 42 // 20
# this will give us an integer,
# the whole number of scores in 42

You can use the remainder years from the previous operation and get that
number in fortnights:
oneYearInFortnights = 365 * 1/14

fortnights = (42 % 20) * oneYearInFortnights

It so happens that:

42 // 20 = 2

42 % 20 = 2

There are 26 fortnights in a year, and so two years equals 52 fortnights. I

am two score years and 52 fortnights old. I can print the result like this:
print ( "I am " + str(scores) + " scores and "
+ str(fortnights) + "fortnights old" )

This is known as string concatenation, meaning, it's the operation that

combines strings together, and in Python we can use the + operator for that.
Notice that I must make sure the values in the score and fortnight variables
are turned into strings by using the function str(). We'll see more about
functions soon but notice how important it is to keep track of types in your
code. Even though Python does not require that you annotate type, it does
require that you pay attention to type and run the necessary conversions.
Python is a dynamically typed language, it will infer all types but insist that
they're used correctly. We can't mix types when forming a string in Python.
As an exercise: Abraham Lincoln could have said "Four score and ..." how
many fortnights?
oneYearInFortnights = 365 * 1/14

gettysburgFortnights = 7 * oneYearInFortnights

What is the current calendar year in score and fortnights?

2020 // 20

2020 % 20

Something tells me 2020 % 20 will result in no remainder, which is

perfectly valid.
And here are more strange units of time according to Wikipedia. A Jiffy is
1/50 seconds. A Moment is 90 seconds. Can you get that value in years and
then calculate your age in Jiffies and Moments?
secondsInAMinute = 60
secondsInAnHour = secondsInAMinute * 60
secondsInADay = secondsInAnHour * 24
secondsInAYear = secondsInADay * 365

60 seconds to every minute, 60 * 60 seconds to every hour, 24 * 60 * 60

seconds to every day, and 356 * 24 * 60 * 60 to every year.
momentsInAMinute = secondsInAMinute / 90
momentsInAnHour = secondsInAnHour / 90
momentsInADay = secondsInADay / 90
momentsInAYear = secondsInAYear / 90

myAgeInMoments = ?

oneSecondInJiffies = 1/0.02

jiffiesInAMinute = secondsInAMinute * oneSecondInJiffies

jiffiesInAnHour = secondsInAnHour * oneSecondInJiffies
jiffiesInADay = secondsInADay * oneSecondInJiffies
jiffiesInAYear = secondsInAYear * oneSecondInJiffies

myAgeInJiffies = ?

How many weeks old are you?

weeksInAYear = 365.0 / 7.0

# your age * weeksInAYear = ?

Divide your age by 31.7 and you get your age in Gigaseconds, how much
would that be? Write it in code and run it in the console.
Calculate the number of seconds in a year, multiply it by 100 to get the
number of seconds in a century, divide that by a billion to get a nanocentury
(one billionth of a century equals a nonocentury just as one nanosecond is
one billionth of a second) and with this you arrive at Duff's Rule:
PI seconds is roughly 1 nanocentury. ("roughly" in the same way that a
pound is roughly half a kilogram).
PI is roughly 3.14 and that is roughly the number of seconds in a
nanocentury. This can be useful when you need to roughly convert time
measured in decimals into the Babylonian sexagesimal system we use for
time because the square root of 10 is roughly PI, and so 10 to the power of
1/2 is about one nanocentury...
... Sorry. Got carried away. Forget I said any of that.
And sure, you would be right in questioning the point of all this. You could
do all this on a calculator, or better yet, you could Google it. And that's true.
(I mainly wanted to talk about variables and some more about types). This
may not look like programming yet, but we're not too far from that. If you
needed to perform a number of these calculations all at once, programming
would be of great help. But sure, you could do the same with a spreadsheet,
feeding a formula to a column or row, or many columns and rows. I never
said you couldn't find programming outside code editors. You've probably
programmed many times before without even noticing it. If you ever used a
graphics program that uses a layers system, like Photoshop, you basically
used a calculator, batching a number of simple mathematical operations in the
order dictated by the layers: this pixel is added to this other pixel, and the
result is multiplied by this other pixel and on and on. They don't call it
programming, or math. They call it blend-modes. Same thing, really.
But we haven't seen a way to batch operations like that yet. We'll tackle
that next.
Baby steps. Relax. Here's an old Russian political joke using string
concatenation and subtraction (it uses some awkward formatting so I could fit
the lines properly):
rows = 5

print ("There are " + str(rows) +

" rows of party members in attendance " +
"at the Congress Hall during Stalin's speech.")

print ("Suddenly, someone sneezes.")

print ("Stalin asks, 'Who sneezed?'")
print ("No one answers.")
print ("Stalin says: 'Row number " + str(rows) +
", on your feet! Shoot them!'")

rows -= 1

print ("Suddenly, someone sneezes.")

print ("Stalin asks, 'Who sneezed?'")
print ("No one answers.")
print ("Stalin says: 'Row number " + str(rows) +
", on your feet! Shoot them!'")

rows -= 1

print ("Suddenly, someone sneezes.")

print ("Stalin asks, 'Who sneezed?'")
print ("No one answers.")
print ("Stalin says: 'Row number " + str(rows) +
", on your feet! Shoot them!'")

rows -= 1

print ("Suddenly, someone sneezes.");

print ("Stalin asks, 'Who sneezed?'")
print ("No one answers.")
print ("Stalin says: 'Row number " + str(rows) +
", on your feet! Shoot them!'")

rows -= 1

print ("Suddenly, someone sneezes.")

print ("Stalin asks, 'Who sneezed?'")
print ("No one answers.")
print ("Stalin says: 'Row number " + str(rows) +
", on your feet! Shoot them!'")
rows -= 1

print ("At last a sobbing cry resounds"

+ " in the Congress Hall:")
print ("'It was me! Me!'")
print ("Stalin says:")
print ("'Bless you, Comrade!' and resumes his speech")

And in case you're wondering, Doesn't this joke break the first law of
programming? There must be a better way to code all that than to type the
same things over and over again. Yep. There is. Read on!
 3
HOWALIVE
In the book The Martian, by Andy Weir, the main character Mark Watney
finds a way to communicate with NASA using Sojourner, the robotic-rover
part of Pathfinder. But he has a problem from the beginning. He can only use
Sojourner's camera to send his messages, but also to receive messages from
NASA. If he uses Sojourner's camera to point to the letters and numbers
positioned in a circle around the robot, he would need to divide a circle into
26 characters plus ten numbers and wait for the camera to point to each of
these symbols in turn, thus forming a message.
 Dividing a circle into 36 symbols

360 degrees divided by 36 = 10 degrees. And yes, he will need the

numbers, as it'll become clear very soon in the story. Ten degrees is not a
whole lot. The camera could look straight at the letter A, for instance, and
Watney would not know if this meant A, B, or Z, or 9 or 0 depending on
where he placed the numbers on the circle. But then, Watney remembers this
table:
 ASCII Table (partial view)

Known as the ASCII table (American Standard Code for Information

Interchange), pronounced Ass-kee. It lists a series of conversions of the sort:
A (or Uppercase A) has a decimal value of 65.
The table lists numerical values for 256 symbols (characters, numbers, plus
other Keyboard symbols) so that computers can translate bits (or binary
values) into characters, and we heard about this on Feynman's lecture as well.
This decimal value is then converted to other base-systems, and this
information varies from table to table. A table might list that 65 has a
hexadecimal value of 41 and a binary value of 01000001, for instance. The
rows are presented like this, using my 'A' example:
65 41 01000001 A
Why is this a godsend to a guy stranded on Mars? Watney realizes he can
use HEX values to represent the letters and numbers and so divide the circle
into bigger chunks. In order to represent any hex value, he'll only need 16
symbols, giving him 22.5 degrees per symbol:
 Dividing a circle into 16 symbols

You can use a HEX number to represent a decimal value; the same decimal
value you know from your helpful table represents a character. So we're
talking about a conversion of the sort we did in the previous chapter. So how
do we know a 65 decimal value means 41 in HEX? A HEX is a hexadecimal
number, or a base-16 number as opposed to what you may call regular
numbers which are base-10, or decimal...
Oh boy. Here we go.
In life, there are two speeches one is expected to hear growing up. The first
is about how babies are made. The second is the column speech about
numerical bases. So forgive me, you probably know this already, but here it
goes: babies are the result of unprotected sex during fertile days, and we use
columns to encode our numbers into symbols.
 Columns system for numerical symbols

Using this column system with the symbols we picked for our numbers, the
last number is multiplied by one, then the next number is multiplied by the
base (2, 8, 10, 16, 36, 60...whatever). The subsequent numbers are multiplied
by the base raised to the power of 2, 3, 4, 5, 6... and on and on...
Here's an example. 1135 is a symbol, just that. It represents a number using
those squiggly lines for all the symbols. Working backward—because it's
much easier to do it that way,—that base-10 symbol means: 5 * 1, plus 3 * 10
(the base), plus 1 * 100 (the base raised to 2: 10 * 10), plus 1 * 1000 (the base
raised to 3: 10 * 10 * 10).

Base-10

You can write any number using any base system. We happened to favor
the decimal one, or base-10. The ancient Babylonians used a base-60.
Computers use base-2, using the values 0 and 1 to represent all possible
numbers. For example, the number eight in base-2 is: 1000

Base-2

Working backwards: 0 * 1 + 0 * 2 + 0 * 4 + 1 * 8
The HEX system uses base-16 as I said, and it needs a one-character
symbol to represent each number from 0 to 16. From zero to nine, that's easy;
our good old squiggly symbols take care of the first nine values plus zero: 0 1
2 3 4 5 6 7 8 9. But we can't use 10 to represent 10 in hexadecimal because
we need a single-character symbol, so we use letters from then until we hit
15, so A B C D E F stands for 10 11 12 13 14 and 15. The number 16 is
represented as 10 because of the columns in base-16:

Base-16

0 multiplies 1, and the second column (1) multiples 16, resulting in the
number 16, our base. The base is always the first number to use more than
one column, and all values up to the base, starting from zero, are represented
as single characters (numbers or letters). The same thing happens with 10 in
base-10; we have single symbols from 0 to 9, but the base value 10 is
represented in two columns as 0 * 1 + 1 * 10. As a matter of fact, all base
numbers are represented as 10. 10 in base-10 = 10, 10 in base-16 = 16, 10 in
base-2 = 2, 10 in base-8 = 8...
The internet uses all sorts of bases, for instance a base-36 is used to
generate those tiny URL people use to share pictures of their food. But if you
ever worked with HTML, CSS, or any graphics program, you've probably
seen base-16 used to represent colors, because colors can get up to huge
numbers. A shade of bright orange for instance is 16748800 in decimals.
(And this representation of color as decimal numbers is the result of another
convention used by all computers). So it's better to represent that number
using base-16 instead. Colors can be further simplified in Hex by breaking
the color into three separate components, one for red, one for green and one
for blue, generating those funky hex numbers like # FF FF FF.
Back to Watney.
NASA will point Sojourner's camera to one of these characters
0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F arranged on a circle around the robot's
camera. The symbols can be used to represent letters and numbers based on
the ASCII table values, with each two-symbol code representing one encoded
value. We don't even need the whole table. We only care for letters and
numbers. If you look at the table online most of the symbols are pretty much
useless to a guy stranded on Mars. And we know NASA didn't bother with
punctuation either, so we can safely assume the decimal values they'll need to
represent in HEX will be the ones ranging from 48 to 57 for the numbers, and
65 to 90 for the letters. And these letters would be all caps because NASA
would be screaming at Watney, and understandably too.
Watney does all the conversion by hand, at least in the movie, even though
he does have access to a laptop. We're going to write a script decoding
NASA's messages. This will work out the same way we converted a year into
scores and fortnights. We'll get a whole number from a division and then get
the remainder with the modulo operation.

Sure, Watney could have used the decimal values instead, divide
 the circle by 10 and not bother with the extra bit of conversion, but
hex adds drama! Besides, it's harder to separate the encoded messages
using the decimal system. Try it. Go to Mars and do it. You'll see what
I mean.

It helps to think about what we need the program to achieve, generating a

quick list of the things we expect it to do. We'll build the NASA code that
encodes a message as hexadecimal symbols and a Watney code that decodes
the same message back to letters. The NASA code needs to:

Convert a collection of letters into hexadecimal symbols.

Add these resulting symbols to another collection and dispatch them to
Mars.

Let's use the character A as an example. NASA wants to send Watney the hex
value for A. Using the ASCII table NASA finds out the decimal value for A
is 65, and 65 in base-16 is 41. It instructs Sojourner to point to 4 and then 1.

The Watney code will do things in reverse:

Loop through a collection of hexadecimal symbols.

Convert each to a letter.
Print out each letter to the console.

Following with my example, Watney will write down 41, convert this to
base-10 and get 65 and convert that to A. Or he'll use an ASCII table that
already lists hex values for the individual characters.
Following one of our rules of programming: one solution will fit all
possible instances of the problem. So the program will repeat the same steps
to each individual character in any given message until the entire message is
processed. So it looks like we need collections and loops. It's apples and
oranges all over again.

Collections
We'll start with the most common type of collection, the array. You
probably heard about it already. It's used in my favorite computer joke:
["hip", "hip"]

(Oh man, it gets me every time).

An array is almost universally represented as a list of elements (usually of
the same type unless we're talking about a weakly-typed language) inside
square brackets.
Arrays are a neat way to group lots of data under one variable. You can
assign an array to a variable as we did with everything else thus far. With a
common garden variable, you get their value by referring to the variable
itself:
myName = "Roger"
print(myName)

With an Array, you get the value by referring to the array plus the index of
the value you want:
names = ["Roger", "Billy", "Bob"]
print (name[0])

This gives us "Roger". Why the 0? In most languages arrays are said to be
zero-indexed, or zero-based. It means it starts at 0. Index 1 would give us
"Billy" and index 2 would give us "Bob". The array will have a count of 3,
but its last index will be that count minus 1. Because why would anybody
make anything easier for anyone, am I right? If this is something you find too
obnoxious then Lua is the language you want; Lua arrays are indexed at 1,
like normal people arrays. I like Lua. And by the way, Python doesn't have an
Array per se, it has a List. In Python an Array is a List. In some languages
you will have both a collection type called Array and a collection type called
List. But in Python Arrays are Lists. And I will use the terms array and
collection interchangeably throughout the book even though each language
might use the term to represent a specific type of collection.
As a matter of fact, let's waste more time going over other types of
collections. I'll focus for now on what Python can offer us.
Lists keep their items in the order they were first added, and this order is
kept by the list. Think of a To-Do List, you do this one thing, and then this
other thing, in order. You have the first item, the second item... You can add
items to the beginning of a list or to the end, or at any index, and the list will
change to reflect the new order. Another point to keep in mind in relation to
Lists is that you can add the same or similar items multiple times.
microphoneTest = ["test","test","1","2","3","test"]

There are collections that do not bother keeping the order, and these are
more like shopping lists. You can't guarantee the first item added will be the
first item on the list. And these collections usually do not allow for repeats.
Python has a Set collection which does all that. It's represented by curly
braces:
favoriteThings = {
"Raindrops on roses",
"Whiskers on kittens",
"Bright copper kettles",
"Warm woolen mittens",
"Brown paper packages tied up with strings"
}

You can't index a Set, remember it has no order. So we can't type:

favoriteThings[0]

And hope to retrieve the first item. We can only look for things inside a set
through loops, which we'll see in a moment. But even though I typed the
elements in that order you saw, it does not mean they were stored in that
order (that Set may ruin all the rhymes, awww).
And then we have collections that group items in pairs. In Python they're
called Dictionaries and are represented by curly braces with the pairs
separated by colons (:).
doReMi = {
"Doe" : "a deer, a female deer",
"Ray" : "a drop of golden sun",
"Me" : "a name I call myself",
"Far" : "a long, long way to run",
"Sew" : "a needle pulling thread",
"La" : "a note to follow Sew (huh?)",
"Tea" : "a drink with jam and bread",
}

The first value in the pair is called the Key and the second the Value, and
together they're known as Key-Value pairs. All keys must be of the same type
and all values must be of the same type. But values and keys can be of
different types (say integer keys and string values, for instance). And values
can be repeated in a dictionary, but not the keys. The keys must be unique.
You can find an item inside a dictionary using its key like this:
me = doReMi["Me"]

And you can also loop keys and values independently.

Finally, we have Tuples. These are blobs of different types of data (or of
the same type, either way it's cool with tuples). Tuples are immutable. Once
declared they cannot change, you cannot add to a tuple or remove from a
tuple:
myTuple = (1, "2", "3", True)

You can access the values as you would with a list:

myTuple[0]

Tuples are ordered but immutable as I said. Mutability is another important

topic in programming, but more so with certain languages. And later in this
book, I'll talk about mutability until your eyes burn.
When should you use a particular type of collection? It will be dictated by
purpose and knowledge. Sets can't hold duplicates and this might be
important when solving a problem. Dictionaries can pair things under unique
keys and this might be important when solving a particular problem. But you
might not know these collections exist, and that's fine too. With
programming, not knowing one particular solution does not mean you won't
be able to solve a problem, it only means you'll type more.
And finally, Strings are a special kind of collection and behave like Lists
in Python, although strings are immutable (all primitive types in Python are
immutable, these are: strings, integers, floats and booleans). But these are
essentially the same in many respects:
word = "Word"
word = ["W","o","r","d"]

Strings will have similar properties and methods as the ones available for
Lists. We're not going to cover functions in this chapter, but it's hard to talk
about collections and not talk about functions. A programming language is
more than just syntax and symbols. It's also a collection of helper methods.
Every type of "thing" in a language will have a list of helper methods as well
as properties. Integers will have them, strings will have them, and also
collections. These methods will help convert one type into another, or help
format them in a particular way, or help derive information from them...
When you learn a language, your first step is to understand the basics of its
syntax. How does one declare a collection and how does one loop through it,
for instance. The second step is learning its helper methods. It can be
daunting at first, not knowing them or not being able to remember them after
you've seen them a few times. I go through the same thing every time I tackle
a new language. In time, you learn to relax and enjoy the process. Most of
these methods you can recreate yourself and I'll show you an example of this
shortly. But this is like reinventing the wheel. Python is packed full of helper
methods and they're absolutely brilliant. But not knowing them is okay too, it
just means, as I've said, that you'll type more. Here are some methods and
properties involving lists:
names = ["Roger", "Billy", "Bob"]

# this will give us the number

# of items in the names List (3)
len(names)

# this will return the index of the item Billy (1)

names.index("Billy")

# this will crash with a ValueError

# ValueError: 'Wally' is not in list
names.index("Wally")

# this will have a value of True

# since Billy is in the names List.
print("Billy" in names)

# this will have a value of False.

# Wally is not in the names List.
# Where is Wally?
print("Wally" in names)

# this will be true

print("Wally" not in names)

# this will join all elements in the

# List, separating them with ", "
", ".join(names)

# like so: "Roger, Billy, Bob"

# this will add an element to

# the end of the List.
names.append("Wally")

# this will remove an element from

# the List. He's gone again.
names.remove("Wally")

# this will sort all elements in the

# List, resulting in ["Billy", "Bob", "Roger"]
names.sort()

# so by default sort will work

# alphabetically for strings

# this will reverse all elements in the List

priori_incantatem = ["Cedric",
"Muggle caretaker",
"Bertha Jorkins",
"Lily Potter",
"James Potter"]

priori_incantatem.reverse()

# resulting in ...
["James Potter",
"Lily Potter",
"Bertha Jorkins",
"Muggle caretaker",
"Cedric"]

# see that JK Rowling!

# Seriously, Google "The Wand Order Problem".

And no, you don't need to remember all this right now. The best way to
learn them is by using them. But do realize that integers will have their built-
in helper methods and properties, and so will strings and collections... With a
stress on the word "helper".

Back to Watney.
The first thing we need to do is convert a base-10 number to base-16. Let's
pick the number 42 and see how we could do it. It shouldn't be too different
than what we did when we transformed 42 into scores and fortnights. First we
get the integer value of 42 divided by 16 this time (our base).
first = 42 // 16

Then we get the remainder for the second value:

second = 42 % 16

But we still need to show the values using the base-16 symbols. For that,
we can create a list with the 16 symbols and do the translation using the
symbols index. Think of it this way:

base-16 = [0,1,2,3,4,5,6,7,8,9, A, B, C, D, E, F]

The symbol F is at index 15 in the base-16 list, and the decimal value 15 is
F in hexadecimal. That's one way we can run our conversions. F = 15.
We know we'll only ever need two symbols so we don't need to bother with
anything other than two columns for our hex values. We create a collection
for our Hex symbols:
hex = ["0","1","2","3","4","5","6",
"7","8","9","A","B","C","D","E","F"]

The value of each symbol's index in the list will match the decimal value
for the symbol, from 0 to 15. So if we have a value of 5, all we'd need to do
to convert the value to hex is to pick the symbol at hex[5]. Which happens to
be 5. Therefore, if:
first = 42 // 16 = 2
 The symbol at index 2 is 2.
second = 42 % 16 = 10

The symbol at index 10 is A

So 42 in base-16 is: 2A
But NASA will need first to convert a letter to the ASCII decimal value
and then convert that integer to base-16.
Python has a helper built-in function for this called ord(). It returns the
ASCII decimal value of a character. But let's say we don't know this, as I
imagine you didn't until I mentioned it just now. We can repeat the same idea
we used for the list of Hex symbols and recreate the ASCII table in our code
as a list of 90 items and find the ASCII decimal value by looking for indexes
in the list.
Something like this:
ascii = ["", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", " ", "", "",
"", "", "", "", "", "", "", "", "",
"", "", "", "", "0", "1", "2", "3",
"4", "5", "6", "7", "8", "9", "", "",
"", "", "", "", "", "A", "B", "C",
"D", "E", "F", "G", "H", "I", "J",
"K", "L", "M", "N", "O", "P", "Q",
"R", "S", "T", "U", "V", "X", "Y",
"W", "Z"]

I replaced the characters we won't need with an empty string "". But I
decided to add a space character (at index 32), even though NASA didn't
bother with one. And since we only want capital letters and numbers (plus
that space), we can stop the list at index 90 and not use the whole 256 items
in the real table. In order to convert "H" (that is uppercase h) to its ASCII
decimal value we do this:
ascii.index("H")

So you see, if you don't know about ord() you'll have to type more. By
using this ascii list, in Python these two functions would return the same
value of 72:
print (ord("H"))
print (ascii.index("H"))

Because "H" is at index 72 in the ascii list I created, and H has a value
of 72 in the ASCII table and so that's what gets returned by ord().
You can choose to use the ord() or not. This is an example of solving a
problem on your own that might already be solved by some built-in helper
function. There are no losers in this game, though. It's often more enjoyable
to solve problems with your own code. A boss may tell you, however, that
you're wasting company time.
Cool. We can convert a letter to a hexadecimal value by first getting the
base-10 ASCII integer value and converting that to base-16. We need to do
this for all the letters in a message. Let's say the first message from NASA
says: "HELLO MARS".
Strings behave as collections, as I mentioned. So I can "address" each letter
in the message using their index:
message = "HELLO MARS"
message[0]
message[1]
message[2]
message[3]
message[4]
...

I could retrieve each letter like this, with their index, and convert each to
Hex. But not all messages will have the same length. I could say "LIVE
LONG AND PROSPER" in my next message. This would mean changing
my code each time I send a message with a different length than the previous
one, adding or removing lines of conversion as the need may be. According
to the first law of programming, there must be a better way. And there is. It's
called a "for each" loop (although Python does not call it that). Which brings
us to...

Loops
 We can loop a string as we would loop any collection. And this is what the
loop we're looking for looks like in Python:
for character in "HELLO MARS":
# do something with variable character

The word character is a variable name. It could be anything you wish:

for c in "HELLO MARS":

for x in "HELLO MARS":

But do try to make these names meaningful if you can, as I've mentioned
before. I know it's not easy. We belong to a species that name children
"Billy" or "Mary" instead of naming them "Ass Kicker Billionaire Big-Boss-
A-Tron". (Seriously, just Google Nominative Determinism and you'll see
what I mean).
The "for each" loop above states: for each element in the "HELLO MARS"
collection, assign the element to the variable character and perform the
following operations on it. When you're done perform these operations on
one character, loop back to the first line and re-run the operations until we're
done with the entire collection.
If I wanted to print each one of the letters in "HELLO MARS", I'd do it
like this:
for character in "HELLO MARS":
print(character)

The colon at the end of the first line creates a code block. It is necessary in
Python, indeed vital, that I use the indentation before the second line (Python
programmers tend to favor 4 spaces for each level of indentation). Think of
this as an outline:

Wake up at 7:30
Have Breakfast
Eggs
Toast
Coffee
Go back to bed
 The indentation is used to create sub-lists, to indicate that these belong to
their parent "topic". In the same way, by using a code block indentation, I'm
separating the logic that will work inside the loop. The logic that will be fed
the character variable. Python uses spaces and colons (:) to organize the
code into blocks, whereas other languages might use curly braces ({}) and
semicolons (;). Take a look at a similar loop done in C# :
foreach (var character in "HELLO MARS") {
Console.WriteLine(character);
}

I don't need the indentation here since the curly-braces create the block on
their own but programmers will add them so the code becomes more readable
and pleasing to the eye. In Python, if your indentation is out of whack, you'll
get an Indentation Error and your code won't run. Do try to be neat.
Loops are the first special type of code block I'm presenting in this book.
Each type has its peculiarities. With a loop, I can repeat the logic inside the
block, looping back to the first line after each iteration to check if I may
continue to execute the blocked code or not. In the case of our conversion
script, once I run out of characters in the string I'm looping through, I finish
with the loop and continue with the program. So a loop causes execution to
get stuck inside a block until it's okay to proceed.
for character in "HELLO MARS":
# we'll be stuck here a while
print(character)
# once the loop is done we proceed with the next line
print("phew, we're back!"

We can now add logic to process each character in our message:

for character in "HELLO MARS":
ascii_value = ord(character)

Remember we could have used our ASCII list and coded this instead:
for character in "HELLO MARS":
ascii_value = ascii.index(character)

With this inside the loop's code block, we're running the ASCII integer
conversion on every character in the string. What next? Let's get the first and
second base-16 symbols:
hex = ["0","1","2","3","4","5","6","7","8","9",
"A","B","C","D","E","F"]

for character in "HELLO MARS":

ascii_value = ord(character)
first_symbol = hex[ascii_value // 16]
second_symbol = hex[ascii_value % 16]

We're just repeating the logic we wrote earlier when we converted 42 to

base-16, but this time inside the loop's code block. I calculated the list index
for each symbol inside the brackets but I could have done it in another line:
index = ascii_value // 16
first_symbol = hex[index]
index = ascii_value % 16
second_symbol = hex[index]

At this point we can print the hexadecimal code to the console:

hex = ["0","1","2","3","4","5","6","7","8","9",
"A","B","C","D","E","F"]

for character in "HELLO MARS":

ascii_value = ord(character)
first_symbol = hex[ascii_value // 16]
second_symbol = hex[ascii_value % 16]
hex_string = first_symbol + second_symbol
print(hex_string)

Remember that we can concatenate two strings by using the + operator, so

by "adding" the first and second symbols we build our Hexadecimal symbol
string. If you run the program you'll see the following result in the console:

48
45
4C
4C
4F
20
4D
41
52
53

For every character in "HELLO MARS" the loop took care of running the
logic described inside the loop's code block. Notice again how every line
inside the same block must have the same indentation.
hex = ["0","1","2","3","4","5","6","7","8","9",
"A","B","C","D","E","F"]

for character in "HELLO MARS":

ascii_value = ord(character)
first_symbol = hex[ascii_value//16]
second_symbol = hex[ascii_value % 16]
hex_string = first_symbol + second_symbol
print(hex_string)

The moment I write a line of code that matches the indentation of the first
loop line (for character in "HELLO MARS":) I'm essentially
telling the compiler this line does not belong to the loop code block.
And now, all we need to do to change the message we send Watney is type
a different one at the top of the loop. But we're not done yet. We need to store
the encoded message inside another list we'll dispatch to the Sojourner. And
besides, we need to send a more meaningful message and not waste time with
frivolities. Using the actual message NASA sent Watney in the story, we
have:
# NASA conversion code:

hex = ["0","1","2","3","4","5","6","7","8","9",
"A","B","C","D","E","F"]

encoded_message = []

for character in "HOW ALIVE":

ascii_value = ord(character)
first_symbol = hex[ascii_value//16]
second_symbol = hex[ascii_value % 16]
hex_string = first_symbol + second_symbol
 encoded_message.append(hex_string)

print(encoded_message)

The main changes besides the message are: we declared an empty list at the
top of the loop and we now .append() the hex string value to it, collecting
all converted symbols into one collection. (In Python you can also use the +
operator to append to a list).
The message "HOW ALIVE" always sounded a bit judgmental to me, but
one should not read too much into interplanetary text messages, I suppose.
We will now move on to Watney's code. It will loop through the encoded
message list, get each hex string and convert it to an integer and then convert
that back to a letter.
Converting Hex to decimal is a bit anticlimactic by comparison. But then
again, I'm not the one running out of air and potatoes 172 million kilometers
away.
# Watney conversion code:

for hex_code in encoded_message:

ascii_value = int(hex_code, 16)
character = chr(ascii_value)
print(character)

That's it. We loop through the array we received from Earth and we use
two new built-in helper functions from Python. One creates an integer from a
string and takes a base as a second parameter. With it, we can transform the
string "4F" into an integer by telling the function int(): "here's my string,
and it happens to be in base-16, also known as hexadecimal". And with the
second helper function, char(), we convert an ASCII value into its char
symbol (the one listed in the ASCII table).
We could have used our massive array of ASCII symbols, but who wants
to type all that?
Oh, all right!
ascii = ["", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "",
 "", "", " ", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "0", "1",
"2", "3", "4", "5", "6", "7", "8", "9",
"", "", "", "", "", "", "", "A", "B", "C",
"D", "E", "F", "G", "H", "I", "J", "K", "L",
"M", "N", "O", "P", "Q", "R", "S", "T", "U",
"V", "X", "Y", "W", "Z"]

for hex_code in encode_message:

ascii_value = int(hex_code, 16)
character = ascii[ascii_value]
print(character)

Python doesn't actually have a char type, it treats it as a very short string
instead. But other languages do consider strings to be arrays of chars
(including spaces, numbers and punctuations; these are all chars). Python
treats strings as a collection of, well, strings.
And how could we code what int(hex_code, 16) is doing for us?
How can we transform "2A" back to 42? I'll leave that as an exercise. But I'll
give you a massive hint. You could use a separate loop:
for symbol in "2A":

Or take each one of the individual symbols using their index:

code = "2A"
first = code[0]
second = code[1]

You can use int(string) to cast a string to an integer. And after that,
reverse engineer the whole thing. Have a crack at it. I'll post the answers to
these exercises on this book's website at www.rengelbert.com/codingbook/.
 4
I Promise This Is Not About
Bitcoins
Moving on with our conversion-themed explorations. I think it's about time
we talked about encryption, the science of generating unreadable text on
purpose. One of the oldest forms of encryption was known as the Caesar
Cipher—from the same people who created the salad, I suppose. It's also
known as a shift cipher because of the way it shifts the alphabet either to the
right or to the left, a certain number of times. The idea then is to write your
secret message using this shifted alphabet as if it were the regular one. The
logic, when expressed as a program, is quite simple. You have a collection
for the alphabet and a separate collection for the shifted alphabet. You use the
same index to find and pick letters using these two collections. Index 0 on the
regular alphabet gives you A, but index 0 on the shifted alphabet may give
you a C. So whenever you need to write A, you write it as C.
We can list the steps we'll need to create a Caesar Cipher as:

Create a collection with all the letters in the alphabet in their proper
order.
Create a collection for the shifted alphabet, which starts as a copy of the
original list.
Shift the second collection one place to the right, so that A becomes B,
B becomes C...
Grab the message we want to encrypt and loop through it, getting the
index for each character in the first alphabet collection. The one that lists
letters in their right order.
Create a new message with characters from the shifted collection using
the same index.

We'll continue working with Python for this. The first two steps look like
this:
alpha = ['A','B','C','D','E','F','G','H','I','J',
'K','L','M','N','O','P','Q','R','S','T',
'U','V','W','X','Y','Z']

caesar = list(alpha)

I can use list() to make a copy of another list in Python or turn a

collection into a list. But how could we do the shift to the right in the second
list? Here's one way:
caesar.insert( 0, caesar.pop() )

We're not appending to the list here. Appending adds an element to the end
of the collection; instead, we're using another helper method:
List.insert(). It takes an index for where you want to insert the new
element and the element itself. But for this second parameter, we call another
helper method: List.pop(). This removes the last element in the
collection and returns it. For instance, the following code...
char = caesar.pop()

... assigns to the variable char the value of Z and removes Z from the
caesar list, both at the same time.
By inserting at the beginning of a list the last item from the same list, we
shift the items. Caesar now looks like this:
caesar.insert( 0, caesar.pop() )

# ['Z','A','B','C','D','E','F','G','H','I','J',
'K','L','M','N','O','P','Q','R','S','T','U',
'V','W','X','Y']

Z is the last item in the list and the last item gets popped and inserted at the
beginning. But what if we wanted to shift to the left? Can you think of a way?
I can give you a hint. In Python, List.pop() can take an argument for the
index you wish to remove from a list (by default it pops the last one). So how
about:
caesar.append( caesar.pop(0) )
 We're back to using List.append() now, which adds to the end of the
list. This results in:
# ['B','C','D','E','F','G','H','I','J',
'K','L','M','N','O','P','Q','R','S',
'T','U','V','W','X','Y','Z','A']

More Loops
Going back to loops for a moment. There are a variety of loops one can
choose from. We saw one in the last chapter that allowed us to loop through a
collection or string. The two main players in the loop game used to be the
for and the while loops. And the for loop was not the one we've seen, but
rather this monstrosity common in many languages except Python:
for (var i = 0; i < 10; i++) {
}

The three notations inside the parentheses—separated by semi-colons—are

the conditions describing the loop. The code block inside the loop repeats
execution a certain number of times described by those conditions. Using the
for loop above as an example, the loop ascribes a value from a set range of
values to a variable I called i. It would start with i being 0 (i = 0). It
would run until i was less than ten (i < 10). And in each iteration the
value of i would increase by one (i++). That funny i++ notation is
shorthand for i += 1 which is itself a shorthand for i = i + 1.
Shorthands like this are known as "syntactic sugar." They exist to make you
type less, but are generally less readable.
The symbols < (less than), > (greater than), <= (less than or equal to), >=
(greater than or equal to), == (equal to), != (not equal to)... are known as
comparison operators and are just as important as the mathematical ones
we've seen (* / + -). Each language may use slightly different syntax, but they
will always offer a way to express these operations. (Notice that = assigns a
value but == checks for equality between two values).
This type of for loop can be useful when you want to both loop and have
the index information for each iteration. The for loop we saw earlier (for
element in array) does not provide this extra bit of info. Python
supports this indexed for loop format but it prefers this syntax:
for i in range(0,10):
# do something with i

It will loop, assigning to the variable i values from the range 0 to 10, not
including 10 (0,1,2,3,4,5,6,7,8,9). If you start the range from 0, you can omit
it from the range:
for i in range(10):
# do something with i

You can loop through a list using indexes within a range like this:
for i in range(0, len(my_list)):
item = my_list[i]

# or without the 0:

for i in range(len(my_list)):
item = my_list[i]

This, as I said, makes more sense if you want to use the value of the
variable i for something else in your logic. When it's important to know
where an element is inside the list.
And then we have the while loop. Very powerful and useful in its own
way.
while condition:
# do something

You could rewrite the previous for loops in this example using a while loop
like this:
i = 0
while i < 10:
# do something and then increment i
i += 1

It runs until the condition described at the top of the loop block is no longer
valid. At the heart of most games you play, you'll find a while loop churning
away with an apparently endless loop like this:
while true:
# run game inside this block

The game's internal logic will dictate when to quit the loop, otherwise, the
entire time you're playing a game, the computer is stuck inside a while loop.
So why am I telling you all this? Because we can use these loops to
perform a series of shifts if we wish the number of shifts to be a variable in
our program. Loops are not just ways to traverse a collection, you can use
them to repeat tasks. Remember, we only shifted the alphabet once, but what
if we wanted to run multiple shifts? An n number of shifts, let's say, five
times?
for i in range(5):
caesar.insert( 0, caesar.pop() )

# or
i = 0
while i < 5:
caesar.insert( 0, caesar.pop() )
i += 1

Notice that we did not actually use the value for i in the first loop, so
Python lets us write the same thing like this:
for _ in range(5):
caesar.insert( 0, caesar.pop() )

The _ means Any, as in "any value".

Python does offer many simpler ways to do the exact same thing
with less typing; like using something called a slice operation, for
instance. But I want you thinking in terms of loops at this stage. We
could also skip creating a shifted alphabet altogether and use the
decimal ASCII value for each letter. We could then create the "shifts"
by adding or subtracting this integer value.

Continuing with our encryption code, you can test this bit of logic:
alpha = ['A','B','C','D','E','F','G','H','I','J',
'K','L','M','N','O','P','Q','R','S','T',
'U','V','W','X','Y','Z']
caesar = list(alpha)
caesar.insert( 0, caesar.pop() )

for character in 'That famous scifi movie makes a hidden reference to

IBM':
index = alpha.index(character.upper())
print(caesar[index])

Inside the for loop we grab each character in the sentence, find the index
for it in the alpha list, and use that index to find the encrypted version of
the character from the caesar list. The String.upper() method is a
built-in string method that changes a string to uppercase. Its counterpart is
String.lower(). Here we're making sure the char we're converting is set
to uppercase because that's what we have in our lists. Yet, this code will not
work as it is. Can you spot why?
Answer: spaces are also characters. Yet, spaces are not included in our
alpha list. And yet, they're present in the string we're encrypting. Therefore
alpha.index(" ") won't find a space inside the list and then what
happens? Kaboom! That's what happens. Our program crashes. We need a
way to check our logic for possible explosions like this before moving on.
We need to establish some conditions to our logic. And what better way to do
that than to use...

Conditionals
You might have used the online services of IFTTT, which stands for If
This, Then That. With that one sentence you've learned everything you need
to know about conditionals. They're the turning points in your code, dictating
where things go in your logic, based on some set of logical comparisons...
And they're written just as IFTTT states (using pseudo-code for now):
if this
then that

Or better yet, IFTTTOET:

if this
then that
or else
this

Or better still, IFTTTOIFTTTOESE:

if this
then that
or if this
then this
or else
something else

And on and on and on... You can express all sorts of conditions, expanding
and grouping them using comparison (or logical) operations like AND, OR,
EQUAL and NOT EQUAL, GREATER THAN, SMALLER THAN...
if I had a brain
I could while away the hours
Conferrin' with the flowers,
Consulting with the rain;
And my head I'd be a scratchin'
While my thoughts are busy hatchin'

if I had a hammer AND I had a bell AND I had a song

I'd hammer and ring it and sing it in the morning
I'd hammer and ring it and sing it in the evening
All over this land!

if (rock AND scissors) OR (scissors AND rock)

rock wins
else if (rock AND paper) OR (paper AND rock)
paper wins
else if (paper AND scissors) OR (scissors AND paper)
scissors win
else
we have a tie

Python calls "else if" statements "elif." As if it would kill us to write the
extra characters.
if day > FRIDAY:
weekend
else:
weekday

if time > 6pm:

evening
elif time > 12pm:
afternoon
else :
morning

Python calls the AND operator and and the OR operator or. But most
languages will use && and || respectively.
if myValue > 10 and myValue < 20:
print("my value is between 10 and 20")

if myValue == 15 or myValue == 16:

print("my value is either 15 or 16")

And pay attention to the new code blocks and the indentations creating
them. They follow the same rules we saw in the for each loop. Use a colon to
start the block and indentation to separate the elements that belong to each
block. Again, just as you would with an outline.
Conditionals are the second type of special code block, after loops. Its
peculiarity is that the block created by the if statement will only execute if the
condition described is met. And I should mention, you can nest one block
into another, as many times as you need. Conditionals inside loops, loops
inside loops inside conditionals...
And now back to Caesar. I can check whether the character can be found in
alpha before encrypting it:
alpha = ['A','B','C','D','E','F','G','H','I','J',
'K','L','M','N','O','P','Q','R','S', 'T','U','V','W','X','Y','Z']

caesar = list(alpha)
caesar.insert( 0, caesar.pop() )
for character in "That famous scifi movie makes a hidden reference to
IBM":
if character.upper() not in alpha:
continue
index = alpha.index(character.upper())
print(caesar[index])

If character not in alpha, skip to the next character. The

continue keyword, written inside the if statement's internal block, will
skip the remaining lines inside the loop and move on to the next iteration—in
this case, to the next character. I coded my if statement like this just so I
could show you how to control the iterations inside a loop. You can also
break out of a loop:
for something in someList:
if notWorking:
break

The break keyword takes you out of a loop, essentially breaking it.
continue skips the current iteration and starts on the one immediately after
it, if any.
But we could have written our conditional like this instead:
for character in "That famous scifi movie makes a hidden reference to
IBM":
if character.upper() in alpha:
index = alpha.index(character.upper())
print(caesar[index])

We remove the not and the need for continue and ensure that we only
run the code block created by the if statement if the character is in the alpha
list. And since we built the caesar list out of the alpha list, we don't need
to check if caesar contains the element as well. One check is enough for
both.
Our encrypted message looks like this when printed to the console:
SGZSEZLNTRRBHEHLNUHDLZJDRZGHCCDMQDEDQDMBDSNHAL
But hang on, there are even better ways to achieve the same result. Which
brings us to...
 Functions
Simply speaking, a function is a special kind of code block (our third after
loops and if statements), one you're able to refer to in your code the same
way you refer to variables. This means, unlike other code blocks we've seen,
a function code block is declared before it can be referred to. Functions create
blobs of logic that once declared can be executed as many times you like.
When we run the following script:
for _ in range(2):
print("Hey ")

print ("We're the Monkees!")

We see the prints in the order they appear in the code. Even the one inside
the for loop block gets executed immediately. But if I used a function block
in my code:
for _ in range(2):
print("Hey ")

def finishSong ():

print ("We're the Monkees!")

Now when I run this, I only see the print inside the loop because the
function I wrote was declared but not called and a function needs to be called
in order to be executed:
for _ in range(2):
print("Hey ")

def finishSong ():

print ("We're the Monkees")

# call function
finishSong()

It is as if the code block described in the function declaration was

magically inserted where the function is called in our script. And this can
happen as many times as you wish. This is one of the main advantages of
functions. They allow the programmer to place logic inside self-contained
units that can be called from anywhere in the code, and as many times as it's
necessary.
Here are some of the common ways functions are declared in a variety of
languages:
bool login (String username, String password) {}
function login (String username, String password):bool {}
func login ( _ username:String, _ password:String)-> Bool {}
def login (username, password):

But it's all potato potahto. As with any other kind of language, the
individual syntactic parts may be placed at different spots in a sentence but
the main parts are all there—function name (if any, a function may be
anonymous), a parameter (if any, a function may be parameterless) and a
return value (if any, a function may return void, a fancy word for nothing).
A function returns something by using the command return (though
some languages do without it):
def getMeaningOfLife ():
return 42

Python uses the def keyword, which denotes the start of the function
declaration. It ends the declaration by creating a block using the colon
symbol (other languages use curly braces for this). The def keyword holds a
special meaning. It's saying the next word is a unique sort of variable; it will
not point to any common value type but a special one: a function. Yes, a
function is a type, at least in most languages. The function itself is the body
and arguments attached to it. Some languages make this even more obvious
with syntax such as:
myFunction = func (argument1) {
...
}

Each argument is further named with a variable so we may refer to them

inside the function's block:
def myFunction (myArgument1, myArgument2):
print(myArgument1)
print(myArgument2)
 Python does not bother with argument types and it does not list a return
type even if the function returns something. In the examples I gave of all the
different syntaxes, if those particular functions I listed returned nothing
(void), the functions would be declared as:
void login (String username, String password) {}
function login (String username, String password):void {}
func login ( _ username:String, _ password:String)-> Void {}
def login (username, password):

You can see in the last one, the one using Python syntax, that you can't
know from a Python function declaration what types of arguments it needs or
whether it returns something unless you give the function and arguments
really good names.
When we used list.append(element), list.pop(),
len(list), int(string, 16), print('Hello World') ... we
used built-in functions and methods that come with the Python language.
You can learn what these functions do or what arguments they expect by
reading their signature in the documentation. Every function has a signature
(this acts as the function's type in some languages). Something like:
(a) -> b
Or:
functionName (a) -> b
This function takes an argument of type a and returns a value of type b.
However, both a and b can be empty, or non-existent, and you can have as
many arguments as you wish, and in some rare languages as many things
returned from the function as you wish... All this will be reflected in the
function's signature:
(int) -> int
(int, string, int) -> string
() -> int
() -> void

Good. We can write our own functions. But when should you do it?
A function will provide a few extra features to your code. First of all, after
variables, it's the second thing you can name and that means context! Be
careful with how you name your functions since these names can help clarify
your code. A function name should make it clear what the function does and
if possible what it returns or takes for arguments. Besides that, a function can
help further organize your code into blocks of reusable logic. When you find
yourself repeating lines of code, you should think of placing them inside a
function's body and call that multiple times instead. But also think in terms of
isolating blobs of logic that can stand on their own; a function is a good place
for logic that performs a very specific... well... function.
All the code we've written thus far could have made good use of functions
or could have been themselves wrapped inside a function. It's up to you when
to use them, but keep those goals in mind: make your logic clear through
meaningful context, don't repeat yourself (think of code re-usability), and
isolate stand-alone logic.
Before we can go back to our encryption code, I want to go over a few
topics related to functions.

Scope
We saw how Python uses the : symbol plus line indentations to create
code blocks. Loops have them, if statements have them, and so do functions.
In programming we say that each code block creates a scope. When I write
the following:
myMessage = "HELLO MARS"

print(myMessage)

I'm writing this in the global scope—think of it as the root of your script.
This scope does not need a : symbol at the start or any special indentation (in
fact, it can't have any). It's always there. The print() function can access
myMessage because they both exist in this same scope, the global scope.
But when I write this:
myMessage = "HELLO MARS"

def myFunction ():

meaningOfLife = 42
 # this is okay
print(myMessage)

# but this is not okay

print(meaningOfLife)

The function myFunction() created a new scope inside its code block.
From that "child" scope, we can access anything from the parent scope (the
global one in this example). But the parent scope cannot access anything
declared inside the myFunction() scope.
Scope is a one-way street. Only inner scopes may access information
(variables, function names) from outer scopes but not the other way around.
This is also known as lexical scope and this rule applies ad infinitum. As long
as I create inner scopes—loops inside loops inside if statements inside
functions—their relationship and the way they access each other's properties,
variables and functions will be dictated by the rules of scope.
Different languages will fiddle with this rule in different ways (not all
languages use lexical scope, but those are rare). For instance, Python allows
this to work:
myName = "George"

if myName == "George":
# by the way: == means "is equal to"
myFullName = "George Jr"
else:
myFullName = "Ass Kicker Billionaire Big-Boss-A-Tron"

print(myFullName)

In many languages this would throw an error since the global scope is
trying to print() something declared inside the if statement's child scope
(myFullName). As a matter of fact, most languages would treat both
instances of myFullName inside the if and else statements as different
variables that happen to have the same name because they were declared in
different, sibling scopes and the same rules apply to those: a scope can only
access information from itself or a parent scope. Python disregards this,
however, and to my eyes it looks completely bonkers.
 There is a general rule in programming (a best-practice sort of thing) that
states one should not use global scope that much. This means functions
should not refer to anything in global scope and that these global values
should be passed to the function scope via the function's arguments. I'll show
you an example of this in a moment. I break this rule all the time, but it is a
good one.

Control Flow
If statements, loops and function blocks are collectively responsible for a
programming feature known as control flow. This means the path your logic
follows in a program will be controlled by these blocks. Loops will keep your
logic stuck to a point until the loop is complete, if statements will omit entire
chunks of your logic if a condition is not met, and functions will make your
logic jump around between self-contained units of operations. Each language
may introduce more types of control flow elements, but they will always be
some extended version of these three.

Operators, Methods and Functions

What's the difference? An operation uses operators: + * / - = == [ ] < >.
Most of these are in reality syntactic sugar for binary functions. Binary
because they always deal with two arguments. You use + to add two
numbers, for instance. In the background they are actually treated by the
compiler as functions that take two parameters.
Methods are actions performed by a subject on itself. When I say
myList.append("A"), I'm using a list method that is directly affecting
the list declared and bound to the variable myList. So list.append() is
said to be a method because it needs a list to perform it, and it changes the
state of the object that called it (it acts on it).
Functions don't do that. They may process arguments and may return a
value but they're not attached to a subject (object). When I say
len(myList) I'm using a function. It's easy to spot the difference between
a function and method because of the use, or lack of, a dot linking subject to
action in the case of methods.
 Having said that, I often use both terms interchangeably.

Higher-Order Functions
I said that a function is basically a type, like an integer or string. Therefore,
a function should be able to receive another function as an argument or return
a function as its return type, just as it can with any other type. When this
happens, we have what is known as Higher Functions or Higher-Order
Functions. They are incredibly powerful. And in particular, they offer very
powerful ways to deal with collections.
We learned about collections and some of the basic transformations you
can apply to them: add elements to a collection, remove elements from a
collection, shift elements in a collection... And one thing you should try to
focus on, from now on, on your way to becoming a better programmer is
even more ways to transform collections. Why? Because that's what you'll do
90% of the time in your code. We learned loops and have used them to
perform these transformations. But as far as collections are concerned, loops
are not the ideal way to transform them, or at least not the only way. You can
do it through the use of higher-order functions. And map() is the first one I'd
like to show you. Check out this code:
alpha = ['A','B','C','D','E','F','G','H','I','J',
'K','L','M','N','O','P','Q','R','S','T',
'U','V','W','X','Y','Z']

caesar = list(alpha)
caesar.insert( 0, caesar.pop() )

def encryptChar (char):

if (char.upper() not in alpha):
return char
index = alpha.index(char.upper())
return caesar[index]

encryptedMessage = map(encryptChar, "That famous scifi movie makes a

hidden reference to IBM")

print ("".join(encryptedMessage))
 I wrote a function called encryptChar() that does something similar to
what we had inside our loop earlier. It takes a variable char as a parameter,
checks if the value of char is listed in the alpha array. If not, it returns the
value as it is. But if we do have that value in our array, we convert it to the
encrypted version and return that instead.
Then comes Python's higher-order function map(). It takes a collection as
its second parameter, this could be a list or a string or anything that can be
iterated through. map() will pick each of the elements in this collection— in
this example, the characters in the string—and pass it as an argument to the
function listed as the first parameter. This function must take the element as
its argument and return a value that will be used to construct the new
collection. In other words, map() returns a collection of the transformed
elements from another collection. You pass map() a collection A and a
function F and map() will return a collection B with all the elements of
collection A transformed by the function F. Or in other words, this:
def times2( number ):
return number * 2

result = list( map (times2, [1,2,3,4]) )

print(list)

# result: [2,4,6,8]

map() returns a so-called iterable object and must be cast into the
type of collection you want the result to be in (in case you need it). Casting is
the act of transforming a type into another type. In this case I cast the iterable
object I got from map() into a list by using the list() function. We used
casting before to turn integers into strings using the str() function and
strings into integers using the int() function.
I didn't have to do this with our other example:
encryptedMessage = map(encryptChar, "That famous scifi movie makes a
hidden reference to IBM")

print ("".join(encryptedMessage))

Because I ran "".join() on the result and string.join() takes an

iterable as a parameter. The Python documentation (you can find it
online at https://docs.python.org/3/) lists its syntax as:
string.join(iterable)

All collections and strings are iterables. They are things you can iterate
through.
In our encryption code, the characters in the message "That famous scifi
movie makes a hidden reference to IBM" are said to be "mapped" to a new
transformed collection.
And what if I wanted to pass encryptChar() more than one parameter?
What if I wanted to pass it a reference to the alphabet lists? For that, I could
have used a lambda instead. A lamb-what? Spot the differences:
alpha = ['A','B','C','D','E','F','G','H','I','J',
'K','L','M','N','O','P','Q','R','S','T',
'U','V','W','X','Y','Z']

caesar = list(alpha)
caesar.insert( 0, caesar.pop() )

def encryptChar(char, alpha, caesar):

if (char.upper() not in alpha):
return char
index = alpha.index(char.upper())
return caesar[index]

encryptedMessage = map(lambda char : encryptChar(char, alpha,

caesar),
"That famous scifi movie makes a hidden reference to IBM")

print ("".join(encryptedMessage))

lambda is the keyword in Python used to create an anonymous function.

In computer programming, anonymous functions are universally known as
lambdas. The Python syntax for a lambda is:
lambda argument : body of lambda
or
lambda argument1, argument2, ... : body of lambda
 or
lambda : body of lambda
You use lambda to create a function on the "spot" as it were, a function
without a name because you don't intend to call it from anywhere else in your
code save from within a higher-order function. When used with map(), the
lambda function must match the signature of the function map() expects; a
function that takes only one parameter—the element from the collection.
Here's an example:
result = map (lambda number : number * 2, [1,2,3,4])
# result: [2,4,6,8]

This lambda function is declared as the first parameter in the map()

function and takes one argument called number.
In my encryption code, I can now, with the use of lambda, take the
character argument and pass it to the encryptChar() function along with
the two collections of letters:
map(lambda char : encryptChar(char, alpha, caesar), "That famous...")

This way I decouple encryptChar() from outside references. When a

function must refer to something in an outside scope, we say a coupling was
created. In the previous version of encryptChar() the function could
only work if an outer scope contained two lists, one called alpha and one
called caesar. If that didn't happen: Kaboom! Now I don't have that
problem anymore since I must pass references to those lists as arguments in
my function. Not a biggie. Just showing we could. Although couplings are
considered a faux pas in programming. I mentioned the "good-practice" of
not using global scope in your code if you can avoid it. This is why.
I ended the code by joining the encryptedMessage collection elements
so we can spit out an encrypted sentence that looks like this now:
print ("".join(encryptedMessage))

SGZS EZLNTR RBHEH LNUHD LZJDR Z

GHCCDM QDEDQDMBD SN HAL

As an exercise, can you pin-point in the code the logic that allows for
spaces now in the encrypted message?
 If you ever played a Crypto game you know how to crack coded messages
like the ones seen here. You look for shorter words and run through the
possibilities. Is that encrypted three-letter word an AND or an ARE or an
ANY?. In the encrypted message above we know Z = A because we see a Z
standing alone, and if we know the language is English then we know there
are not many letters than can stand alone like that. Another way to crack them
is to look for repeated sentences. If every Roman letter began with "Dear
Caesar" or ended with "P.S. Watch out for Brutus. XOXO" their encryption
would be rendered pointless. Even Enigma, the infamous Nazi encrypting
machine, was cracked with, among other things, repeated sentences the Nazis
insisted on adding to their messages.
And speaking of Roman Emperors, can you guess what type of conversion
this code is doing?
def convertWord (word):
if word[0] in "aeiou":
return word + '-yay'
i = 0
while i < len(word):
if word[i] not in "aeiou":
i += 1
else:
return "{0}-{1}ay".format(word[i:], word[0:i].lower())

def convertSentence (sentence):

words = sentence.split(" ")

result = []
for word in words:
result.append (convertWord(word.lower()))
return " ".join(result)

print( convertSentence ( "Et tu Brutus" ) )

Can you guess what the built-in methods split() and format() do?
Can you guess what the operator [:] in word[i:] and word[0:i] does?
The answers are at the end of this chapter.
 Another form of encryption, this one relatively closer to what we use on the
Internet and cybersecurity, is the one that makes use of a key. We'll code the
simplest form of this encryption, which is not much better than the Caesar
one to be honest, by using a keyword. The steps are:

Pick a secret word to use as the key.

Use the letters of that word (ignoring repeats) as the beginning letters of
the alphabet.
Fill out the remainder of the alphabet, starting from A, but again without
repeats.
From here on out, the process becomes the same as the Caesar cipher.

For instance, if we picked the word "WORD" as our key, the resulting
cipher alphabet would be:
['W','O','R','D','A','B','C','E','F','G','H','I','J',
'K','L','M','N','P','Q','S','T','U','V','Y','X','Z']

How would we code that?

We start the alphabet with the key characters and fill out the remaining
letters starting from A, but without any repeats. Once again we start with a
normal alphabet stored inside a collection:
alpha = ['A','B','C','D','E','F','G','H','I','J',
'K','L','M','N','O','P','Q','R','S','T',
'U','V','W','X','Y','Z']

We pick our keyword, let's change that to:

word = "PASSWORD"

And we'll use those two things to populate our cipher collection. So we
start with an empty collection this time:
cipher = []

And we'll fill it up with the cipher characters.

Python lets us cast a string into a list collection:
key_char_list = list(word)
# key_char_list = ['P','A','S','S','W','O','R','D']
 Or we can use a while loop to add "PASSWORD" to our cipher:
while (len(key_char_list) > 0):
c = key_char_list.pop(0)
if c not in cipher:
code_chars.append(c)

Can you see why the second option is the better one?
We're doing it like this instead of simply dumping the characters inside our
cipher list because the keyword might have duplicate characters
("PASSWORD" repeats an "S", for instance). We loop until
key_char_list is empty, popping the first item of that list and adding it
to our cipher if the cipher does not contain it already. Remember, no repeats.
The result should be: ['P', 'A', 'S', 'W', 'O', 'R', 'D'], with only one S.
We use a second while loop to finish filling up our cipher:
alpha = ['A','B','C','D','E','F','G','H','I','J',
'K','L','M','N','O','P','Q','R','S','T',
'U','V','W','X','Y','Z']

extra_chars = list(alpha)

while (len(cipher) < len(alpha)):

c = extra_chars.pop(0)
if c not in cipher:
cipher.append(c)

The condition I used was: keep looping until cipher has a length of 26,
which is the length of our alpha collection (our alphabet). Again, we pop
letters from another alphabet collection created just for this purpose and we
don't add repeats. The result is:
['P', 'A', 'S', 'W', 'O', 'R', 'D', 'B', 'C', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N',
'Q', 'T', 'U', 'V', 'X', 'Y', 'Z']
But did that seem like a lot of code to you? If so, you're right. That
extra_chars list does seem like overkill, doesn't it? Isn't there a way to
combine both loops, the one adding "PASSWORD" and the one adding the
remaining letters?
Yes. Half a dozen or so. Including another important higher-order function
called filter(). But for now, let me finish the code as-is and then get
back to making it all pretty.
Once we have the cipher characters, we can proceed just as we did before:
for char in "My password is the dumbest one":
if char.upper() in alpha:
index = alpha.index(char.upper())
print(cipher[index])

There, all done.

So how about that filter() function I mentioned? We can use it to
remove the second while loop (with the extra help of yet another helper
method). See if you can understand what these do:
def filterDuplicates (char):
return char not in cipher

cipher.extend( filter( filterDuplicates, alpha ) )

First of all, the list.extend() built-in method lets you add all the
elements of a collection B into a collection A.
collectionA = ["A","B","C"]
collectionB = ["easy","as","1","2",3"]

collectionA.extend(collectionB)

# ["A","B","C","easy","as","1","2",3"]

But filter() is more interesting. What filter() does is it returns a

boolean value through what is known as a predicate. In regular grammar a
predicate is the stuff you attach to a subject. In "Bob is awesome", "is
awesome" is a predicate. In programming, a predicate is an operation that
given a "subject" will evaluate it, usually returning a boolean as a result. If
you recall, the function inside a map() must return a value that will be
appended to the resulting collection. But the function inside a filter()
must return whether the current value being evaluated should be in the
resulting collection. So it "filters out" things you don't want, whereas map()
transforms all the elements. In this example:
def filterDuplicates (char):
 return char not in cipher

cipher.extend( filter( filterDuplicates, alpha ) )

... we're only adding characters which are not in the cipher so that the
cipher contains no duplicates. filter() will run
filterDuplicates() on each element and that function will return a
true or false value to determine whether the element should be added to the
filtered list.
We could have used a lambda too instead of that silly, one-line function:
cipher.extend( filter( lambda character : character not in cipher,
alpha ) )

And now, we can use filter to replace both our loops. First we add the
keyword:
cipher = []
cipher.extend(filter( lambda character : character not in cipher,
"PASSWORD" ))

And after that we can add the characters in the alpha list.
And of course, we can use map() again for the remainder conversion
logic, reusing our function from before. The entire script now looks like this,
using filter() and map() higher-order functions:
alpha = ['A','B','C','D','E','F','G','H','I','J',
'K','L','M','N','O','P','Q','R','S','T',
'U','V','W','X','Y','Z']

cipher = []
cipher.extend(filter( lambda character : character not in cipher,
"PASSWORD" ))
cipher.extend(filter( lambda character : character not in cipher,
alpha ))

def encryptChar (char):

if (char.upper() not in alpha):
return char
index = alpha.index(char.upper())
return cipher[index]
encryptedMessage = map( encryptChar, "My password is the dumbest one"
)
print ("".join(encryptedMessage))

Resulting in: HY KPNNVJMW CN QBO WTHAONQ JIO.

There is a tradition with Python of using lines and quotes from Monty
Python in examples demonstrating the language. So here's a puzzle for you,
using a line from Monty Python :
VCIF VCIF, ITWDO ITWDO. NPY IJ HJMO, NPY IJ HJMO.
You can, as an exercise, write the code that solves it (reverse engineering
our code), since it uses the same key we've been using. You'll find the answer
in this book's website: www.rengelbert.com/codingbook/.
And as a bonus, here are a bunch of one-liners encrypted using a different
key:
NJW WPS QJFA SKEBT BH TWJ? WBTN P KPBQ JM OAPSPQS
B WPS WJHGAQBHI WNY TNA RPEE WPS IATTBHI RBIIAQ. TNAH
BT NBT FA.
WNAH EBMA IBVAS YJU FAEJHS, YJU'QA GYSEAXBO.
HAAG PH PQD? B HJPN IUY.

Back to the code. How about this change, using a new function and our
silly predicate?
alpha =
['A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P','Q','R','S','T',

def createCipher (keyword, alphabet):

# oooh, an internal function!

def filterDuplicates (char, unique_chars):
return char not in unique_chars
 cipher = []
cipher.extend ( filter( lambda c : filterDuplicates (c, cipher ),
keyword ))
cipher.extend ( filter( lambda c : filterDuplicates (c, cipher ),
alphabet ))
return cipher

cipher = createCipher ("PASSWORD", alpha)

print(cipher)

This will result in the same cipher. I used the silly function as the predicate
but this time I declared it as an internal function. The internal function is
declared inside another function (yes, we can do that; it's basically what we
do with lambdas, after all). And I used that predicate twice. Once for the
keyword "PASSWORD" which makes sure we don't end up with two "S" in
our cipher, and then I use it a second time with the alphabet letters. It prints
out the same cipher alphabet:
['P', 'A', 'S', 'W', 'O', 'R', 'D', 'B', 'C', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N',
'Q', 'T', 'U', 'V', 'Y', 'X', 'Z']
But one could argue this code is harder to read, particularly if one is a
beginner programmer. And I agree. Loops are easier on the eyes sometimes.

One other thing you can do is create a prompt for a sentence you wish to
encrypt and display this prompt inside the console. When you type something
and hit enter, the sentence is encoded with our cipher. In Python you do it
like this:
sentence = input("Enter a sentence: ")
encryptedMessage = map(encryptChar, sentence)
print ("".join(encryptedMessage))

The input() function will present "Enter a sentence: " as a prompt to the
user in the console and will wait on that line of code until the user enters
some text and hits enter. It will then bind that inputted text to the variable
sentence and we can proceed with the rest of the code from there. The
whole thing looks like this (after some clean up):
alpha = ['A','B','C','D','E','F','G','H','I','J',
'K','L','M','N','O','P','Q','R','S','T',
'U','V','W','X','Y','Z']

def createcipher (keyword, alphabet):

def filterDuplicates (char, unique_chars):

return char not in unique_chars

cipher = []
cipher.extend ( filter( lambda c : filterDuplicates (c, cipher ),
keyword ))
cipher.extend ( filter( lambda c : filterDuplicates (c, cipher ),
alphabet ))
return cipher

def encryptChar(char, cipher):

if (char.upper() not in alpha):
return char
index = alpha.index(char.upper())
return cipher[index]

cipher = createcipher ("PASSWORD", alpha)

sentence = str(input("Enter a sentence: "))

encryptedMessage = map(lambda char: encryptChar(char, cipher),
sentence)
print ("".join(encryptedMessage))

When you run it, you get:

Enter a sentence: Hello
World
BOGGJ VJMGW

Filter and Map are cool.

I should also point out a particularity about functions in Python. You
should declare functions before you call them, otherwise, you'll get an error.
So this:
def myFunc ():
# something

myFunc()

And not this:

myFunc()

def myFunc ():

# something

You will see this behavior with some languages, but not many. Most
compiled languages won't care about the order. Python is "compiled" in a
different way which enforces declaration before references.
Well, this is it for the conversion part. Though you should think of it as
Data Transformation, rather; the most common sort of operation any
program will perform. In the next part of this book we'll deal with more
transformations but this time focusing on the ones particular to strings.
Ah, and what about this beauty?
def convertWord (word):
if word[0] in "aeiou":
return word + '-yay'
i = 0
while i < len(word):
if word[i] not in "aeiou":
i += 1
else:
return "{0}-{1}ay".format(word[i:], word[0:i].lower())

def convertSentence (sentence):

words = sentence.split(" ")
result = []
for word in words:
result.append (convertWord(word.lower()))
return " ".join(result)

print( convertSentence ( "Et tu Brutus" ) )

It converts a sentence into Pig Latin. The result is:

 et-yay u-tay utus-bray
The split() method breaks a string into multiple parts, using the
argument string as the divider. So string.split(" ") will split a
sentence at every space and return a collection of words. (Actually, if you
don't pass it an argument, split() will split the sentence on every space by
default).
The word[i:] notation is one of the many things I love about Python.
This is how it represents a "slice":
"word"[1:] results in "ord"
"word"[2:] results in "rd"
"word"[3:] results in "d"
"word"[:1] results in "w"
"word"[:2] results in "wo"
"word"[:3] results in "wor"
"word"[1:3] results in "or"

The first number shows where the slice begins (strings, like any other type
of collection, are zero-based). If there's no first number, the beginning of the
slice is the beginning of the collection. The second number indicates the end
of the slice. If there is no second number the end of the slice is the end of the
collection. Other languages support this of course, but their syntax is never as
neat as Python's. And of course, a slice operation can be used with lists.
And the string.format() function? It helps to concatenate values
inside a string. I could do something like:
greeting = "Hello"
name = "Roger"

print ( greeing + " " + name)

Or, using format():

greeting = "Hello"
name = "Roger"

print ( "{0} {1}".format( greeting, name) )

It lets me use certain symbols for the placeholders inside the string. The
most common symbols used for this are curly braces with an index count
({0}{1}{2}). Why the index? Because you might want to repeat a value:
greeting = "Hello"
name = "Roger"

print ( "Why! {0}, {0}, {0} {1}".format( greeting, name) )

And as an exercise...
Can you write a conversion script for that annoying song The Name Game
by Shirley Ellis? Here are the rules as stated in Wikipedia:

Using the name Katie as an example, the song follows this pattern:
Katie, Katie, bo-batie, Bonana-fanna fo-fatie Fee fi mo-matie Katie!
A verse can be created for any name with stress on the first syllable,
with X as the name and Y as the name without the first consonant
sound (if it begins with a consonant), as follows:
(X), (X), bo-b (Y) Bonana-fanna fo-f (Y) Fee fi mo-m (Y) (X)!
And if the name starts with a b, f, or m, that sound simply is not
repeated.
For example:
Billy becomes "Billy Billy bo-illy"; Fred becomes "bonana fanna
fo-red"; Marsha becomes "fee fi mo-arsha" "

Have fun.
 Part3:
Find & Replace
 1
Backdoors
With me, it all started with Find and Replace. Back in the early and wild
days of the internet, it seemed like every text file you downloaded (in my
case from fan-fiction websites) was badly formatted; with every line breaking
instead of wrapping essentially turning each line into a paragraph. I needed to
find a way to fix this so I could save on paper when printing these files (I
hated reading on the computer monitor, and no, there were no e-readers yet).
I found out that the program Office Word had a symbol for paragraphs (^p)
that you could use in Find and Replace operations and I thought, "Hey! I can
find all line-breaks and replace them with space."
Find ^p Replace with " "
As you can imagine that wasn't quite the solution I wanted. The result
turned the fan-fiction stories into monolithic Russian literature, with no
paragraphs at all. Some of the line breaks were paragraphs but some weren't.
Then I thought, "Hey! I can break this into multiple steps." First look for
likely paragraphs:

Find .^p Replace with .&&

Find !^p Replace with !&&

Find ?^p Replace with ?&&

Find ."^p Replace with ."&&

Find ?"^p Replace with ?"&&

Find !"^p Replace with !"&&

Why the &&? Because I would need to revert these back into paragraphs
eventually (and no, I wasn't a genius, I made lots of mistakes before I figured
this out). But the next step was to do the old switch-a-roo with the remaining
line breaks:
Find ^p Replace with " "
And finally:
Find && Replace with ^p
I was overjoyed. I guess I was young and easily impressed but I must
confess I got a kick out of it and I realize now, in hindsight, that this was my
first experience with programming. And also heuristics. A heuristic algorithm
does not solve a problem perfectly, but good enough. This "logic" I built did
not actually find the paragraphs the original author created, nothing could,
but something good enough.
Many languages will provide built-in functions to run the types of find and
replace operations I did in Word.
myString = "Hello World";
myString.Replace("lo", "p the");

Today, I spend a lot of my coding time working on Find and Replace. I

created my own word editor for fiction writing, my own bilingual ebook
reader, my own Markdown editor... Seriously, if you learn the logic I'll teach
you in this section of the book and you don't end up coding your own text
editor, you'll be missing a huge point in this whole "learning how to code"
shindig.
Look for something. Find it. Change it somehow. Or parse and analyze a
whole bunch of data and let the data show you the answers you seek. There is
a fascinating idea that over 80% of the internet is unknown. A picture of an
iceberg is often used to illustrate this point, with the tip being what we can
process digitally and the hidden part everything else. And no, I'm not talking
about the Dark Web or weird porn. I'm talking about text. Plain old, boring
text. Blogs, Twitter messages, texting... we don't have a good way to parse
what a human being wrote and determine what the hell this human being
meant by it. But we're working on it. Particularly through something called
Natural Language Processing, or NLP—and I personally find it one of the
most interesting branches of computer science. It involves breaking down
text into its semantic components and analyzing them to retrieve all sorts of
information. Is this text positive or negative? Is it a joke? Does it make
sense? And the ultimate computer science goal: Is it sarcastic?
When you type a search string in a browser the search engine will use NLP
to strip your query of all meaningless words in order to best approximate
millions of different ways to search for the same information and tie that to
the same search results. And it can only evaluate "meaning" through NLP.
Think of all the different ways one could search for:
"what are the names of all the actors who played Sherlock Holmes"
But the search engine will evaluate this and turn it into something like:
"name actors Sherlock Holmes"
To be fair, we're sort of meeting computers half-way. People are talking
more and more like their digital counterparts and so in future NLP might
become obsolete. We will all talk in acronyms. You think not? I know people
who say LOL. In the real world. Out loud. Not as a joke. For reals. And sure,
it's funny to see AIs writing poetry, but how much do you wanna bet that
teenagers twenty years from now will talk in non sequiturs just like the AIs?
"I banana yesterday. It was grapes! LOL."
And then there are the joys of data analysis. Yes, I said it! The joys of data
analysis!
Writer Vybarr Cregan-Reid looked up mentions of the word "chair" in
written texts throughout history to help him determine when chairs became a
thing (turns out we spent a great many years sitting on the floor). Researchers
are often looking up keywords in old books and newspapers to determine the
happiest year in the history of a country. Researchers from Warwick and
Glasgow Universities in the UK recently used a list of 14,000 keywords to
determine the happiest year in England. Answer: 1880. And the saddest of
all? 1978. What kind of words did they look for? Peaceful, Enjoyment,
Happiness, "This the best year evah!!!" to name a few. People are not very
subtle, I guess. And all this by going through a huge chunk of text looking for
keywords. A collection and a loop. The other day, I was listening to the song
Young Girl by Gary Puckett & The Union Gap, and then I began paying
actual attention to the lyrics and wondered: "Holy crap! Is this song about
what I think this song is about?" So I Googled it and I found all these
websites listing songs people believe are about statutory rape and pedophilia.
And I thought: "Uhm, imagine looping through all the lyrics of every song
ever written and identifying exactly when we as a species decided that, you
know what, let's stop doing pedophilia songs because it's creepy." A
collection of lyrics, a collection of keywords, and we'd be sorted.
Find and Replace is cool.
We'll leave Python for a while and focus on another language in this
section. I've considered doing the entire book using nothing but Python; a
common pattern used by other books on how to program, but then decided
against it. It is of the utmost benefit to you to keep "re-learning" these
annoying syntactic differences: how to create a collection? how to get its
length? how to append and remove? how to loop it? can I map it? can I filter
it? how do I convert a string to an integer? and on and on and on... And to
focus on what is being accomplished, which will remain mostly unchanged
between languages. Programming is what's being accomplished, not the
syntax. Besides, I intend to show you in this part of the book why the syntax
is so weird in the first place: it turns out it has to do with find and replace
operations.
I've decided on C# for this entire section of the book. C# (pronounced C
Sharp, like the musical note) is a Microsoft language with strong ties to web
development, servers, and games and of course anything Windows. It looks a
lot like Java—if you squint your eyes a bit—so we can metaphorically kill
two birds with one stone at least as far as basic syntax goes. Or two birds and
a half, since I've also decided to show you F# later on (another Microsoft
language). C# is statically typed, stricter than Python but really good at
inferring type. Although considered to be multi-paradigm, the language
focuses heavily on one paradigm called Object Oriented Programming. I will
show you what that means later in the book.
We'll start with a very basic form of string "finding" commonly known—
particularly in Hollywood movies—as backdoors. This is used a lot in games
to help with testing and smoking out bugs and is often referred to as "cheat
codes" because when you need to check a bug in a game at the end of a
labyrinth in level 50 and you don't want to go through the whole thing every
time, you press a few keys and presto, your character now can walk through
walls. In popular culture, however, backdoors are ways you can enter high-
security systems by typing a random series of characters (or not so random,
like "admin". It works too many times).
Go to https://dotnetfiddle.net (or https://repl.it if you decided to go that
route) and select C# as the language from the drop-down on the left, and for
Project Type select Console. We code inside the big frame in the middle of
the page and see the console output at the bottom. If you register with the
website you'll be able to save your scripts. In the real world, your scripts
would be coded inside text files saved with a .cs extension and it would exist
inside a project known as a solution.
DotNetFiddle is a simplified version of what is known as an Integrated
Development Environment, or IDE. When you code in a certain language,
you'll look for a good IDE or Code Editor that has support for that language.
It's the difference between writing a word on paper and writing a word on a
Word Processor, with spell checking and predictive text. But since we're
talking about programming languages you get even more benefits than just
"spell-checking." The editor will give you error messages explaining what is
wrong with a specific part of your code, and although these are not always
the most useful, it's good to have them. Bits of the code will be color-coded
according to their syntax role. This is known as syntax highlighting and it's
the reason coding looks like a clown sneezed all over your monitor. I will
give you instructions at the end of the book on how to get your hands on
good IDEs.
So how does a backdoor work exactly? We create something known as a
sub-routine. No matter what the application is about—a game, a dating
service or a calculator—in the background, we have this little bit of logic
"listening" to keyboard input and constructing a string by appending every
individual key pressed and comparing the result to a hidden keyword or
pattern. Our keyword will be Jeff Jeffity Jeff; this comes from an Eddie Izzard
joke on this exact same subject from his special Glorious (Google it!). If the
first character and the second character in our user's input is Je, we keep on
building the string. If the third character typed by the user is not f, we clear
the string we're building and start all over again with the next input. So in
order for a backdoor to be "activated" the user must type all characters in
their proper sequence.
We saw how to get input in Python, so what does it look in C#? Let's take a
look at what we see in our program window right now:
using System;

public class Program

{
public static void Main()
{
Console.WriteLine("Hello World");
}
}

The first line, starting with using, is an import line in C#. We're importing a
library called System. We import code that live in specific "packages" so
that code can be made modular and so that we can load just what our
application needs. You don't need to know where each code is kept; you'll
make lots of mistakes here, importing the wrong thing or not importing the
right thing. Relax. It will improve with practice, but do keep in mind good
IDEs will help you find the right import statements.
Then we have a class called Program. We'll see classes and objects when
I go over object-oriented programming, but for now expect to see them
everywhere in C# and treat them as another form of code block.
The function Main is the starting point of many of the applications you use
in your daily life: iOS apps will start from a main() function, Android apps
the same, ditto for games and apps you run in your computer or game
console. It's a universal way for the underlying operating system to start
running an application: the OS loads the app and calls its Main() function
to get the ball rolling. The function signature will change somewhat, it won't
always be static and it won't always be parameterless. But it's always called
main (or Main). And put the static and public keywords in the back-
burner for now as well, we'll see what they mean later.
The Console.WriteLine() function is a print function in C# . You
can delete that line for now. Instead, let's add the code that waits for user
keyboard input inside the body of Main(). In C# it looks like this:
string value = Console.ReadLine();

The compiler would be able to figure out the type of the variable value is
a string, so we could have written it like this in C# :
var value = Console.ReadLine();

It knows this because Console.ReadLine() returns a string. And yes,

C# is one of the languages still very much attached to semi-colons. You can't
forget to add them at the end of your lines or the "spell-checker" will have a
fit.
Go ahead and type this inside the Main function:
string value = "";

while (true) {

Console.Write("Type something and hit Enter: ");

value += Console.ReadLine();

Console.WriteLine (value);

if (value.Length > 10) {

break;
}
}

I'll bet you can read that code without much trouble despite the different
syntax. In English, it describes something like the following:

Create a variable called value to hold the user string input.

Display the instruction "Type something and hit Enter: " in the console.
We'll concatenate the user input inside the variable, by using the +
operator. Remember that:
value += Console.ReadLine();
//syntactic sugar!

Equals:
value = value + Console.ReadLine();
//and yes, this is a comment in C#

Write the current value to the console.

If the collected string inside value has a length bigger than 10, we
break out of the loop. So we have a way to get out of the program.

We'll loop for as long as we need, gathering user input by first providing a
helpful message telling what we expect the user to do. We append the input
to our variable and we print the complete value to the console. I don't want to
hog the console forever, so I add a condition: if the value length is greater
than ten characters, I break out of the while loop, terminating our program.
With strings, if you recall, we called this appending business "concatenation"
but otherwise it behaves the same way as appending to a collection would. In
C# a string is pretty much a collection of char type values, with char
meaning character.
Let's change this code to serve as our backdoor logic. We need to compare
the input with our password and check for a match:
string password = "JeffJeffityJeff";

And remember, the input string will build up slowly, one character at a
time. If we don't have a match we must clear out our "value" variable and
start building it up again from scratch. This means we need to check for
partial matching results and when this thing fails we must go back to
"listening" for the correct string again, that's how backdoors work. Not unlike
the monkeys typing out a Shakespeare sonnet, the correct pattern may appear
anywhere at any moment. There are a gazillion ways to accomplish this. The
solution I used will very likely not be the one you'll think of first. I'll use a
string helper method similar to the slice operation we saw earlier in Python.
Can you read the code for my solution below? Can you find the slicing
operation? And can you figure out what are the parameters it expects?
string value = "";
string password = "JeffJeffityJeff";

while (true) {

Console.Write("Type Something: ");

value += Console.ReadLine();

if (value != password.Substring(0, value.Length)) {

//we don't have a match, clear out string
value = "";
} else {
if (value.Length == password.Length) {
Console.WriteLine("I'm in!");
break;
 }
}
}

What Python did with [start index of the slice : end

index of the slice ] C# does with Substring (start index
of the slice, end index of the slice). This "slicing"
operation in C# is specific to strings and won't work on lists (collections, like
list, will have their own slicing operation).
My logic is working like this. Every time I concatenate a character to
value I get a slice of the same length from password and compare the
two strings. Let's suppose you typed "Jeffo". That has a length of 5. I get a
slice of length five from my password and get the result "JeffJ". I then
compare "Jeffo" to that slice "JeffJ". Since they're not the same, I clear out
the value and start all over again. If they are the same, meaning I typed
"JeffJ", I check if the two strings, the input, and the password, have the same
length. If they do, it means we have a complete match and we have our
backdoor wide open. Otherwise I keep building my input string.
There is a catch, however. And it has to do with something I've touched on
before: mutability. This is another huge topic in programming, but it affects
some languages more than others. We've been calling "variables" variables
for a reason: they can vary. I know! If they could not vary, then they are often
called values or constants as a way to distinguish the two things. But
mutability extends to more things than just variables. You can have
immutable collections, meaning you can't add or remove anything from them
(like Tuples in Python). And in many languages, like C#, strings are
immutable. It is a common feature in programming languages to consider all
primitive types—strings, numbers and booleans—as immutable. This means
that when you write something like:
var string1 = "Hello ";
string1 += "World";

You're not changing string1 in the second line, you're creating a new
value for string1. As a matter of fact, since strings are immutable, you
should be able to count three strings in those two lines. There is a "Hello "
string, and then the code creates a "World" string and then a third string
which is the result of the concatenation "Hello World". Three distinct strings
that were created in memory, and when we finally settled on one "Hello
World" the other two were told by our program to go poof themselves. This is
fine when we're working with short strings, but if I did:
var string1 = allTheTextThatWasEverWritten;
string1 += allThatWasEverUsedAsAnExcuseNotToDoSomething;

The computer may choke a bit creating those temporary extra strings. And
if you're processing large chunks of data this is likely to occur. Knowing this,
some languages offer a better way to build strings. In C# that is called a
StringBuilder() object. The difference in our code would be minimal.
Check it out:
using System;
using System.Text;

public class Program {

public static void Main() {

StringBuilder value = new StringBuilder();

string password = "JeffJeffityJeff";

while (true) {

Console.Write("Type Something: ");

value.Append(Console.ReadLine());

if (value.ToString() != password.Substring(0, value.Length)) {

value.Clear();
} else {
if (value.Length == password.Length) {
Console.WriteLine("I'm in!");
break;
}
}
}
}
}
 We import the Text library, where StringBuilder resides.
using System.Text;

We make our value an instance of StringBuilder using the handy way

to create instances in C#: the command new.
StringBuilder value = new StringBuilder();

We append the user's input to our string builder.

value.Append(Console.ReadLine());

We turn its contents into a string by calling its .ToString() method and
we use .Clear() to clear the content inside the string builder.
value.ToString();
value.Clear();

I must admit that a StringBuilder object in this application is overkill

since we're dealing with tiny strings, but I thought this was a nice place to
talk about mutability some more.
Go ahead, test the code. Type individual letters followed by the Enter key,
or type the whole thing out and see if you can get in.
In the almost legendary programming book Programming Pearls by Jon
Bentley, the author tells a funny true story involving sub-routines of the sort
we've just coded. A Bank headquartered in Chicago had created a program
for their data processing and distributed this to their branches all over the
world. And the program worked without a hitch for some months but then
there came reports of mysterious "crashes." The program would quit
unexpectedly and the programmers could not figure out what the problem
was; particularly since the program had worked just fine before. After
analyzing the bug reports, the programmers noticed an obvious pattern: all
the unexpected crashes were coming from the Bank's branches in Ecuador.
After some investigation they found the bug. The problem was caused
whenever an employee attempted to insert transactions related to that
country's capital: Quito.
LOL.
 2
What's In A Name?
Just as with numbers, the operations one can perform with strings are very
simple and comprise a relatively shortlist. And yet, one never ceases to find
new applications and new things to create using string operations. Putting
aside the challenge of understanding text the way humans can and produce it
with the same ease, the basic string operations are still: concatenation, finding
an element, and replacing an element.
With concatenation you create a new string by combining multiple strings.
We've done this before. If you ever used a title, or name, or idea generator
online you saw concatenation at its most basic form. I'm sure you've heard
the old joke that if one concatenates the name of their first pet with the name
of the street they grew up on, they end up generating their stripper name.
Google says the most common US street names are:
using System.Collections.Generic;

List<string> streets = new List<string> {

"Second", "Third", "First", "Fourth", "Park", "Fifth", "Main", "Sixth",
};

(Lists in C# exist in the System.Collections.Generic library).

And the most common pet names:
List<string> pets = new List<string> { "Tigger", "Tiger", "Max",
"Smokey", "Sam", "Kitty", "Sassy", "Shadow", "Simba", "Patch",
"Lucky", "Misty", "Sammy", "Princess", "Oreo", "Samantha", "Charlie",
"Boots", "Brandy", "Oliver" };

C# is very strict with types and so you must give its collections what type
you intend to store in them using the <> brackets. And unlike Python, C#
distinguishes between Lists and Arrays. Arrays would be declared as:
int[] numbers = new int[] { 1, 2, 3, 4, 5 };
string[] strings = new string[] { "1","2","3","4","5" };
char[] characters = new char[] { '1','2','3','4','5' };

Arrays are immutable in C#. You cannot append or remove items from an
array. But Lists are mutable:
List<int> numbers = new List<int> { 1, 2, 3, 4, 5 };
List<string> strings = new List<string> { "1","2","3","4","5"};
List<char> characters = new List<char> { '1','2','3','4','5'};

Using a list in C#, you can add and remove elements to your heart's
content. This means you can declare an empty list and fill it up with stuff
later. With Arrays, you can't. You must give the array the number of elements
it will hold if you wish to "fill it up" later:
int[] numbers = new int[5];

You can change the values inside the array to something else, but this array
will only ever hold 5 integers.
Having arrays as immutable collections is a very common pattern in strict
languages, but not so much in so-called dynamic languages. In Python, for
instance, we only have lists, which are mutable. (Python has Tuples and
something called a frozen set for immutable collection types).
And did you notice the single quote for chars?
List<char> characters = new List<char> { '1','2','3','4','5'};

It's how the compiler distinguishes a single character 'a' from a string "a".
For our name generator, we can write a function that concatenates the
words in two separate lists and returns a list of names:
List<string> CreateNames(List<string> l1, List<string> l2) {}

We could write something like the following in the function's body:

List<string> CreateNames(List<string> l1, List<string> l2) {

var result = new List<string>();

var i = 0;
while (i < l1.Count) {
result.Add(string.Format("{0} {1}", l1[i], l2[i]));
 i++;
}
return result;
}

Notice that we must inform what a function returns (in this case, a list of
strings). Some strict languages will be able to inferr even a function return
type so that you can omit it; C# is not one of them. Type rules!
Our string concatenation logic uses the string.Format() method. You
can form a string with place holders, as we saw in Python. By convention the
placeholders are usually represented as {0} {1} {2} ... This will be followed
by the values that will be concatenated replacing the placeholders. Notice we
have a space between {0} and {1} so that we can concatenate a full name
combining the string values for the first and second names. As another
example, we could format emails like this:
string.Format("{0}@{1}.{2}", idValue, domainName, domainType);

Or we could also concatenate with the plus operator:

firstName + " " + secondName;

This would create more strings in memory, however, as we saw.

But did you notice that we might have created a bug with that function?
What if the two lists are not of the same length? We would look for an item
that exists in list one and look for an item at the same index in list two and
not find it. The program would crash and it would throw one of the most
common errors in programming: not finding something you think is there but
isn't. It's called the Null Reference Error and it's the bane of all programmers.
The null reference was invented by Sir Charles Antony Richard Hoare, who
called this his "billion-dollar mistake," based on the assumption that the error
has caused that much money in losses thus far. I think by now that number is
probably an optimistic estimation (but all programmers are optimists!).
Whenever you try to access something that is not there, your program will
crash with a null reference error. This means looking for the sixth element in
a collection containing 5 elements. It means looking for a string value inside
a variable holding a null value. It means expecting a function to return
something when some error caused it to return nothing.
 How to fix this in our function? One way would be to find out which list is
shorter.
List<String> list;
if (l1.Count <= l2.Count)
{
list = l1;
}
else
{
list = l2;
}

That's okay, but a bit ugly isn't it? If statements are not expressions in C#.
They're statements. They don't return a value (expressions do), so I must
declare the list variable at the top and check which value to assign it. If only
if statements were expressions, then we could do this:
List<String> list = l1.Count <= l2.Count { return l1 } else { return
l2 };

But fear not, here's the ternary expression to the rescue:

List<String> list = l1.Count <= l2.Count ? l1 : l2;

It states: is this thing true? if yes, return this value : if not, return this
value;
Is list 1 shorter than or equal to list 2? If so list 1 is the result I want, if not
list 2 is the result I want. Now I can determine the shortest list and loop only
that one.
Most languages support ternary operations. Unless they treat if statements
as expressions, then the ternary operator becomes meaningless. This is the
case with F# as we'll see later.
The code now becomes:
List<string> CreateNames(List<string> l1, List<string> l2) {
var result = new List<string>();
List<String> list = l1.Count <= l2.Count ? l1 : l2;
var i = 0;
while (i < list.Count) {
var fullname = string.Format("{0} {1}", l1[i], l2[i]);
 Console.WriteLine(fullname);
result.Add(fullname);
i++;
}
return result;
}

As a matter of fact, we could have used another higher-order function to

help us in this case (like map and filter), this one known as zip(). It
exists inside one of the best libraries in C#: Linq. But more on this later.
And by the way, do you want to know another common error in
programming? It's what happens if you write:
var i = 0;
while (i < list.Count) {
}

And forget to increment the counter inside the loop. I do this about three
times a week (on a good week). This is called—in the way of unhappy
relationships and visits from relatives— an infinite loop. Your application
won't crash straight away, it will freeze and then crash with the operating
system saying the program is taking too long or has stopped responding.

Okay. We can generate the most common stripper names in the US. But
here's the thing. I once coded an Orc name generator for a game. I followed
the same logic and used a list of Orc names:
List<string> name = new List<string> { "Adlugbuk",
"Azabesh", "Bagamul", "Bazrag", "Brogdul", "Ghamonk","Gruluk",
"Ogar", "Threg"};

The original list was huge and I even found a way to generate these names
dynamically using simple rules and something called a Markov Chain. To
these names, I added a value from a second list; one containing sobriquets
that I decided would be a list of adjective words ending in -ible:
List<string> sobriquet = new List<string>
{ "Irresponsible", "Indestructible", "Terrible", "Inflexible", "Horrible",

The formatted output produced things like, Ogar, The Incompatible. (I had
a good laugh about that one). And then, it got me thinking... Searching online
for more name generators, I found fantasy street names and fantasy pet
names:
List<string> pet = new List<string> { "Chewer", "Aragog",
"Daimon", "Saphira", "Mushu", "Draco", "Kenneth", "Smaug", "Falkor",
"Alfie", "Puff", "Nemesis"};

List<string> street = new List<string> { "Diagon Alley", "Grimmauld

Place", "Spinner End", "Knockturn Alley", "Dragontail Walk", "Broken
Pass", "Jagged Lane", "Forbidden Pass", "Eastern Pass", "Burning
Trail", "Spidersilk Passage", "Shadowy Route", "Forager Track",
"Highway to the Danger Zone"};

By now I'm sure you must be thinking what I was thinking: Yes, we can
generate stripper Orc names! The function would need to strip (pun intended)
the extra words in the street name. Of course, we could have stored the street
names without the extra words but what would be the fun in that? So before
calling the createNames() function, we first need to strip the street name
of extra words (pun intended deux).
var firstStreetName = street.Select (item => item.Split(' ')[0]);

CreateNames(pet, firstStreetName);

That's the C# map function, which is called Select(). The reason for
that name, I suppose, is because Select() makes one think of the
filter() function and that people who build programming languages are
unnecessarily cruel. Whatever. Their map() function is called Select()
and their filter() function is called Where(). The German word for
Poison is Gift, so there are worse things than calling the map() function
Select().
I run the program and... Yes! I just found out that Puff Jagged is an Orc
stripper name. This book is paying for itself!

In the real world, you'd want to be able to process very large chunks of
strings, and embedding these in your code does not seem like a good solution.
Luckily, programming languages offer two libraries that can help us with
that. One that exists under the umbrella term IO, for input-output, and one
that exists under the term Request (or URLRequest). The first can load files
from a path in your computer or network, and the other can make a request
for a file through an internet server via an URL. We can't test these libraries
in online consoles because they are forbidden to run in web browsers for
security reasons, but we can use them in our applications running inside our
own editors. If you wish to run code from one such editor, I have instructions
for this at the end of the book. But for now, it's okay to just read the code and
use it as a reference later.
You could load a text file called myFile.txt which is sitting in your desktop
like this:
using System.IO;

string path =
Environment.GetFolderPath(Environment.SpecialFolder.Desktop);

string s = File.ReadAllText(path + "/myFile.txt");

And we can load the text inside a webpage like this:

using System.Net;

string s;

using (WebClient client = new WebClient()) {

s =
client.DownloadString("http://someURL.com/hopefullyNotPorn/verylikelyPorn.html");
}

The using block is a C# thing. You could skip it and do it like this:
string s = client.DownloadString("http://url");

But if something goes wrong, the using block will clear up the mess for
you, close shop, and bury the bodies. IO and Requests are where messiness
lives. Everything and anything can go wrong when working with files and
web requests. Nothing frightening, just annoying. It's definitely the glass half
empty side of programming.
You probably noticed in those few lines an explosion of new things, new
built-in commands and properties, and keywords. I don't want you to feel
discouraged. My reaction to code like this is exactly the same as yours. This
is what's known as an API (Application Program Interface). They are
libraries detailing how every single operation must be done in order to arrive
at a certain desired result and the naming conventions and logic used will be
entirely up to the people who created the API. It's Feynman's complaint about
how things are wrongly named all over again, multiplied by 1000.
"Industrial-strength" languages like C#, Java, and Swift feel sometimes like
books of rules. You must dance to their tune or else nothing will work. But
there is space for creativity in these languages, even if the API creators may
twist their noses at the way we choose to do things. They're not the boss of
us! So yes, sadly there will be seemingly nonsensical code like:
Environment.GetFolderPath (Environment.SpecialFolder.Desktop);

We simply need to Google it when we need it: "how I find the desktop
folder in C# ?". I don't waste my time memorizing crap like this and neither
should you; unless I've used it enough times to have it branded in my brain,
which is its own form of sadness. Although to be fair, the people who created
this tried their best to be meaningful and flexible and you cannot fault them
for that. Sometimes we do need to find files on the desktop. And not all files
will be placed on the desktop. Therefore, there will be more "special folders"
and one imagines an enormous number of helper methods related to whatever
"Environment" means. But as I said, you don't need to memorize any of this.
This is code you get to when needs must.
What can I do with my newfound power of loading chunks of text? I know.
I could load all Sherlock Holmes stories like this:
using System.Net;

string s;

using (WebClient client = new WebClient()) {

s = client.DownloadString ("http://sherlock-
holm.es/stories/html/cano.html");
}

Assuming of course that URL still exists. If I have the text saved in my
desktop, and I do!, I could load it like this:
string path = Environment.GetFolderPath
(Environment.SpecialFolder.Desktop);
string s = File.ReadAllText(path + "/sherlock.txt");

I need to check if I have a result from the loading operation:

if (!string.IsNullOrEmpty(s)) {
//do something with the text in this block
}

The exclamation point at the beginning of a boolean means NOT.

string.IsNullOrEmpty(s) will return true if the string is either null
or empty. With the exclamation point we can write instead: if NOT null or
empty.
if (!string.IsNullOrEmpty(s)) {}

Or we could have done it this way:

if ( string.IsNullOrEmpty(s) == false ) {
}

So we have a string containing all Sherlock Holmes stories. What do we do

next? I could change the text to one case so it's easier to find matches for
searches:
s = s.ToLower();

I won't have to bother typing my search queries with the proper sequence
of upper and lower case characters and simply use lowercase for everything.
And now I could count the number of times a string appears in the text. I
can do this in a number of ways. For instance, I could Split:
var data = s.Split( new string[] {"my dear watson"} ,
StringSplitOptions.None);

C# Split() method is said to be overloaded. This means there are many

versions of this method, using different arguments. I can split on a char for
instance, or an array of chars and an array of strings... So I could split on a
space char Split(' ') and get the individual words in the text. Or I could
split on a sentence passing a string array plus some extra optional value:
Use StringSplitOptions.None for no extra toppings. Use
StringSplitOptions.RemoveEmptyEntries to remove empty
values from the resulting array. If the text contained somewhere two spaces
" " for instance, the split would do its thing and create a null value in-
between these spaces. StringSplitOptions.RemoveEmptyEntries
gets rid of those.
Counting occurrences using splits will return true result + 1. Splitting the
entire text on the string "my dear watson" returns an array with 93 length,
meaning that string occurs 92 times in the text. Wait, what? If I split the
sentence "my dear watson" on the word "dear" I get back an array with two
elements: "my " and " watson" and therefore I have a total of one "dear" in
the sentence. Result length - 1 tells me how many instances of "dear" I have.
If the split string I'm using is not found anywhere in the text, we get an
array with one element: The whole text. And since result length - 1 gives me
the total count, it means I have found 0 matches.
So either this sentence:
var data = s.Split(new string[] { "elementary, my dear watson" },
StringSplitOptions.None);

Or this:
var data = s.Split(new string[] { "elementary my dear watson" },
StringSplitOptions.None);

Will return Length 1. Meaning, as you probably know, Sherlock Holmes

never said it. Not in the books anyway. He did say, however:
var data = s.Split(new string[] { "simplicity itself" },
StringSplitOptions.None);

A total of seven times. And the word elementary is used 8 times but not
always said by Holmes. And if you count the number of times this is said:
var data = s.Split(new string[] { "ejaculat" },
StringSplitOptions.None);

You get 23 instances, covering "ejaculation", "ejaculations" and

"ejaculated". These, almost always, taking place inside 221B (mentioned 6
times) Baker Street (mentioned 120 times). This leads us to conclude that
Mrs. Hudson (32 times) whose job was to clean 221B, Baker Street (once
without the comma and five times with it) was not paid nearly enough. Bless
her heart.
You can also search for things using string.IndexOf(), but it won't
give you the number of times something appears in the text. For instance,
this:
Console.WriteLine(s.IndexOf("221b"));

Returns 15590, which stands for the char index in the array containing the
entire Sherlock Holmes canon where "221b" appears for the first time, which
I thought quite high until I verified it and yes, we first hear of the address on
the second chapter of Study in Scarlet, where, incidentally, most if not all the
mentions to "221B, Baker Street" appear. Later, the reference drops to state
simply "Baker Street".
Conan Doyle was notoriously bad at remembering details. In early versions
of the stories Watson goes from a John to a James. And despite Holmes being
the greatest consulting detective in the world, it simply flew past him the fact
his roommate started with a war wound to his shoulder, and then it later
moved to his leg. But that's cocaine for ya! (Cocaine appears 9 times in the
text, seven-per-cent solution appears only once, so I guess the dosage
changed a bit, eh Holmes?)
Now, say you want to spell-check your writing. Or let's say you want to
highlight passive verbs or adverbs or cliches in your writing. This is how you
do it. You load a list of the things you want to search for and then write the
code that does it with a combination of split and index. If you want to write
an E-Prime text editor, writing English without the verb to be, you'll need a
list containing all forms of the verb to be:
List<string> toBe = new List<string> { "is", "am", "are", "was",
"were", "isn't, "wasn't" ... };

You split the whole text using a space char to get at the words and then
loop this collection to see if any of the words are contained in the toBe list.
That easy.

You probably wondered, when we were generating stripper names, that we

should have a way to match the name lists randomly instead of using a loop.
And you'd be right! Though not something specific to strings, randomness is
itself a big concept and quite complex. To put it mildly, randomness is weird.
Problems start with the very definition of what makes something truly
random. For instance, when you shuffle a playlist you're using pseudo-
randomness, also known as "not random at all!" Because random means
anything. And if you start adding rules to what "anything" means you don't
have random anymore, because you don't have "anything goes" anymore.
When you shuffle a playlist you are starting with a finite number of things to
shuffle and they can't repeat, meaning the songs can't appear more than once
in the list. That's too many rules! A truly random playlist would look like:
"Royals by Lorde", "banana", "pants", 1, a bit of string, "Royals by Lorde",
"Royals by Lorde"
And I don't even like that song.
Humans are terrible at randomness. A fact that can help us to catch
cheaters. We can find out if a human being has been fiddling with results in
say: tests, budgets, financial reports... by evaluating their randomness. You
give a series of numbers like 1234 and ask a human being to randomly
shuffle it and the human, bless him, would try his hardest to get something as
different from the original as possible. A human cannot accept that 1234
would be a valid random shuffle result for 1234. Another thing that helped
crack Enigma in WWII was that the Nazis could not let an A stand for and A
in the code generated by the Enigma machine (or B for a B, C for a C...). It
made them feel icky inside, unlike all the murders they committed.
Usually, when working with random numbers in code, you start by creating
a random number generator. This is also a pseudo-random number generator
because it's hard to prove it isn't. The algorithm used to generate them will
work within rules and limitations and patterns. It's hard to prove that an
algorithm that produces randomness can produce "anything".
var rnd = new Random();

This is a random number generator. You can ask the generator for a
random integer:
rnd.Next();

or a double (a big float):

rnd.NextDouble();

You can ask for a number up to another number:

rnd.Next(10);

This will pick an integer between 0 and 9.

And yes, we can test how long a monkey would take to type these words:
var list = new List<string>() { "or", "to", "to", "not", "be", "be"
};

In the correct Shakespearean order:

var rnd = new Random();
var correct = "to be or not to be";
var i = 1;

while (i <= 10000) {

var list = new List<string>() {

"or", "to", "to", "not", "be", "be"
};
var sentence = new List<string>();

while (list.Count > 0) {

var index = rnd.Next(list.Count);
var item = list[index];
sentence.Add(item);
list.RemoveAt(index);
}

var result = string.Join(" ", sentence);

if (result == correct) {
Console.WriteLine(i);
break;
}
i++;
}

I use a cap of 10000 loops for our "attempts" so we don't get stuck here.
The code will try up to ten thousand times to randomly shuffle the words and
form the sentence "to be or not to be". We have a loop inside another loop.
The second just pops words out of the List randomly and builds a sentence (a
second list).
This part:
var index = rnd.Next(list.Count);
var item = list[index];
list.RemoveAt(index);

Gets a random index in the list, and then takes the item out of the list at that
index. I use string.Join() to turn the result list into a proper sentence.
If the result matches the correct form, I print the number of times it took to
accomplish that and break out of the loop. The result ranged from 20 to 550
just a few times I ran this thing.
Notice the silly human in me when I coded this:
new List<string>() { "or", "to", "to", "not", "be", "be" };

I "pre-shuffled" the list. Awwww. I don't have to since the items are
popped out of the list randomly. Randomness on top of randomness is not
twice randomness. Nothing can be said to be "more random". But see how
randomness plays tricks on us? Or maybe it's just me. I'm a dummy.
If we complicate the sentence even a little:
var list = new List<string>() { "to", "be", "or", "not",
"to", "be,", "that", "is", "the", "question" };

By adding more words and now making "be" no longer interchangeable—

one has a comma now and the other hasn't—we can't solve the thing under
10.000 attempts any more. We need a million attempts now and even then,
most of the time, we don't get any result at all.
var correct = "to be or not to be, that is the question";
var rnd = new Random();
var i = 1;

while (i <= 1000000) {

var list = new List<string>() {

"to", "be", "or", "not", "to", "be,",
"that", "is", "the", "question" };
 var sentence = new List<string>();
while (list.Count > 0) {
var index = rnd.Next(list.Count);
var item = list[index];
sentence.Add(item);
list.RemoveAt(index);
}
var result = string.Join(" ", sentence);
if (result == correct) {
Console.WriteLine(i);
break;
}
i++;
}

You could write the loop as:

while (true) {
...
}

And then go make some tea and who knows what will happen... Those
damn dirty apes!
As an exercise, change the Orc stripper name generator to match names
randomly.

If you ever watched Kim Jung Gi drawing videos on YouTube, you'll

understand when I say Ken Thompson is the Kim Jung Gi of programming.
And one of the things he invented—as if it was nothing much, you know, just
messing about—was Regular Expressions. It's behind every machine-
processed attempt at "understanding" text, every search query you type, every
spelling mistake caught by your spell-checker, and possibly every strange
thing an AI says. (InspiroBot at inspiroBot.me just told me: "Distributing a
Franchise is Strange," and asked me if I wanted to pay for a poster with that
on it. Would I!)
I won't lie to you. Regular Expression will probably fit most of your earlier
expectations of what programming looks like. If you ever saw how children
comic books represent swear words, you basically saw a Regular Expression.
The internet just told me those things are called Grawlixes: "a character or
series of characters that often appear in place of profanity". But here we'll call
them patterns. But I kid you not: Regular Expressions are just about the
coolest thing computers can do.
Ok, maybe it's just me. I mean, take it from a guy who likes coding orc
stripper name generators.
The idea is remarkably simple. You want to search the word "Grawlix" in a
text. Nothing could be simpler right? You know how to do it already. But
what if you want to search for words that begin with a "g", has a "w"
somewhere in the middle, and ends with an "x"? What if you wanted your
text to have no punctuation, just words? What if you wanted to code your
own Markdown editor, suiting your own crazy needs? Or your own
programming language?
Yes, the answer is Regular Expression. In fact, most compilers use Regular
Expressions to help turn code into machine-readable gunk. Once you learn it,
you acquire a new respect for programming syntax and understand the reason
behind the parentheses and commas and semi-colons... How else would you
identify where the arguments being passed to a function are, for example? Or
how to separate the individual instructions? Unless you use symbols to mark
the boundaries of where a function name ends and an argument list begins,
and where an instruction ends and the next begins...
I could write an entire book about it. But I won't lie. It does look weird.
Here's a small, very small, introduction.
using System.Text.RegularExpressions;

string stringInput = "Who put the bomp in the bomp bah bomp bah bomp?
\nWho put the ram in the rama lama ding dong?\nWho put the bop in the
bop shoo bop shoo bop?\nWho put the dip in the dip da dip da dip?";

Note: \n stands for newline.

I can create a pattern like this:

string s_out = Regex.Replace(stringInput, @"..m[^\s]", "thing");

I use the @ symbol before the string to denote this is a string literal, or in
other words, any so-called escape characters can be treated as a character and
not a escape instruction. An escape character is a way to insert characters that
could be otherwise confusing to a program. Like a string containing quotation
marks: " "hey!" said he". We have to escape them like this: "\"hey!\"
said he."
That pattern in the code is trying to match the words: bomp, rama, lama,
and replace them with the word "thing". Can you try to guess what each
symbol in the pattern means based on that? Nah, probably not. It's saying:
@"..m[^\s]"

I want to match something that has two of any characters .. (a dot is "any
character", including spaces), followed by an m and one more character which
is not a space (^ means not and \s means space). The brackets in [^\s]
may signify what the parentheses do in 2 * (5 + 2). It represents an isolated
unit inside the pattern so that things don't get even more confusing! It can
also represent a set or range of characters. If you want to find words that
contain any character listed in the set [abceo] for instance. Or the range
[a-z0-9].
Regular Expressions are ridiculously fast. And no wonder, since they were
written back in the day candles were faster than computers. You can pump a
lot of text through a pattern and it will run matches through the whole thing
like it's nobody's business. This pattern returns the string:

Who put the thing in the thing bah thing bah thing? Who put the
ram in the thing thing ding dong? Who put the bop in the bop shoo
bop shoo bop? Who put the dip in the dip da dip da dip?

Which, as it is now, is already the theme song for Regular Expressions as

far as I'm concerned. But we can make it even better:
s_out = Regex.Replace(s_out, @"\b..p", "what");

The pattern now says: look for a word that begins with two characters (\b
means the following pattern will come immediately at the beginning of each
word), followed by a p. I could also state the word must end there and use a
\z at the end, or possibly another \b which stands for word "boundary" and
not really just "beginning".
This pattern can target: bop and dip, returning us this poetic beauty:
 Who put the thing in the thing bah thing bah thing? Who put the
ram in the thing thing ding dong? Who put the what in the what shoo
what shoo what? Who put the what in the what da what da what?

Oh, man. A hit, a very palpable hit.

And there are so many ways to use them! Regular Expressions are the best
way to determine if a telephone number, email, date of birth, or credit card
number a user typed in a form are valid or not. All the programmer needs to
do is run them through specific patterns and see if the input conforms to
them. And you don't need complicated patterns either to make Regular
Expressions useful. You could have an array of pointless, weak words like:
var pointless = new List<string> { "very", "some", "always" , "there
is", "there are", ... };

And then loop them to mark useless words in your writing, surrounding
them with **, for instance:
foreach ( var word in pointless) {
myAmazingNovel = Regex.Replace (myAmazingNovel,
@"\b"+word+@"\b", "**"+word+"**");
}

Boom. Done. All you'd need now is to review tagged words and see which
ones you want to cut and become a best-seller author.
Patterns are particularly useful if the thing being searched can take many
forms. Say, for instance, we're searching for the cliche ...and that is all she
wrote. We got it from a list of cliche expressions we loaded from a file and
that we are trying to remove from our text. But that cliche may exist as "and
that's all she wrote", "that is all she wrote" and "that's all she wrote". We
could list all variations in our file, Regular Expressions are fast enough to
allow this. Or we could search for all those instances with one pattern. A
hellishly complicated one, to be sure, but still, we could do it!
[A-Za-z]+|['s]|[ is]+ all she wrote

This would remove:

That's all she wrote

and that's all she wrote

and that is all she wrote

that is all she wrote

Unless programmers use Regular Expression daily, they too will need a
cheat-sheet of commands before they attempt to do anything with it. This will
involve writing a few test scripts for each pattern you build-up for a particular
purpose. That, incidentally, mirrors a lot of what programming is like in
general. Nothing comes out ready to be used unless you're Ken Thompson.
You write little tests, printing results to the console to see if your logic is
working properly. It took me 15 minutes to figure out how to get rid of "and
that's all she wrote" and I'm sure my resulting pattern is still crap.
Regex, as I said, is supported by pretty much every language and the
syntax and commands may change slightly. Programmers who have to solve
a problem through regular expressions will search online for cheat-sheets,
listing all commands for a specific language.
Regular Expressions are cool.
**And that's all she wrote!** At least until the next page.
 3
Sell you for Scraps
What I'm going to talk about in this chapter exists within a spectrum
ranging from "OK" to "no, no, no, don't do that!" It's one of those things in
programming that most people can put to good use and yet the temptation to
abuse it is quite strong. It's called Web Scraping and it mainly involves
creating bots to grab information from web-pages. The things finding out
your email account on your web page or posting strange comments in your
blog ("yes, this sir is best content for time, eyes blind with wisdom of words!
want to buy a sneaker?"). Those are web scraping bots. Or one of those
Chrome plug-ins that downloads all the images from a web-page that match a
certain size of extension. (Because someone built a bot to batch download
images from web-pages but by God, they didn't want to waste time with
thumbnails and JPGs!) Some bots will retrieve specific content or download
it. Some will find forms and buttons and play havoc with them.
Another way to think of web scraping is to imagine you've built your own
browser in the console. One that exists inside your command line, parses
HTML information just like any browser would but does not waste time with
things you're not interested in. Oh yes, and it does all this in memory. And
that's cool, right? Well... sort of. If someone took the time and effort to bring
you content and expects you to see the silly ads on their pages because that's
the one way they get paid for their work then web scraping borders on the not
so cool. There are bad bots out there, unethical and immoral bots, and unless
your name rhymes with Shushmir Futtin you might want to skip building
more of those.
Let me give you a few interesting examples as a guide. I love learning new
languages (the ones people use to talk to one another) and whenever I'm
learning a new language it's guaranteed I'll need to use dictionary sites quite a
bit. There are freely available libraries you can use for that, Google's
Translate is one of them. But dictionary sites can give you definition and
examples of the words being used in sentences—and sometimes they provide
you with mp3 files to help with pronunciation. You can build a web scraping
tool that would load the dictionary page inside the console and grab the
information you want, skipping the browser altogether. But do keep in mind
that the site wants you to see their ads, so a visit every now and then wouldn't
go amiss. What is not cool is to batch process 5000 words inside a loop. For
that sort of thing, you need to find out the website's policies on web scraping.
And besides, what the hell are you using the data for? It better not be for
commercial use! Those websites probably sell their services and content for
commercial use. Still, you'd be surprised how much data is available for free,
if you promise not to cash in on it. Maps, movie databases, weather
forecasts... You will find public API freely providing you with data like this
if you need them.
If I made it sound like web scraping is sleazy as hell, I apologize. It has
many, many uses and many, many of them are quite decent. But if Shushmir
Futtin had a ruble for every time web-scraping was used for evil, he'd be a
very rich unscrupulous man with a botox face.
Web-scraping is usually accomplished through a dedicated library. Python
has one of the best ones called Beautiful Soup. Some of these libraries are not
free, some have enterprise versions but are free for limited use. It varies a lot.
They do proper bot stuff, they can perform actions on a web-page and wait
for the response before grabbing the data you want. But here, we'll code the
old school web scraping. To understand how it works, you need to learn first
a little bit about a famous DSL (Domain Specific Language) called HTML.
HTML is a computer language, yes I said it! But one used for a very
specific purpose: the creation of documents. It structures a document through
the use of tags <> creating trees. Rather like outlines.
<root>
<element1>
<element2>
<element3>
<element3.1>
<element3.2>
</element 3>
</root>

You can open and close tags with the <> and </> format and so clearly
state parent-child relationships between the tags. You can also create
different instructions or contexts for these tags by adding keywords to them
<a> <b> <i> <ul> <p> and so on. Some of the tags will create
containers, wrapping more tags inside them, forming nodes and branches in a
tree-like structure. Others will help format the content. You can also think of
these trees as a series of nested arrays:
[
[],
[
[],
[],
[]
],
[]
];

And that's where the web-scraping libraries really shine. They can map
HTML trees to collections you can loop through in your code.
We'll code a web-scraper that grabs information from a Dictionary site:
https://www.linguee.com/. This particular site does not have ads, and its terms
and conditions state their service is free to use for private and business use.
They do however reserve the right to change this in the future. This does not
mean you can create a bot and download all the data they've put together,
putting stress on their servers. But they're cool with the basics. For now. This
all may have changed by the time you're reading this. If so, you can follow
the steps by finding another dictionary web site with friendly terms.
Don't be a dick.
We start with some investigation. In your browser, load the dictionary site,
select the language translation of your choice, and type a word you know
exists in that language. I picked the German-English route and typed
Gesundheit and made sure I picked the German translation. This will give me
a URL that looks like this, with the queried word at the end of the URL:
https://www.linguee.com/german-english/translation/Gesundheit.html

So I know that if I want to translate the word Schweinehund, I can create a

neat little string in my code using basic concatenation in order to get the new
URL:
https://www.linguee.com/german-english/translation/Schweinehund.html

It's important to see how the website reacts to a word it does not have a
definition for. For instance, I typed schadefreuen instead of schadenfreude
and I got an error. The page said:
No results for “schadefreuen”.

Cool. We're halfway done with our investigation. Next we need to load a
definition. Let's go back to the Gesundheit page result in our browser. We
highlight the definition word where it first appears on the page, in this
example the word health. We right-click with the mouse and select Inspect in
the dialogue box (this may change in your browser). This will show us these
tags in the HTML tree:
<a id="dictEntry10000208226" href="/english-
german/translation/health.html" class="dictLink featured">health</a>

We want to scrape the "health" word out of the HTML. We also want to
scrape the examples, so repeating the previous steps, targeting the example
sentences now, we isolate the tags as:
<span class="tag_s">Spazieren gehen ist gut für die Gesundheit.
</span>

<span class="tag_t">Walking is good for your health.</span>

Now, we're ready to proceed. We'll basically use the same logic we used
when searching for words in the Sherlock Holmes' novels. We'll put the
keyword we're searching for in a variable:
var word = "Gesundheit";

Load the HTML page as a string in memory, using the WebClient

library (this too won't work in an online console):
using System.Net;

string htmlString;

using (WebClient client = new WebClient()) {

htmlString = client.DownloadString
("https://www.linguee.com/german-english/translation/"+ word
+".html");
}

Notice how the URL gets concatenated with the search word.
We search for the string No results for in our returned string because that's
how the site informs us of an error (or no match).
var haveResult = htmlString.IndexOf("No results for") == -1;

If IndexOf() returns a -1, it means the string you're searching for does
not exist. So if we have a value that is anything other than -1, we have no
results from this word.
if (haveResult == true) {

//Now we can search for our

//content within this block.
}

I chose to split the HTML string on class='dictLink featured'>.

If you notice the way the result is presented in the tree, every translation is
wrapped in this HTML instruction:
class='dictLink featured'>health</a>

So if I split the string on class='dictLink featured'> I'd have

the translation listed as the very next element in most of the resulting array's
indexes. Think of it like this, say our split string is &, and we'll use it on the
following string:
The Beatles where &Paul, &John, &George and &Ringo.

When I split on & I get the array:

["The Beatles where ","Paul", ","John, ", "George and ", "Ringo."];

And because my split string & is attached to the beginning of the data I
want, in this case the names of each Beatle, I know I can skip the first
element in the resulting array ("The Beatles where "), and grab the names
from each subsequent element. If instead, I split on a comma, I'd get this as a
result:
["The Beatles where &Paul", "&John", "&George and &Ringo"];
 I'd have a bit more difficulty parsing the results to get what I want: the
names Paul, John, George, and Ringo.
So getting back to our huge HTML string. By looking for very specific
notations and patterns that I know (or guess) must be attached to the
information I want, I can split and pin-point the information with some
accuracy. If I'm wrong about the split string I chose, I'll know very soon.
if (haveResult == true) {
/*
We split the string, taking care to escape all quotation marks
that may appear inside the string or else the code will throw errors
with the excess of quotation marks.
*/

var data = htmlString.Split(new string[] { "class='dictLink

featured'>"}, StringSplitOptions.None).ToList();

/*
We remove the first item, as we did with the Beatles, since we
don't have any useful data there:
*/

data.RemoveAt(0);

/*
This is why I turned the result split array into a List with
.ToList(); It's easier to remove items from Lists in C# since they're
mutable.

Now I can loop the remaining List of results.

*/

foreach (var result in data) {

/*
We need to extract the translation and we know it ends
with an HTML tag: health</a>. So we can substring the result and
print it to the console for now:
*/

Console.WriteLine(result.Substring(0, result.IndexOf("
</a>") ) );

/*
I could have used .IndexOf("<"); and it would have worked
too. The substring starts at index 0, and "slices" the string up to
the index where </a> is found. So it takes:

health</a>

and returns:

health
*/
}

Note: If the HTML tag contains single quotes, you don't need to
escape them when writing them in C# inside double quoted strings:
"class='dictLink featured'>word</a>"

This will print out:

health

Bless you!

Gesundheit!

If you want the sentence examples, you must repeat the same steps using
the split strings <span class='tag_s'> and <span
class='tag_t'> respectively for the German and the translated
sentences. This will give you:

Spazieren gehen ist gut für die Gesundheit.

Diese Studie zeigt einen Zusammenhang zwischen Einkommen und

Gesundheit.

Eine gute Ernährung ist vorteilhaft für die Gesundheit.

Gesundheit! Bist du erkältet?

Walking is good for your health.

This study shows a correlation between income and health.

A good diet is beneficial to health.

Bless you! Do you have a cold?

So simple and yet so helpful. But do be nice about this.

As an exercise, can you run the string searches using Regular Expressions?
They can simplify the process even more. You can use the Replace()
function along with a neat little pattern to clear the results of any HTML tags,
or better yet use something called groups:
var s = "<span class='tag_t'>translation</span>";
var matches = Regex.Matches(s, @"<span class='tag_t'>(.*?)</span>");

if (matches.Count > 0) {
foreach (var m in matches) {
Console.WriteLine("Word: {0}", m.Groups[1]);
}
}

This code uses the Matches() function that returns a

MatchCollection with all matched results. Each result contains a group.
Anything you wrap inside parentheses in your pattern can be "tokenized" in
the result as an individual group. Meaning, you can retrieve exactly what was
matched by the pattern described inside the parentheses. And what is that
pattern in this example? A dot (.) means any character as I've said before. *
means match the previous instruction 0 or more times; so here it means match
any character zero or more times. The ? is optional in this case but it makes
the pattern not greedy, and this has to do with how much stuff gets grabbed
after the match is identified. The code will essentially return whatever is
inside those two tags, in this case the word: translation.
But do be nice about how you use this. Remember what uncle Ben told
Peter Parker.
 4
Reading is For Champions
One of the biggest challenges faced by books like this is the difficulty in
showing how solutions were arrived at, with every in-between step and
logical cul-de-sacs perfectly detailed, all the infinite loops and redundant if
statements... You know. The fun times. And then there's the infernal reality
that people have brains of their own and what seems like a good idea inside
yours does not translate well inside others. I wanted this book to be about
your specificity, not mine. Expressing things your way and finding your own
solution to problems is far more valid at this stage than anything I can teach
you. But I can't make the code in this book specific to you and to how you
think. And so it goes...
In this chapter, we'll go through the development of a proper application.
One you can actually use and change to fit your needs. An application that
can potentially make you a better person! Yay! Well, sort of.
I cannot escape the fact that I will solve problems my way, but I can show
you the most common strategies programmers use to solve things. Later,
when you try to do something that matters to you and you face an empty
screen, take a deep breath, and follow the strategies I'll show you in this
chapter.
The application we'll build is a speed reader trainer. It will run on the
console and it can actually teach you to read faster. It works like this:

You feed the program the text you want to read.

The program splits the text into words.
It then displays one word at the beginning of the line, and the next word
at the end of the line.
It also displays a dot in the middle where you should try to focus your
eyes and train yourself to read the words using your peripheral vision.
As the text progresses, we add words to each line. This can be done
 automatically inside a timer or you can add keyboard input to determine
when a line is shown and when more words are added to the line. This is
where your specificity will come in handy.

The most successful way to code something is to get dummy data and test
each way this data needs to be manipulated by your program through separate
tiny functions in order to achieve the results you're aiming at. Breaking the
whole into tiny bits you can test quickly, iterate through, and improve as you
identify errors or edge cases you haven't foreseen. It would go something like
this, ready?
Our dummy data is a string:
var text = "The quick brown fox jumps over the lazy dog";

We need this as a list of words so we can pop individual words out.

var words = text.Split(' ').ToList();

We need to display the first word at the beginning of a line, printing it to

the console. We write a quick test:
var word = words[0];
words.RemoveAt(0);
Console.WriteLine(word);

But we need to display the second word at the end of the line and place a
dot in the middle. We'll repeat this step with each pair of words, so it makes
sense to create a function to handle the printing. We could do something like:
void ShowWords (string word1, string word2) {
Console.WriteLine(
word1 + " . " + word2
);
}

var word1 = words[0];

words.RemoveAt(0);

var word2 = words[0];

words.RemoveAt(0);

ShowWords(word1, word2);
 And now things get interesting. First of all, we're repeating a lot of code to
get words out of our List. Secondly, based on our description of the app, at
some point we'll display two words at the beginning and two words at the end
of the line. And then three, and then four, and maybe more. Thirdly, the space
we have to display the words is finite, at one point we won't be able to place
all the words we wish inside the same line. And finally, there's the strange
way we're creating the line. That's wrong right? The dot will shift if we do
things like that because the words will have different lengths:
The . quick

brown . fox

jumps . over

the . lazy

dog .

That's not good. The dot needs to appear in the center. Our eyes need to
focus on the same spot, that's the whole point of the exercise.
So now we know we'll need to be smart about our parameters and functions
so that our application can handle all the different conditions:

It should allow for a variable number of words displayed per line.

It should adjust somehow to the case when the total words we want to
display in one line reaches a length greater than the space we have
available for them.
And it should keep the damn dot in the middle of the line.

And all this so that our result will look like this:
The . quick
brown . fox
jumps . over
the . lazy
dog .

Do you have to know all the problems beforehand? Nope. This is where the
tiny tests will help. I didn't figure out the problem with the shifty dot until I
coded a few tests, and then I slapped my forehead. I didn't figure out the
problem with running out of line space until I did some tests and then slapped
my forehead again. My forehead was stinging by the time I finished this.
One thing at a time...
Even though the total space before and after the dot changes between lines
—depending on the length of each of the words—the total length of the line
must remain the same. We must "justify" the lines, keeping the dot in the
middle. This is where programming books start to cheat, in my opinion, and
attach their "thinking" to a specific language and how it can solve things.
They'll make solutions appear out of thin air using ready-made functions. I
know C# has a helper method that can handle exactly what we need as far as
placing the dot smack in the middle, but this won't help you if you decide to
use a language that does not have that particular helper method. So let's go
over the logic through pseudo-code first. We have:
var lineLength = x

var dotPosition = lineLength / 2

We must make the words fit within half a length of the line. Imagine half
the line looked like this:
-------------------------

In order to fit the word "brown", I can't do this:

-------------------------
brown-------------------------

I can't "push" the dashes forwards when placing the word, I must "replace"
the dashes with the letters:
-------------------------
brown--------------------

So that the total number of "places" in the line remains the same.
One other thing. One of the principles in programming, if you remember, is
to keep it simple. I don't want to bother with x/2 for the dot position. Instead
of storing how long the line is, we'll store how long half a line is:
var halfLineLength = 30;
 And to make things even simpler, we'll make a whole line be (2 *
halfLineLength) + 1, or 61 in this example and not 60. Why? Because it will
be easier to concatenate the dot in the middle when we create a full line:
halfLine + dot + halfLine

I know that 30 is not half of 61, but things do get simpler if we pretend it
is. Remember, don't make work for yourself in programming.
We now realize the most important function we need in our program is the
one that places the words inside the line spaces, replacing the spaces, and not
shoving them aside. This is what the C# built-in function I've mentioned
does. But we could implement it ourselves. Here's one way:
string AddWordToBeginningOfLine (string word) {
var result = word;
while (result.length < halfLineLength) {
result += " ";
}
return result;
}

Add the word first to your result string and then append spaces until the
whole string length matches our halfLineLength value. We probably
should have used a StringBuilder object, but I just wanted to show you
how you could implement this function. We'd need another function to add
the word to the end of the line, however:
string AddWordToEndOfLine (string word) {
var result = word;
while (result.length < halfLineLength) {
result = " " + result;
}
return result;
}

A tiny difference in the way we concatenate the result string, making sure
the word appears at the end.
But what if the word is longer than our half-line length? As the logic
stands, the functions would return the word but that doesn't help us. What we
have here is an edge case we need to handle. We'll do that soon, but for now,
here are the C# built-in functions I talked about:
word.PadRight(halfLineLength);
word.PadLeft(halfLineLength);

They do the exact same thing our two functions do, they pad the text with
spaces until it matches a given length. One does this to the right of the word,
and the other to the left.
Let's go back to the beginning and code the functions necessary to create
one line, and this time we'll consider all different scenarios and code logic to
support them.
We have our half-line length:
var halfLineLength = 30;

And since we want to support increasing the number of words we display

inside half a line, let's store that in a variable. We start with one word:
var numWords = 1;

Let's work on the function that grabs each word:

var text = "The quick brown fox jumps over the lazy dog";
var words = text.Split(' ').ToList();

string GetWordsForHalfLine () {
var lineWords = words.GetRange(0, numWords);
words.RemoveRange(0, numWords);
return string.Join(" ", lineWords);
}

I've used a C# List helper method called List.GetRange() which

takes an index and a total count and behaves like the slicing operation we saw
in Python. We can also remove multiple items using
List.RemoveRange() which also acts as a slicing operation, but this one
pops things out of the original List. And we finish by recreating a proper
sentence, with spaces between words, using string.Join().
But we have a bug in that code. And if we review the last line of text in our
little example we might identify the problem:
the . lazy
dog .

We run out of words eventually. That's life. The last half-line might be
empty. And according to my logic, if the words list only has this in its final
iteration:
var words = List<string> { "dog" };

And let's pretend numWords has a value of 2. Then we won't be able to

fulfill this:
var lineWords = words.GetRange(0, numWords);

words has one item, and we're grabbing two. And kaboom. We're looking
for something that isn't there.
Again, does this mean you need to figure out all these problems before you
code your programs? Nah. Things will go wrong. And then you'll fix them.
There are a lot "Oh, yes, of course, I forgot that," moments in programming.
This is one of them. Remember, we're finding all instances of a problem;
you'll get really good at identifying instances while planning a program but
you'll miss a lot of them until you code the damn thing. I just skipped the part
where we run the program and find the error. So how about this as a fix:
string GetWordsForHalfLine () {

if (numWords >= words.Count) {

var sentence = string.Join(" ", words);
words.Clear();
return sentence;
}
var lineWords = words.GetRange(0, numWords);
words.RemoveRange(0, numWords);
return string.Join(" ", lineWords);

We now check first if the words list has enough words. If not, we just
return the current word list turned into a sentence and clear the words list
because we reached the end of our text. This is called defensive programming
and in a world filled with Null References you'll spend a good chunk of your
time typing checks like this in your code.
 We can code the function that creates the line now:
void ShowLine () {
var left = GetWordsForHalfLine().PadRight(halfLineLength);
var right = GetWordsForHalfLine().PadLeft(halfLineLength);
Console.Write(left);
Console.Write(".");
Console.WriteLine(right);
}

Grab the first half of the line and the second half, both duly padded, and
print them to the console, concatenating the dot between them.
Console.Write() continues to print to the current line.
Console.WriteLine() does the same thing plus a line break, so
whatever gets printed afterward, is printed on a new line. Using both of them
in the combination we see here will produce the result we're looking for. Or
will it?
Nah. This code won't work either. Remember, we decided (well, I decided)
to support increasing the number of words printed on a line over time. We
start with two words per line, and then four, and then six... And since words
have different lengths, some lines would fit our stipulated half-line and some
wouldn't.
More defensive programming on the way... Great. How about something
like (in pseudo-code):
bool WillNextLineFit () {
if left half fits and right half fits return true
else return false
}

And how can we check if half-line fits? If we want to check if a set of

words fits a half-line, we could do it like this:
bool WillHalfLineFit () {
var lineWords = words.GetRange(0, numWords);
var line = string.Join(" ", lineWords);
return line.Length < halfLineLength;
}

Once again, we build a line with the slice of words we want to display and
we check the length against our value set in halfLineLength. But would
this work for the second half-line? Nope. Why? Because we are not removing
words from the words List this time, we can't remove them like we did when
we were building the lines. We can only use GetRange() here and not
RemoveRange(). Can you think why? (This is another time I slapped my
forehead).
With this function you want to check if a line fits but leave the word list
intact so if the line doesn't fit we can revert and try again. Therefore, we want
to be able to grab the words and build the lines after checking if the words fit.
Using GetRange(0, numWords) for the start index and count
parameters of that slicer function will return the same words for both halves
of the line in our planned algorithm:
bool WillNextLineFit () {
if left half fits and right half fits return true
else return false
}

We need to pass a different start index and count parameters to

WillHalfLineFit() each time, one for the left side and one for the right
side.
bool WillHalfLineFit (int startIndex, int count) {
var lineWords = words.GetRange(startIndex, count);
var line = string.Join(" ", lineWords);
return line.Length < halfLineLength;
}

What would be the indexes?

Left half line: WillHalfLineFit(0, numWords);

Right half line: WillHalfLineFit(numWords, numWords);

I had to think a while to get at those numbers. If the second range seems
strange (numWords, numWords) you're right. It's the damn "lists are
zero-based" nonsense again. Say numWords equals to five. The first slice
gets elements 0, 1, 2, 3, 4. Therefore, it takes 0 up to 5 but does not include
five. We need an extra slice of 5 elements for the second half. So we want a
slice with 5 indexes that start after that first slice ended at 4. So we need to
start the next slice at 5 (which is our numWords) and take 5 (which is also
our numWords) and that way we get 5, 6, 7, 8, 9.
But oh, oh. We have the same bug again! Dammit! We can't guarantee
GetRange() will work with all possible values for numWords because we
will run out of words as we did before. We need to adjust the slicing count to
what we have available again.
Alrighty. How about:
bool WillHalfLineFit (int startIndex, int count) {

if (words.Count < startIndex + count){

return string.Join(" ", words).Length
< halfLineLength;
}
var lineWords = words.GetRange(startIndex, count);
var line = string.Join(" ", lineWords);
return line.Length < halfLineLength;
}

Yep, we can write all that first return in one line. Or not:
if (words.Count < startIndex + count){
var s = string.Join(" ", words);
return s.Length < halfLineLength;
}

If the total number of words left is less than the length of the slice we're
cutting (start index + count), we return whether the total number of words left
will fit half the line. As an exercise, can you make the function call itself at
that point?
if (words.Count < startIndex + count) {
return WillHalfLineFit(
... something needs to change here ....
)
}

This is called recursiveness, and I'll talk about it some more in a second.
We can now write the function that checks if an entire line will fit,
checking both halves:
bool WillNextLineFit () {
return WillHalfLineFit(0, numWords) && WillHalfLineFit(numWords
, numWords);
}

Note: C# uses && for its AND operator and || for its OR operator.

And how can we use it in the ShowLine() function? What do we do if

we get a false result? Because if this check returns false, we need to
respond accordingly and readjust the line length to something it might fit.
How?
We make the ShowLine() function recursive. Oh yeah! Recursiveness!
This is adult-talk now. Recursive functions are functions that call themselves.
And unlike the joke about the dog licking his testicles, the recursive function
doesn't call itself because it can. It does it because it may solve all sorts of
neat little problems this way. A recursive function must have two elements: a
check to see whether it needs to call itself again or break the recursion, and a
call to itself at some point in the logic. See if you can spot both things in the
following function:
void ShowLine() {

if (!WillNextLineFit()) {
numWords--;
ShowLine();
} else {
var left = getHalfLine().PadRight(halfLineLength);
var right = getHalfLine().PadLeft(halfLineLength);
Console.Write(left);
Console.Write(".");
Console.WriteLine(right);
}
}

We check if the next line will fit, if not, we reduce the number of words we
wish to display and call the ShowLine() function again from within itself.
However, you need to clearly state a condition that will break out of the
recurrence, rather like remembering to increment i (i++) inside a while
loop. Otherwise... kaboom. This time, the error is not a Null Reference error,
but the equally scary: Stack Overflow.
Back to our program. So far it looks like this:
var halfLineLength = 30;
var numWords = 1;

var text = "The quick brown fox jumps over the lazy dog";
var words = text.Split(' ').ToList();

void ShowLine() {
if (!WillNextLineFit()) {
numWords--;
ShowLine();
} else {
var left = GetWordsForHalfLine().PadRight(halfLineLength);
var right = GetWordsForHalfLine().PadLeft(halfLineLength);
Console.Write(left);
Console.Write(".");
Console.WriteLine(right);
}
}

bool WillNextLineFit () {
return WillHalfLineFit(0, numWords) && WillHalfLineFit(numWords ,
numWords);
}

bool WillHalfLineFit (int startIndex, int count) {

if (words.Count < startIndex + count) return string.Join(" ",
words).Length < halfLineLength;
var lineWords = words.GetRange(startIndex, count);
var line = string.Join(" ", lineWords);
return line.Length < halfLineLength;
}

string GetWordsForHalfLine () {
if (numWords >= words.Count) {
var sentence = string.Join(" ", words);
words.Clear();
return sentence;
 }
var lineWords = words.GetRange(0, numWords);
words.RemoveRange(0, numWords);
return string.Join(" ", lineWords);
}

You may have realized we're not handling one edge case at least.
What if one of the words we need to display is longer than half a line?
Some edge cases can be left alone. They'll give you nightmares, for
sure, but you can leave them be. I mean, an English word longer than
30 characters? Pfft.

We just need to decide how to call ShowLine() the first time and for
every subsequent line after that. We could let the user get a new line after
pressing the Enter key, for example, and quit the program when pressing the
q key followed by Enter.
And if you want to increment the value for numWords overtime we could
do that inside a new function:
void IncrementNumWords () {}

For instance, we could increment a counter and once it reaches a certain

value we increment numWords so that we don't increment after every line.
We'd need two new variables:
int incrementNumWordsAfterLine = 2;
int incrementNumWordsCounter = 0;

void IncrementNumWords () {

incrementNumWordsCounter++;

if (incrementNumWordsCounter > incrementNumWordsAfterLine) {

numWords++;
incrementNumWordsCounter = 0;
}

}
 Although, it might be best to cap numWords at a maximum value so that
we don't recurse a bunch of times unnecessarily each time we grab a new
line, creating a stack overflow error.
const int MAX_WORDS_PER_HALF_LINE = 8;

void IncrementNumWords () {

incrementNumWordsCounter++;

if (incrementNumWordsCounter > incrementNumWordsAfterLine) {

numWords = Math.Min(MAX_WORDS_PER_HALF_LINE,
numWords + 1);
incrementNumWordsCounter = 0;
}

A const means a constant value, it is immutable. A number of our

variables could be turned into const, like halfLineLength for example.
Constants don't need to be named with uppercase letters, but there are many
such conventions among programmers.
The Math.Min() helper method selects the smaller value of the two
values listed as parameters.
The program looks like this now:
var halfLineLength = 30;
var numWords = 1;

int incrementNumWordsAfterLine = 2;
int incrementNumWordsCounter;
const int MAX_WORDS_PER_HALF_LINE = 8;

var text = "The quick brown fox jumps over the lazy dog";
var words = test.Split(' ').ToList();

void ShowLine() {

if (!WillNextLineFit()) {
 numWords--;
ShowLine();
} else {
var left =
GetWordsForHalfLine().PadRight(halfLineLength);
var right =
GetWordsForHalfLine().PadLeft(halfLineLength);
Console.Write(left);
Console.Write(".");
Console.WriteLine(right);

IncrementNumWords();
}
}

bool WillNextLineFit () {
return WillHalfLineFit(0, numWords)
&& WillHalfLineFit(numWords , numWords);
}

bool WillHalfLineFit (int startIndex, int count) {

if (words.Count < startIndex + count) {
return string.Join(" ", words).Length
< halfLineLength;
}
var lineWords = words.GetRange(startIndex, count);
var line = string.Join(" ", lineWords);
return line.Length < halfLineLength;
}

string GetWordsForHalfLine () {
if (numWords >= words.Count) {
var sentence = string.Join(" ", words);
words.Clear();
return sentence;
}
var lineWords = words.GetRange(0, numWords);
words.RemoveRange(0, numWords);
return string.Join(" ", lineWords);
}
void IncrementNumWords () {
incrementNumWordsCounter++;
if (incrementNumWordsCounter
> incrementNumWordsAfterLine) {
numWords = Math.Min(MAX_WORDS_PER_HALF_LINE,
numWords + 1);
incrementNumWordsCounter = 0;
}
}

I call IncrementNumWords() whenever I display a new line.

Here's the entire program with the logic to capture user input. (Don't mind
the static keyword, I'll talk about it later). Look for the logic inside Main,
this is where we run the program:
using System;
using System.Collections.Generic;
using System.Linq;

public class Program {

const int MAX_WORDS = 8;

const int MAX_SPEED = 1000;

static string text = "the quick brown fox jumps over the lazy
dog.";

static List<string> words;

static int halfLineLength = 30;

static int numWords = 1;

static int incrementWordsAfterLine = 2;

static int incrementWordsCounter;

public static void Main() {

words = text.Split(' ').ToList();

 Console.WriteLine("\nPress Enter to scroll text and Q to
quit...\n");
ShowLine();

while (words.Count > 0) {

var value = Console.ReadLine();
if (value.ToLower() == "q") break;
ShowLine();
}
}

static void IncrementNumWords () {

incrementWordsCounter++;
if (incrementWordsCounter
> incrementWordsAfterLine) {
incrementWordsCounter = 0;
numWords = Math.Min(MAX_WORDS, numWords + 1);
}
}

static void ShowLine() {

if (!WillNextLineFit()) {
numWords--;
ShowLine();
} else {
var left =
GetWordsForHalfLine().PadRight(halfLineLength);
var right =
GetWordsForHalfLine().PadLeft(halfLineLength);

Console.Write(left);
Console.Write(".");
Console.WriteLine(right);
IncrementNumWords();
}
}

static bool WillNextLineFit() {

return WillHalfLineFit(0, numWords)
&& WillHalfLineFit(numWords, numWords);
}
 static bool WillHalfLineFit(int startIndex, int count) {
if (words.Count < startIndex + count)
return string.Join(" ", words).Length < halfLineLength;
var lineWords = words.GetRange(startIndex, count);
var line = string.Join(" ", lineWords);
return line.Length < halfLineLength;
}

static string GetWordsForHalfLine() {

if (numWords >= words.Count) {
var sentence = string.Join(" ", words);
words.Clear();
return sentence;
}
var lineWords = words.GetRange(0, numWords);
words.RemoveRange(0, numWords);
return string.Join(" ", lineWords);
}
}

Main() will drive the program with these lines:

Console.WriteLine("\nPress Enter to scroll text and q to quit...\n");
ShowLine();

while (words.Count > 0) {

var value = Console.ReadLine();
if (value.ToLower() == "q") break;
ShowLine();
}

You can show a new line hitting Enter, and quit the program by typing q
followed by Enter. You can change the length of a half-line and the number
of words per half-line at the beginning of your training so that words appear
closer to the dot. And little by little, as you get better, you can increase these
values, learning to read the lines without moving your eyes.
I had problems running this particular code in dotnetfiddle so I tested it on
https://repl.it/languages/csharp and it worked there just fine. Remember to
adjust the page layout (the drop-down on the left of the page in the settings
panel) to stacked, and to close the settings panel afterward. You'll need the
horizontal space for this.
As an exercise, you can use the same logic to build the other half of a
typical speed reader trainer. This program will do the following:

It will break a text into words.

It will display each word in the middle of the line.
It will run a timer, updating the words you see.

The goal is to stare at the middle of the line where the single word is
displayed and read the words quickly without sub-vocalizing them in your
head. The interval between words gets shorter and shorter until you hit a
maximum but comfortable speed.
You'll need two things you haven't seen yet.
Console.Clear();

This clears the console and allows you to write the new word where the
previous one was, without the need to create new lines.
It's also very likely you'll need a way to generate a string with an x number
of spaces (the reason may become clear once you start thinking of how to
code this, unless your solution is different than mine). In C# you can do this:
var spaces = new String(' ', x);

And you'll need a timer. Here's a quick implementation of one:

using System;
using System.Timers;

public class Program {

public static void Main() {

var timer = new Timer();

//interval in milliseconds.
//1000 milliseconds = 1 second
timer.Interval = 1000;
//this function will get called
 //after the time has elapsed
timer.Elapsed += OnTimerEvent;
//this timer will repeat, every second in this case
timer.AutoReset = true;
//start the timer
timer.Start();

Console.WriteLine("\nPress Enter to exit the

application...\n");
//we'll be stuck here until user
//hits enter, firing timer event every second
Console.ReadLine();

timer.Stop();
timer.Dispose();
}

static void OnTimerEvent(object sender, EventArgs e) {

Console.WriteLine("Tick Tock");
}
}

A timer triggers an event. Events are notifications dispatched from specific

triggers that your code "listens to" and "handles" through an "event handler,"
which in this case is a function the Timer will call every time its internal
interval elapses. Try to use a speed increment in the same way we
incremented the number of words in our previous program; capping it with a
minimum time interval so that words don't flash too quickly. You can even
implement logic that tracks the number of words per minute and prints that
number out at the end of a reading session so you can track your
improvement.
Have fun. You can check the exercise code at this book's website:
www.rengelbert.com/codingbook/.

I'll finish this chapter with another important digression. I mentioned here
the error known as stack overflow and I think it's important to know why it's
called that. Programs exist in two main memory areas: the heap, and the
stack. Different things are stored in one or the other. Usually, anything you
create with the keyword new or inside the global scope gets placed in the
Heap. However, function blocks make use of the memory in the Stack when
operating. The distinction is more complicated than that since you can new
things inside a function block. But for our purposes this is enough of a
distinction.
The Heap is slow, both to read and to write to. But it's huge. The Stack is
blazingly fast, but tiny (it's not uncommon to have stacks as small as 64KB).
The stack matters a lot to programmers because of two reasons, both
related to errors. One is the stack overflow error and the other is the print
stack feature you'll find in many languages. Let me explain to you what both
of these things mean.
Functions are dealt with through a stack of calls and this is where this
memory area gets its name from. One function call is stacked atop a previous
function call until all functions finish executing. Imagine we have two
functions in our code:
void sheLovesMe(){}
void sheLovesMeNot() {}

During run-time, our application calls them like this:

sheLovesMe();
sheLovesMeNot();
sheLovesMe();
sheLovesMeNot();
sheLovesMe();
sheLovesMeNot();
sheLovesMe();
sheLovesMeNot();

This is a regular stack. By the time the second function is called, the
program might be able to clear out the memory used by the first function. But
what if the functions are written like this:
bool sheLovesMe(){
flowerPetals--;
if (flowerPetals == 0) {
return true;
} else {
return sheLovesMeNot();
}
}

bool sheLovesMeNot() {
flowerPetals--;
if (flowerPetals == 0) {
return false;
} else {
return sheLovesMe();
}
}

Now the functions are being called from within another function. The stack
looks different this time:
sheLovesMe();
sheLovesMeNot();
sheLovesMe();
sheLovesMeNot();
sheLovesMe();
sheLovesMeNot();
sheLovesMe();
sheLovesMeNot();

Now the program won't be able to clear out the memory from previous
functions because it's still waiting for the entire thing to finish executing. This
is normal behavior for programs, but it does take a toll on the stack memory.
And when you write a recursive function that doesn't break its recursion:
void weWillBeHereAWhile() {
weWillBeHereAWhile();
}

Then whenever you call this function it will result in an infinite stack or,
rather, your stack will run out of memory. This is called a stack overflow.
Even if you code a proper break condition, your logic might still cause an
overflow error because, remember, the stack is tiny. So this:
int whatIsTheMeaningOfLife() {
if ( doneProcessing ) {
return 42;
} else {
return whatIsTheMeaningOfLife();
 }
}

Might still cause the same error. The steps necessary to process something
recursively might overwhelm the total size of your stack, and this too will
cause a stack overflow. The solution here involves passing partial results or
solving the problem through a loop, but we don't need to go into this now. I
just wanted you to know what a stack overflow is.
The other concept related to stacks is even more important. What does it
mean to print a stack? When you run a program and, for whatever reason, a
problem occurred that caused the program to crash or throw an error, the
program will print the stack to help you catch the error. This simply means, it
will print to the console the function call where the application stopped
working alongside every previous function call up to that point. Something
like:
An error occurred in the OopsyDaisy() function.
Here's the full stack:

OhBoy()
FingersCrossed()
HereGoesNothing()
OopsyDaisy()

You have no idea how helpful this is. But you will.
And finally, one could point out a third important thing related to stack.
And that is the StackOverflow.com website, where you'll spend the majority
of your programming career.
Trust me.
 Part 4:
Express Yourself
 1
Aristocles And His Stick
What follows is a series of simple tests and curiosities expressed through
code using a variety of programming languages. Some of these problems,
you'll be invited to solve by yourself in any language you choose before
looking at the way I coded them. And some will introduce yet more topics
and new ways to solve problems. As much as I can, I'll try to encourage you
to solve the problems on your own and compare the solutions to the code I
provide. You may pick Python for all your solutions, or C#. It doesn't matter.
I'd recommend that you go back to previous examples and review the code
you might need for a solution. I'll even add a cheat list of operations at the
end of this introductory chapter to help you.
All the problems will be solved using the operations we've seen thus far,
with the exception of two problems that will require learning how to draw
things through code. But otherwise, the problems involve collections, loops,
random numbers, some division, some multiplication, some concatenation,
and some conversion.
As an example, I'll start with a simple problem I call Plato's Stick, although
its official title is Plato's Divided Line. In his book The Republic, Plato
doesn't shut up about it. He was a big fan of the Pythagoreans and if he'd had
any children at least one of them would be named Triangle, I'm sure of it. If
there had been three Plato children, the sum of the squared height of two of
his kids would have been equal to the squared height of his tallest kid. For
sure. (This is what's known as a math joke; they don't have to be funny, they
just have to make sense).
What about his stick?
If you take a line (or a stick) and divide it randomly into two parts (mini-
sticks), then further divide each part proportionally to the first division, you'll
end up with four segments and the two in the middle will always have the
same length. Always.
 I think this passed for fun in ancient Greece. Using the silliest possible
example: If you divide a line in half and then divide each segment using the
same proportion from the first division (fifty percent), the two middle
segments would have the same length. Okay, well, in this silly example all
the four segments would be the same length but if you use any other
percentage the two middle segments are guaranteed to have the same length.
If you went all Pareto and divided the line into 80-20% segments and then
each segment into 80-20% segments the two in the middle would have the
same length.

Plato's Stick Problem

In The Republic, Plato used this to explain reality. I kid you not. And when
people went, "Huh?" Plato went, "All right, never mind the stick, imagine
there are these people stuck inside a cave..." And the rest is history. Most
people know the cave bit, but people usually forget the part with the stick.
Our goal in this exercise is to prove Plato was right. We'll take a thousand
sticks, break them into four parts—following the one rule about respecting
proportions—and prove that the two segments in the middle are equal every
freakin' time no matter how we divide the stick the first time.
Where do we get a stick? Or a line? Or a thousand, for that matter? This is
where we start to express things. We can use a number for this. Or an array.
Or a string. Anything with a magnitude. Numbers should be good for this.
And to simplify things, let's make that number 100, it'll make it easier to
select percentages for the cuts. And to test our logic, let's Pareto it first.
So write me a test. It will create a "stick" with value 100 and:

Split the 100 into 80-20% segments. Resulting in 2 segments.

Split each segment into 80-20% segments. Resulting in 4 segments.
Compare the length of segments number two and three and check if
they're the same.

Once you're done with that, it's time to go nuts with the split. This time we
run 1000 tests. In each one we'll pick a random percentage and use that for all
splits.
Ready?
I'll use C# for this. If you like, you can review the code snippets I'll add to
the end of this chapter to help you write your own code.
Let's work on the first test.
Split the 100 into 80-20% segments. Resulting in 2 segments.
double[] Pareto (double value) {
return new double[] {value * 0.8, value * 0.2};
}

The function will take a double representing the line (or stick). It returns an
array with two doubles respecting the 80-20 cut. And we can split the first
line like this:
var values = Pareto(100.0);

Split each segment into 80-20% segments. Resulting in 4 segments.

var segments1 = Pareto(values[0]);
var segments2 = Pareto(values[1]);

Compare the length of segments number two and three and check if they're
the same.
Console.WriteLine(segments1[1] == segments2[0]);

We first split a stick of length 100. Then we create two segments out of the
first divided part, and two segments out of the second divided part. Every
division follows the same proportion, 80-20. And the second segment in the
first pair must equal the first segment in the second pair. This should return
true, or Plato owes us an explanation.
And for the second test, let's go nuts:
double [] GoNuts(double value, double rnd) {
return new double[] {
Math.Round (value * rnd, 2),
Math.Round(value * (1.0 - rnd), 2)
};
}

var r = new Random();

double nuts = Math.Round( r.NextDouble(), 2 );

var values = GoNuts(100.0, nuts);

var segments1 = GoNuts(values[0], nuts);
var segments2 = GoNuts(values[1], nuts);

Console.WriteLine(segments1[1] == segments2[0]);

I'm rounding the double values to two decimal places here:

Math.Round (value, 2)

So we don't have an enormous double number the computer cannot divide

properly into another enormous double number. We do have a limit to these
things inside our "thinking machine". Pffft.
And now we can bring in a thousand sticks...
var r = new Random();
double [] GoNuts(double value, double rnd) {
return new double[] {
Math.Round(value * rnd, 2),
Math.Round(value * (1.0 - rnd), 2)
};
}

bool IsPlatoRight () {
//get the random value we'll use for our splits
double nuts = Math.Round( r.NextDouble(), 2 );
var values = GoNuts(100.0, nuts);
var segments1 = GoNuts(values[0], nuts);
var segments2 = GoNuts(values[1], nuts);
return segments1[1] == segments2[0];
}

var i = 0;
while (i < 1000) {
Console.WriteLine(IsPlatoRight());
i++;
}

Plato was right.

And yes, it's not just you. double nuts is hilarious.

Cheat Sheets
Python:
import random

myList = [1,2,3,4,5,6,7]
# or
myList = []
myList.append(1)
myList.append(2)
myList.append(3)
myList.append(4)
myList.append(5)
myList.append(6)
myList.append(7)

print( myList[1] )

# loop
for number in myList:
print(number)

for i in range( len (myList) ):

print (i)
print (myList[i])

# slice - first 3 items

myList[:3]

# double between 0.0 and 1.0

r = random.random()
print(r)

r = random.random() * 1000
print(r)

# integer between 0 and 1000

r = random.randint(0,1000)
print(r)

# random item in myList

item = myList[ random.randint (0, len(myList) ]

def myFunction (value):

print(value)

myFunction(10)
value1 = 0
value2 = 2

if value1 == value2:
print("equal")
elif value1 > value2:
print(value1)

greater = value1 > value2 ? value1 : value2

C#
var myList = new List<int> { 1,2,3,4,5,6,7 };
//or
var myList = new List<int>();
myList.Add(1);
myList.Add(2);
myList.Add(3);
myList.Add(4);
myList.Add(5);
myList.Add(6);
myList.Add(7);

Console.WriteLine( myList[1] );

//loop
foreach(var number in myList) {
Console.WriteLine(number);
}

myList.ForEach(number => Console.WriteLine(number));

for (var i = 0; i < myList.Count; i++) {

Console.WriteLine(i);
Console.WriteLine(myList[i]);
}

//slice - first 3 items (start index, count)

var slice = myList.GetRange(0, 3);
var r = new Random();

//non-negative random integer

Console.WriteLine(r.Next());

//integer between 0 and 100

Console.WriteLine(r.Next(0,100));

//0.0 to 1.0
Console.WriteLine(r.NextDouble());

//random item in myList

var item = myList[ r.Next (0, myList.Count) ];

void MyFunction (int value) {

Console.WriteLine(value);
}

MyFunction(10);

var value1 = 0
var value2 = 2

if (value1 == value2) {
Console.WriteLine("equal");
else if (value1 > value2) {
Console.WriteLine(value1);
}

var greater = value1 > value2 ? value1 : value2;

 2
We Are All Cousins
Can you guess what the next code does just by reading it? Take your time.
max = 108E9
generations = 0
people = 1

while people < max:

generations += 1
people = people * 2

years = generations * 30

print(generations)
print (people - max)
print (years)
print (2020 - years)

The E notation is a special mathematical notation, it means the number of

zeroes following the previous number, in this case 108 followed by nine
zeroes. That's the estimated number of all human beings who ever lived on
earth: 108 billion people. This number, however, is somewhat disputable.
There are estimates that state roughly 50E9 people were ever alive. This is
made more confusing because of a dispute over the exact moment in history
from which one should start counting. The difference is huge, depending on
who you talk to; between 6E6 and 3E5. Humans could be said to have existed
on earth for 6 million years if you count from when we decided walking on
two legs was a better look and 300 thousand years when we started hitting
our opposable thumbs with the first tools we invented. If you're fine with
hairy bodies and walking on all fours (why wouldn't you?), we then go back
to 20E6. And you can imagine that how long we've been doing the whole
"being human" thing matters a great deal in order to calculate the number of
human beings who were ever born.
But I chose the highest estimate for two reasons: because it makes the
calculations even stranger and because Sci-Fi writer Arthur C. Clarke
managed to make a pretty good estimate when in 1968 he wrote, "Behind
every man now alive stand thirty ghosts, for that is the ratio by which the
dead outnumber the living. Since the dawn of time, roughly a hundred billion
human beings have walked the planet Earth." Nice. That estimation is only
good enough if we go with the 108E9 rather than the 50E9 number, because
around 1968 that estimate was roughly 100E9. In the war between fact and
fiction, science fiction beats both of them every time.
Okay, so 108 billion people, that's the total number of people who were
ever born.
max = 108E9

100 billion ghosts if you subtract the 7 point something billion currently
alive (well, maybe closer to 101 billion ghosts by now, but who wants to be
picky about ghosts?). Now we start a people count and we start it with you.
Yes, you. Because you're the best, and number one. Yes, you are. Don't be
shy.
people = 1

And while the count is less than the max number of people who ever lived,
we count generations of you. Or as we all call it, The Great Honorable House
of You.
while people < max:
generations += 1
people = people * 2

We multiply your people by two each time because, although you're great
and all, you still needed two parents. And they were both great! (Well, your
father not so much but still quite good, and anyway, we don't like to talk
about that, do we?). And each parent had two parents, and each grandparent
had two parents... This is a simple progression, a "power of 2" progression,
the same one computers love so much because of the whole binary thing.
Eventually, the number of people in The Great Honorable House of You will
surpass the number of people who were ever alive on this planet if we keep
the progression long enough. The question is: how long is long enough? We
can calculate how long does that take, in years, by multiplying the generation
count by 30 (some people say a generation is closer to 35, but those people
never heard of teenage pregnancy).
years = generations * 30

How many years is that? How many years does it take for your ancestors to
surpass the total number of people who were ever born? Ready?
print(generations)
print (people - max)
print (years)
print (2020 - years)

One thousand, one hundred and ten years, or 111E1 if you want to take that
whole E thing a bit too far. That's 37 generations. So around the year 910,
when Vikings were still a thing, The Great Honorable House of You reached
the maximum number of people who ever lived a few hundred thousand
years ahead of schedule. Actually the total number of "your people" in 910
went past the total number of "people ever" by quite a bit: 29.438,953,472.
Reaching a whopping 137E9 number of people who were ever born. By 910!
I can get the number of people like this as well:
people = pow(2, generations)

This raises 2 to the power of generations. Python also lets me do this:

people = 2 ** generations

In any case, we don't need to update the people value inside our loop and
use generations to derive this people value.
Now, I don't know if you've noticed it, but there are more people out there.
And some—the unfortunate ones, I call them—are completely unrelated to
you. Let's say you know 10 such people; sounds crazy, I know, but some
estimates say there can be as much as 12 such people. Our loop would go like
this:
strangers = 10

while people < max:

generations += 1
 people = people * 2 * strangers

This time, we'd reach the same number in 9 generations, 270 years ago, in
1750 when Samuel Johnson is publishing the first edition of The Rambler.
God forbid you walk down a busy street and see a hundred strangers or count
the strangers you friended on Facebook, thus proving they might possibly
exist. Then we'd reach the maximum number in four generations. But how?
We've lived longer than that. I think. I saw pictures, anyway. So what gives?
Well, cousin, I don't know, sounds crazy to me too.
As an exercise, can you write the while loop I wrote as a recursive function
instead? Can you write a function that given a year (in the past) will calculate
how many relatives you had up to that point? Can you calculate how many
relatives you had around year zero? How many of them heard about Rome
burning (64) or read the news about the Titanic (1912)?
 3
Intelligent Women Marry Dumb
Men
Or as Daniel Kahneman put it: "Highly intelligent women tend to marry
men who are less intelligent than they are." His statement is much closer to
the truth and does not attempt to get a rise out of people as mine does. All
following versions of the statement are correct:
"Highly intelligent men tend to marry women who are less intelligent than
they are."
"Highly unintelligent men tend to marry women who are more intelligent
than they are."
"Highly unintelligent women tend to marry men who are more intelligent
than they are."
And of course, we may include every variation where the gender does not
change at all. Intelligent men will tend to marry men who are less intelligent
than they are and so will women when choosing other women to tie the knot
with. This "phenomenon" is based on something called Regression to The
Means, which, although remarkably simple, have a way to appear terribly
complicated because humans tend to look for causation where no such thing
exists. We end up asking stupid questions like, "What is wrong with this
woman?" or "Do you mean to say unintelligent women need protection from
men!" or "You're saying intelligent men feel threatened by intelligent
women? You bastard!"
Nah.
If an athlete, say, a Football player, has a really good year playing for this
one team and a major Football team decides to pay millions for him
expecting this player to have another great year; they will be, very likely,
disappointed. If a person is overweight and decides to follow some crazy diet
that makes no sense, this person will very likely lose weight. If you're sick
and your condition worsens beyond what would be expected and you take an
experimental drug made of candy, spit and prayers, the drug will likely work
and improve your condition (even though it doesn't really). Andy Weir's
novel following The Martian was a huge disappointment. All because of
regression to the means.
Let's work on the mathematical proof, using Python. If you wish to code
this on your own the steps are as follows:

Let's assume an IQ range of 60 to 150. If the lowest value gets even

lower than this, meaning the husbands get even dumber, the results are
even more dramatic. But I used Wikipedia to find out a nice common
low and high values for IQ. We need values way above or way below
average.
Assume the bride to have an IQ of 130. No Einstein, but sharp!
Let's run a test with 1000 husbands. Select their IQ values randomly and
count how many of those have a lower IQ than the bride's.
Then we print out a percentage of dumber husbands.

One of my favorite things about these types of tests involving randomness

is that we can create our own lab inside our computer. Turns out the
randomness we can generate through code matches most of the randomness
we see in the real world with very few exceptions.
Don't forget to start by importing the random module in Python, writing
import random at the top of the script. This is similar to the using lines
in C#. We need the module random because that's where the random
generator is. So far, we've been coding with what is known as the core
Python libraries and so didn't need to import anything. When you write a
script in python and call that script something like mememe.py this becomes a
module called mememe you can import into other scripts and call the
functions declared inside mememe.py using dot notation, like
mememe.whoIsNumberOne(). It's what happens with the random or
math module. Same thing.
Ready?
My code looks like this:
import random
wife_iq = 130

tests = 1000
dumber_cnt = 0.0

i = 0
while i < tests:
husband_iq = random.randint(60,150)
if husband_iq < wife_iq:
dumber_cnt += 1
i += 1

result = dumber_cnt / tests

print ( result * 100 )

We establish the wife's IQ:

wife_iq = 130

We run a certain number of tests, generating a random integer between our

extremes (60, 150):
while i < tests:
husband_iq = random.randint(60,150)
if husband_iq < wife_iq:
dumber_cnt += 1
i += 1

And if the random IQ is less than the wife's, we increase the dumber count.
In the end, we calculate the number of time out of 1000 the IQ was less than
the wife's:
result = dumber_cnt / tests

With these values we get about 75-80% chance the husband will be dumber
than the wife. As it should be. Think of the IQ range (60, 150) as a line or a
spectrum. The woman in the test is pretty near one tip of the line, say 20%
away from the very tip. Therefore she has 80% of the line to pick husbands
from on one side (those less intelligent than she is) and 20% of the line on the
other side (those more intelligent than she is). So it's far more likely he will
be dumber. And that's it. If the wife had been closer to the left tip of the line,
the 60 value, she'd have a lot more line left representing people with higher
IQ to pick a spouse from than people who are even less intelligent than she is.
The thing that troubles people with Regression to the Means is that humans
believe our capacity to control and influence things is much higher than it
actually is. And besides, we have a bias towards causality. But regression to
the means governs all things random. And whether you like it or not,
choosing a spouse is pretty random, because it depends on too many variables
outside one's control. Where you live, the people you meet, your endless list
of biases, the annoying things about you and your spouse-to-be—and how
obvious these are from the start—whether you had a meal or not when you
met, or something to drink... and on and on. However, we would be okay if
regression to the means was stated like this instead:

Pick a random number from 0 to 100.

Do this a thousand times and count the number of times we got a value
that is less than 80.
import random
tests = 1000
less_than_80 = 0.0

i = 0
while i < tests:
if random.randint(0,100) < 80:
less_than_80 += 1
i += 1

result = less_than_80 / tests

print ( result * 100 )

Not surprisingly, you'll get something close to 80% of results matching that
condition. Even though, mathematically speaking, the two things are the
same, we're OK with the second one simply because it is unattached to
anything "human".
Incidentally, I'm using 0.0 for the dumber_cnt variable declaration to
make it into a float. Otherwise I'd have to get the result value like this
depending on the version of Python I'm using:
result = float(dumber_cnt) / tests

Or this:
result = dumber_cnt / float(tests)

One of the numbers would need to be a float in order to get a float result
from a division. The more recent versions of Python will be okay with this
producing a float:
print(8/3)

We saw this before when we converted values and used the // to get integer
results out of these divisions, but I just wanted to refresh your memory.

But what if you're not sure about which spouse to pick from a list of
available options? Or which house to move to, or which job offer to accept,
or the next destination for your holidays? Fear not here's Python to the
rescue. Mathematics calls this either The Optimal Stopping Problem or The
Secretary Problem. I prefer the first name. It means: when is the best time to
make a decision and stop looking for more available options? (The second
name comes from a classical example where a boss is trying to decide which
candidate to hire as the new secretary).
There are two really good solutions. I called them the "Ignore A Third" and
the "Shift Your Standards" solutions. You should use the first solution if you
know the total number of options (prospective spouses, jobs, houses,
destinations); meaning, you're trying to choose from a known and finite list of
options. The second solution should be used when the options are not all
known; when you meet more attractive people every day, or see more
interesting jobs, or find more dream-houses or more perfect destinations to
choose from...
Now comes the bad news. For both solutions to work, you need to be able
to grade the options. Say from one to a hundred. Remember, this is the
optimal stopping moment you're looking for. The solutions will tell you when
to stop looking for something better. And I know it may be terribly crass to
score things, especially when the things are people, but hopefully, our system
of measurement is far more complicated than just looks and anatomical sizes.
 So how does the first solution work? Here are the steps in case you want to
code this on your own first:

Create a test that generates a collection of 100 choices, each of them

being a random value ranging from 1 to 100. (You can later run the
same tests with a collection of non-repeating values, so basically the
numbers 1 to 100, and have this list shuffled).
Runs through the first 37% of the values and collect the highest value
among them.
Use that value as your "Standard," and when looping through the
remainder of the choices, pick the first one higher than the "Standard".
(This loop must start at the 38th element, in this example, since 37
elements were skipped in the previous step because 37 is 37% of 100).
If no such item is found, return the one that set the "Standard".
Run this test 1000 times and evaluate the average result.

Ready?
import random

def ignore37():
choices = []

for i in range(100):
choices.append (random.randint(1,100))

ignore = int(len(choices) * 0.37)

standard = 0

# loop through the first 37%

for i in range(0, ignore):
if choices[i] > standard:
standard = choices[i]
# loop through again, skipping the first 37%
for i in range (ignore, len(choices)):
if choices[i] > standard:
return choices[i]
return standard
num_tests = 1000
strategyOne = 0.0

for i in range(num_tests):
value1 = ignore37()
strategyOne += float(value1)

print(
"Results using Ignore 37%: {0}"
.format(strategyOne/num_tests)
)

Once again, the code loops through a number of tests. It generates the
random choices, takes each one of the values and processes them following
the 37% rule:
def ignore37():
choices = []

for i in range(100):
choices.append (random.randint(1,100))

# get 37% of values to ignore

ignore = int(len(choices) * 0.37)

standard = 0

# loop through the first 37%

for i in range(0, ignore):
if choices[i] > standard:
standard = choices[i]

# loop through again, skipping the first 37%

for i in range (ignore, len(choices)):
if choices[i] > standard:
return choices[i]

return standard
 There is a loop determining the standard, the highest value among the first
37%:
# loop through the first 37%
for i in range(0, ignore):
if choices[i] > standard:
standard = choices[i]

Although with Python we could get the maximum value with a slice and
the max() function:
slice = choices[:ignore]
standard = max (slice)

max() can return the largest number inside a collection of numbers. And
of course, we could have written that in one line:
standard = max (choices[:ignore])

With the second loop, we look for the very first item we find among the
remaining items which are larger than the standard:
# loop through again, skipping the first 37%
for i in range (ignore, len(choices)):
if choices[i] > standard:
return choices[i]

There are many more tests you could do. You could, for instance, establish
a minimum value you're okay with, say 75, and track the number of times out
of 1000 in which the value selected was randomly higher than your
minimum. You'll be surprised by the results. In any case, this method gets it
right over 98% of the time. As long as you can grade things and know the
total number of options, you'll find the best one, guaranteed.
And how does the second method works? Again, I'll give you the list of
steps if you wish to code it on your own. You can even follow the previous
code to help you out with this one.

Create a test that generates a collection of 100 choices, each of them

being a random value ranging from 1 to 100. Once again, you might
wish to test this with a collection of unique values later.
Establish a minimum value as your "Standard", say 75.
 Run through the available options (this could potentially be an infinite
collection) and find the first value which is higher than the standard.
Set that value as your "New Standard" and loop through the rest of the
collection until you find a higher value.
If none is found, return "New Standard".
Repeat this for a 1000 tests and print out the average.

Ready?
import random

minimum_standard = 75

def selectBaseValue():
choices = []

for i in range(100):
choices.append (random.randint(1,100))

new_standard = 0
for i in range(len(choices)):
if new_standard == 0:
if choices[i] >= minimum_standard:
new_standard = choices[i]
else:
if choices[i] >= new_standard:
return choices[i]
return 0

num_tests = 1000
strategyTwo = 0.0

for _ in range(num_tests):
value2 = selectBaseValue()
strategyTwo += float(value2)

print(
"Results using Shifting Standards: {0}"
.format(strategyTwo/num_tests)
)
 The main difference is the function describing our rules for picking a value:
def selectBaseValue():

choices = []

for i in range(100):
choices.append (random.randint(1,100))

new_standard = 0

for i in range(len(choices)):
if new_standard == 0:
if choices[i] >= minimum_standard:
new_standard = choices[i]
else:
if choices[i] >= new_standard:
return choices[i]
return 0

This time we loop until we find a value higher or equal our minimum
standard and use that as our new standard. If we do have a new standard
already set, meaning new_standard does not equal zero, we look for the
first item that's greater or equal new_standard. (You could remove the
equal from both statements and see how big of a change this would cause
in the final results).
The result with this second strategy will prove slightly less effective than in
the first one, but we do know less with this one and I find it more realistic
and applicable in the real world. You're dealing with a potentially infinite
number of options and you want to know when to stop looking, and yet it
doesn't force you to settle on a "good enough" and helps you pick a really
good option over 90% of the time. Not bad.
So go out there and live the Edith Piaf life: no more regrets. Seriously, this
book is paying for itself!
 4
Birthday People
There is a probability theory known as the Birthday Problem, or Birthday
Paradox. It states that in a group of 23 people there is a 50% chance that two
of them share the same birthday (day and month). And in a group of 70, the
probability is nearly 100%. It's a "problem" because intuitively people expect
the group number to be much higher before we can reach those values. I
mean, 23 for half the chance? That seems too low. This mode of thinking is
called the "pigeon-hole" rationale and basically states that we'd need
something approaching 365 people before our chances of repeating a birthday
would be near 100%, and not a number over five times smaller. This
incidentally, is the same irrational way of thinking that leads one to believe
their passwords are impossible to crack. You wish.
So if 23 people are reading this book right now, there is a 50% chance two
of them have the same birthday. If the number of people reading this book
reaches 70 (I wish!) then it's a dead cert two of them will get those awkward
cards at work on the same day. But is this really true? The birthday part, I
mean. Well, let's find out!
I want you to stop for a moment and think about how to test this theory, go
ahead: within a group of 23 people there's a 50% chance two of them share
the same birthday. Don't try to convert your solution to the programming
syntax you've learned so far. Just think about the steps you'd take and the
type of information you'd need.
I'll use C# this time and lead you step-by-step through different ways you
can solve this. Thinking about the problem, there are a few things we know
already: The code needs to be the equivalent of putting a group of 23 people,
randomly selected, inside a room (a collection) and check if any two of them
share the same birthday. We know we need a way to pick random values in
order to generate a random group of people, or rather a random group of
dates since this is what we care about.
 What about these dates? Most languages will have a Date library with an
API for various operations related to dates. Things like generating a date and
retrieving what day of the week that falls in, and whether some year had 365
days or not, and how many milliseconds have elapsed since the beginning of
all time in 1970. Wait, what? Computers use Epochs to mark when to start
counting time from. The most common one is the 1970 epoch, created by
Unix. This choice of date had to do with how big a number computers at the
time could deal with (ranging from negative to positive numbers), and if you
think the Y2K bug was a problem just you wait until the 2038 bug hits; when
all hell will break loose and dates won't mean anything. Picture the movie
Purge but with nerds on CNN talking about Epochs. This is known as The
Year 2038 Problem. Google it. And relax, we'll be fine. Well, unless your
birthday matches someone else's birthday, but what are the chances of that,
am I right?
In C# the date object is called DateTime and it comes with the usual
helper methods to add and subtract days, to retrieve the day of the week or
day of the year and all the rest. But since in our little program all I care about
are unique days in a year, I don’t need to use DateTime objects at all, I can
just use integers from 1 to 365, or any list with 365 unique values.
Yep, I've been wasting your DateTime talking about this!
Do you want to code this on your own first? You can use Python if you
like.
We need a collection to fill up with 23 values picked randomly from a
range of 1 to 365. I’ll create a function called TestTheory() and run the
test logic inside it. static void TestTheory () { }
I'll need some variables. We need a number of tests to run and the number
of people we’ll place inside the same “room” so we can vary this number
later when I decide to run more tests with different numbers of people.
int numTests = 1000;
int numPeople = 23;

And why not use the power of type inference?

var numTests = 1000;
var numPeople = 23;

No reason. You can do it either way. As a matter of fact, it might be better

to do this:
const numTests = 1000;
const numPeople = 23;

Since these are not variables, but values. Or don’t worry about this sort of
thing, life is too short. We also need to keep track of positive results, meaning
the number of times we found at least two people with the same birthday.
var positiveResults = 0;

This one is a variable (mutable) since we’ll update its value, and I used
inference now, because who likes typing? We need a while loop to run the
tests using that numTests counter.
var i = 0;
while (i < numTests) {
//code will go here
//don't forget to increment the count!
i++;
}

Now, what exactly is the test? We need to pick 23 people and check their
birthdays, and we need to do this in every iteration of the while loop. I’ll use
two more functions, one to grab the 23 people's birthday values and one to
find matches in the list of birthdays. The while loop will look like this:
var i = 0;
while (i < numTests) {

var people = PickRandomDates(numPeople);

if (HasMatchingBirthday(people)) {
positiveResults++;
}

i++;
}

The act of coding function calls for functions that don't exist is called
stubbing. Well, technically you would want to code the empty functions to
get rid of errors, and that's called stubbing:
var i = 0;
while (i < numTests) {

var people = PickRandomDates(numPeople);

if (HasMatchingBirthday(people)) {
positiveResults++;
}

i++;
}

List<int> PickRandomDates (int numPeople) {

return null;
}

bool HasMatchingBirthday (List<int>) {

return false;
}

Stubbing is a neat way to start writing the "first draft" of your code.
Ok. So PickRandomDates() returns some sort of collection, and
HasMatchingBirthday() returns a boolean. We'll write those functions
next, but so far the entire TestTheory() looks like this:
static void TestTheory () {

int numTests = 1000;

int numPeople = 23;

var positiveResults = 0;

var i = 0;
while (i < numTests) {
var people = PickRandomDates(numPeople);

if (HasMatchingBirthday(people)) {
positiveResults++;
}
 i++;
}

Console.WriteLine(
(float) positiveResults/ (float) numTests
);
}

We finish it by printing out a percentage of how many positive results did

we get out of the total number of tests.
PickRandomDates() receives a count of people, and returns an array
of dates, or, as I’ve decided to represent them for our problem, an array of
integers.
static int[] PickRandomDates (int count) {}

First, we create the result returned from the function:

var result = new int[count];

This could be a List, but why not use Arrays every now and then? We
create an array of integers containing a number count of items (which
happens to be 23 in this current example). Arrays in C# are immutable, they
don’t change, so when you create an array of something you must do it by
telling the array how many of something it will hold. The array we created
has 23 slots, but what’s in them? Arrays will fill up with default values and
these change, depending on the type of something the array is holding. The
most common default values will be Null.
But this array:
trueOrFalse = new bool[1000];

...will contain by default 1000 false values. And:

someNumbers = new int[1000];

...will contain 1000 zeroes by default.

You can then change the values in a specific slot like so:
someNumbers[900] = -1;

But in our example, as you saw, we used the value in the variable count
being passed to the function to inform the array of how many items it will
contain. We’ll test the theory with 70 people later, so it makes sense to make
this count a variable in our program.
We loop and pick our dates. We’ll use our random number generator we
declare outside the function somewhere, in a parent scope:
static Random random = new Random();

So that:
var i = 0;
while (i < count) {
result[i] = random.Next(365) + 1;
i++;
}

Fills up our array with random values.

The function Random.Next(some number) will return the next
random number our generator can produce, within the range 0 to some
number. So if I told you to think of a number between 0 and 100, the function
would be:
Random.Next(101);

Because the range does not include the last number.

If I wanted from 1 to 100, I could do this:
Random.Next(100) + 1;

Random would give me a number from 0 to 99 and I’d add one to it.
In our function, this line:
int index = random.Next(365) + 1;

Will pick values from and including 0 to and including 364 and add 1.
Here's the entire thing:
static Random random = new Random();

static int[] PickRandomDates(int count) {

var result = new int[count];
var i = 0;
 while (i < count) {
result[i] = random.Next(365) + 1;
i++;
}
return result;
}

Not sure if you should marry Phil or Bob? Here’s a program to solve all
your problems.
var options = new string[] {"Phil", "Bob"};
Console.WriteLine ( options [new Random().Next(2)] );

Boom! Done. I wish you both smooth sailing. I know entire religions built
on shakier ground.
What about our second function, HasMatchingBirthday()? It
receives an array of integers and returns a boolean.
static bool HasMatchingBirthday (int[] dates) {}

The function needs to determine if the array contains duplicates. There are
a gazillion ways to do this. Here’s one:
static bool HasMatchingBirthday(int[] dates){
var days = new int[dates.Length];
var i = 0;
while (i < dates.Length) {
var date = dates[i];
if (Array.IndexOf(days, date) >= 0)
return true;
days[i] = date;
i++;
}
return false;
}

I create a new array of integers (days) to hold the dates I’ve already
checked for duplicates. I’ll loop through the dates and if the individual date
already exists inside days, it means we found a duplicate. For this, I use
another method of Arrays: the IndexOf. This line:
Array.IndexOf(days, date)
 Says, what is the index of value “date” inside the array “days”. If the index
is anything equal to 0 or greater, this means the function found the item
“date” inside the array. If it fails to find anything, it will return a value of -1.
But say you didn’t know there is such a thing as that method, even though
we've seen it before, I know, but be a sport! It’s quite common when using a
language not to know all the helper methods it comes packed with. No fret.
Just write your own. Here’s an implementation of IndexOf() we could
have used in our program:
int IndexOf (int[] array, int element) {
var i = 0;
while (i < array.Length) {
if (array[i] == element) return i;
i++;
}
return -1;
}

Our entire program looks like this so far:

using System;

public class Program

{
private static Random random = new System.Random();
public static void Main()
{
TestTheory();
}

static void TestTheory()

{
const int numTests = 1000;
const int numPeople = 23;
var positiveResults = 0;
var i = 0;
while (i < numTests)
{
var people = PickRandomDates(numPeople);
if (HasMatchingBirthday(people))
{
 positiveResults++;
}

i++;
}

Console.WriteLine(
(float)positiveResults / (float)numTests
);
}

static int[] PickRandomDates(int count)

{
var result = new int[count];
var i = 0;
while (i < count)
{
result[i] = random.Next(365) + 1;
i++;
}

return result;
}

static bool HasMatchingBirthday(int[] dates)

{
var days = new int[dates.Length];
var i = 0;
while (i < dates.Length) {
var date = dates[i];
if (Array.IndexOf(days, date) >= 0)
return true;
days[i] = date;
i++;
}
return false;
}
}

And when I click Run and write the results to the console, I get values like
0.543, 0.492, 0.512… Meaning close to 50 percent of chance two people out
of 23 share the same birthday.
If I make this change:
int numPeople = 70;

The values range around 0.999.

As an exercise, can you change the code so as to determine how many
people are necessary in order to have 3 of them share the same birthday? And
how many people would be necessary to match a specific date 50% of the
time?

If we had used a mutable List in our program instead of Arrays it would

look something like this:
using System;
using System.Collections.Generic;

First, I’d import the library for Collections.Generic where Lists

live. And PickRandomDates() would return a List of integers.
static List<int> PickRandomDates (int count) {

var result = new List<int>();

var i = 0;
while (i < count) {
result.Add(random.Next(365) + 1);
i++;
}

return result;
}

A list is a mutable collection. It does not need an initial size, although you
could provide it with one. With lists, you Add() an item, and you grab the
length of the list by using .Count. But the individual elements are still
referred the same was as with an Array:
myList[0];
myList[1];
myList[2];
…
 We could also use a HashSet collection, in fact, let’s do that in the
second function:
static bool HasMatchingBirthday (List<int> dates) {
var days = new HashSet<int>();
foreach (var date in dates) {
if (days.Contains(date))
return true;
days.Add(date);
}
return false;
}

A HashSet is a collection that can retrieve the information of whether or

not it contains an item really fast, and you can't have duplicate values inside a
HashSet. But you can’t refer to items inside a HashSet through an index
and the HashSet can’t guarantee items will remain stored in the order they
were added to it. But we don't care about that in this problem.
What else can we do? Well, we could use my favorite library in C#: Linq.
using System;
using System.Linq;
using System.Collections.Generic;

public class Program

{
private static Random random = new System.Random();

public static void Main()

{
TestTheory();
}

static void TestTheory ()

{

const int numTests = 10000;

const int numPeople = 23;

var positiveResults = 0;
var i = 0;
 while (i < numTests) {

var people = PickRandomDates(numPeople);

if ( people.Distinct().Count() != people.Count ) {
positiveResults++;
}
i++;
}
Console.WriteLine(
(float) positiveResults/ (float) numTests
);
}
}

Linq makes collections super-powerful and versatile. I can use the

Distinct() method, which retrieves all unique values from a collection,
and then I can check if the number of distinct values is the same as the total
number of items I started with before I ran Distinct() on them. If not, it
means I have duplicates in my collection, which is why Distinct() made
the resulting list shorter. And just like that I get rid of one of the functions,
the HasMatchingBirthday().
if ( people.Distinct().Count() != people.Count ) {}

And how about this:

var people = Enumerable.Repeat(0, numPeople)
.Select( _ => random.Next(365) + 1)
.ToList();

Enumerable is also part of Linq and it comes packed with helper

methods to create ... well, "enumerables" (collections you can iterate through;
what Python calls iterables). Those three lines are saying:

Create an enumerable by filling it with zeroes, a numPeople of times.

(23 zeroes, for instance).
Map each 0 value in the enumerable we just created replacing it with a
random number between 1 and 365. C# calls map Select as we've
seen before.
Cast the enumerable into a List.
 The underscore _ means Any, if you remember, and it's a way to write
parameters when they don't really matter in our logic or could hold any value.
I could have written it like this:
.Select( x => random.Next(365) + 1)

But x here means the values we filled the enumerable with in the previous
line, and since we're not going to use that x value for anything and instead
just replace it with our random number, we can replace it with Any.
We end up with:
using System;
using System.Linq;
using System.Collections.Generic;

public class Program

{
private static Random random = new System.Random();

public static void Main()

{
TestTheory();
}

static void TestTheory () {

const int numTests = 10000;

const int numPeople = 23;

var positiveResults = 0;
var i = 0;
while (i < numTests) {
var people = Enumerable
.Repeat(0, numPeople)
.Select( _ => random.Next(365) + 1)
.ToList();

if (people.Distinct().Count() != people.Count) {
positiveResults++;
}
i++;
 }
Console.WriteLine(
(float) positiveResults/ (float) numTests
);
}
}

Or, we could make people represent the final number result we need to
match with numPeople in our Linq query instead of a list of integers,
bringing in Distinct() to join our happy query:
var people = Enumerable
.Repeat(0, numPeople)
.Select( _ => random.Next(365) + 1)
.Distinct()
.Count();

if ( people != numPeople ) {
positiveResults++;
}

Now people is no longer a List but an integer which is what we wanted

the whole time.
And this is what Linq does. It allows us to create these chains and queries
using collections and it's heavily inspired by a paradigm called Functional
programming as we'll see later.
Do you have to be this parsimonious with your lines of code? Nope. Each
language will, however, offer different ways to solve problems and once you
decide to learn a language you might as well try to find out what you have
available to you. Do try to use map and filter and all these higher-order
functions as much as you can. It'll make you a better programmer. The syntax
offered might be strange at first, but they're really just trying to make
common operations work inside chains, so your code can become more
compact.
Python has something called "list comprehensives" which are somewhat
similar to what you can do with Linq in C#. The use of these list
comprehensives is said to be more "pythonic", meaning: if you're using
Python, why not really use Python the way it was meant to be used.
 Do you have to? Nah. Compactness can result in code that is hard to read.
And keep in mind that the algorithm you remember and know how to apply is
better than the thing you have to keep Googling for.

Well, this whole birthday thing creates more questions than it answers.
What the code really shows is that if you have a pool of 365 unique elements
and randomly pick 23 out of them, there is a 50-50 chance two of them will
be the same.
So what if we were to ask people to think of a number between 1 and N.
How many people would it take until we had a 50% chance of a repeated
guess using an N-pool of numbers?
Let's find out.
If you want to stop now and code this yourself, go ahead. You should be
able to reuse most of the logic coded for the Birthday Problem.

Run a certain number of tests.

In each test create a list with the numbers x people picked from 1 to N.
Let's pick 100 for our test.
Check if the chance two people picked the same number is at least 50%.
If not, increase the number of people until we have an answer: how
many people does it take until there is a 50% chance two persons picked
the same number between 1 and 100.

Here's my code:
private static Random random = new Random();

public static void Main()

{
PickANumber(100, 2);
}

static void PickANumber (int totalNumber, int numPeople) {

const int numTests = 10000;

var positiveResults = 0;

var i = 0;
 while (i < numTests) {

//calculate number of distinct "picked numbers"

var people = Enumerable
.Repeat(0, numPeople)
//make each choose a number
//between 1 and totalNumber
.Select( _ => random.Next(totalNumber) + 1)
.Distinct()
.Count();

//check for duplicates,

//if total of distinct numbers is not numPeople
if (people != numPeople)
{
positiveResults++;
}
i++;
}
//calculate percentage of positive results
var percentage =
(float)positiveResults / (float)numTests;

if (percentage < 0.5 ) {

//less than 50%? call the function
//again with more people
PickANumber (totalNumber, numPeople + 1);
} else {
Console.WriteLine(“With “ + numPeople +
“ people we reached “+ percentage );
}
}

The code now uses a recursive function, PickANumber(). We start

asking two people, and if the chance is less than 50% (meaning a less than
50% chance two people chose the same number out of 100), we ask 3 people,
and then 4 and 5... recursively.
My tests say that 12-13 people would be enough to reach a 50% chance for
duplicate guesses with a maximum of 100 values. Although people are
notoriously bad at picking random numbers, so in real life, results might be
even worse. (We tend to think alike).
And as an exercise: how many people, on average, would be needed to
have all possible birth dates represented in one single group? In other words,
all values from 1 to 365 would be in the collection?
So with 365 cakes how many extra people would be around to spoil the
fun? (These problems keep me awake at night).
 5
Randomness Is Strange
If you watch a lot of YouTube videos showing self-help gurus and rich
CEOs telling you the secret to success, this chapter will disappoint you.
There are three particularly odd ways randomness can explain success and
which our causality-biased minds have difficulty accepting. We're only
exposed to the success stories where good-fortune was said to be the result of
following "miraculous patterns" of behavior (habits and routines from the
super-rich, for example). We're rarely exposed to the ginormous number of
people who followed the same "miraculous patterns" and failed miserably. As
mathematician John Allen Paulos put it: "There's always enough random
success to justify almost anything to someone who wants to believe." I for
one find these words comforting.
If I'm about to break all your illusions, let's do it in Python. C# has a
harshness to it that we don't need for this.

Odd Thing Number One: The 63% rule.

Shuffle two decks of cards. There is a nice theory that says a shuffled
deck of 52 cards will always be unique, the first in the universe. Why?
This is the number of possible combinations the cards can be in:
80658175170943878571660636856403766975289505440883277824000000000000
that's why. You get it by multiplying 52 * 51 * 50 * 49 * 48...
Now flip one card at a time from each of the unique-never-before-seen-
in-the-universe deck of cards; creating pairs of flipped cards, one from
each deck.
There is a 63% chance you'll flip two identical cards, creating at least
one identical pair.
 This rule, rather counter-intuitively, applies to however many items you
wish. Gather a thousand people and collect their cell phones into a large box.
Shake the box thoroughly. Then return cell phones to each person, randomly
—or while blind-folded if you wish. There is a 63% chance at least one
person will walk away with the right phone.
Do you want to stop now and code this test yourself? Be my guest. I will
show off a bit in my code. I want to use these examples to expose even more
syntax and commands to you. But you should be able to code the test with
what we've seen so far.

Look what I did:

import random

def testCardFlips ():

values1 = [n for n in range(52)]
values2 = [n for n in range(52)]

random.shuffle(values1)
random.shuffle(values2)

for n in range(52):
if values1[n] == values2[n]:
return True

return False

positives = 0.0

for i in range (1000):

if testCardFlips() == True:
positives += 1

print (positives/1000)

#result: 0.635

Check out that fancy way to fill a list!

values1 = [n for n in range(52)]
 It states: Grab n from the values that n has in the range from 0 to 51 and put
all those values inside a list. Nice.
But what if you do think this is more readable:
values1 = []
values2 = []
for n in range(52):
values1.append(n)
values2.append(n)

I don't blame you. I don't always do things in a Pythonic way. So there!

Take that Python and smoke it.
random.shuffle() can shuffle a list for us and then it's a simple
matter of seeing if any of the indexes have a similar value:
for n in range(52):
if values1[n] == values2[n]:
return True

Once we prove that, we can find the chances two cards will have the same
index in both decks. And also prove that the chance remains the same using a
different number of items (by coding the example with the cell phones, for
instance). I'll leave that as an exercise.

Odd Thing Number Two: The Hot Hand.

Create a list of 20 randomly selected binary values (coin flips, true or
false, 1s and 0s..)..
There is a 50% chance that 4 items in a row will have the same value.

In other words, this will produce a false result:

10101010101010101010
And this a true one:
10101011110010101010
Because we have a streak of four 1s.
Daniel Kahneman and Amos Tversky, the "Two Friends Who Changed
The World," were the first to notice our bias in relation to this odd feature of
randomness when analyzing data from NBA players who were said to be
possessors of a "hot hand" because they managed to get many hoops in a row.
Kahneman and Tversky proved this was governed by randomness more than
anything specific to the players. After all, by way of competition, the NBA
made talent somewhat meaningless, something shared in roughly similar
amounts by the majority of the players; it's a leveled playing field as far as
talent goes. Randomness plays a much stronger role. The hoops in a row are
the same as the repeated random values in a sequence.
Once again, feel free to prove this using your own code. Create a sequence
using 20 randomly selected binary values (0s and 1s, for example) and then
search for a 4-item repetition inside the sequence.

I decided to create a string of values and then look for repetitions in the
string using one of my favorite Python features: the fact you can multiply
anything in Python.
import random

def createRandomString (len):

result = ""
for i in range (len):
result += str( random.randint(0,1) )
return result

num_tests = 1000
num_repeats = 4
streak = 0.0

for i in range(num_tests):
s = createRandomString(20)

if s.find("0" * num_repeats) != -1 or s.find("1" * num_repeats) !=

-1:
streak += 1

print (streak/num_tests)

"0" * 4 in Python results in "0000". Nice, isn't it? It's the little things that
truly matter in life. So I can look for num_repeats of "0" using:
s.find("0" * num_repeats) != -1

This will look for the substring "0000" inside s when num_repeats =
4, and if the index is not equal to -1, it means we found the substring. We got
our hot hand! You can build tests to identify sequences in any number of
items and any length of streaks.
I generate a string with 1s and 0s like this:
result = ""
for i in range (len):
result += str( random.randint(0,1) )
return result

But Python offers many shorter alternatives to do the same thing. As an

exercise can you think of a way to use map() for this? Here's a hint: you
may want to start with a string comprised of twenty spaces:
result = " " * 20

And map each index in the string to our random output.

Odd Thing Number Three: The Winner Takes It All!

Go ahead. Sing the ABBA song. I'll wait.
This one is the clincher, in my opinion.

Flip a coin ten thousand times.

The distribution of heads and tails will come close to 50%. The more
you play, the closer it gets to 50. But one of them usually beats the
other. Either heads or tails will win, not by much, but one is almost sure
to win.
Count the number of rounds the winner remained the overall winner
and...

Chances are the winner remained the overall-winner over 90% of the
rounds. 90!
Ready? How would you represent a coin flip? When I first coded this script
I did this:
flip = random.randrange(1,101) > 50

I felt the need to pick from a large range of values. I could not trust this to
work just as well:
flip = random.randrange(0,2) == 1

And I ended up building a test to check if there were any variation in the
results using one or the other. I couldn't trust myself. There wasn't a variation,
by the way.
Anyway, here is my code...
import random

num_tests = 10000

heads = 0.0
tails = 0.0

heads_wins = 0.0
tails_wins = 0.0

for i in range (num_tests):

if random.randrange(0,2) == 1:
heads += 1
else:
tails += 1

if heads > tails:

heads_wins += 1
elif heads < tails:
tails_wins += 1

print (heads)
print (tails)
print (heads_wins/num_tests)
print (tails_wins/num_tests)

As an exercise, you should run this test a thousand times and calculate the
number of times the winner remained the overall winner over, say, 75% of
the rounds.
 There shouldn't be a list of 7 habits of highly successful people. There
should be a list with one billion habits of highly successful people. These
would include: breathing, blinking, swallowing saliva, and the occasional
fart. Do all those things, and throw a lot of randomness into the mix, and you
too can be a successful person!
Guaranteed.
 6
Let's Ruin Magic
For our next trick…
When I was about five years old, one of my uncles showed me the Hotel
Room magic trick and it blew my little mind off its hinges. I tried to replicate
it and failed miserably of course, until my uncle took pity and told me the
two things I needed to remember in order to make it work. The trick goes like
this: You pick all four Queens, all four Kings, all four Jacks, all four Aces
and you tell a creepy little story about sexual harassment...

Once upon a time there was this shady hotel with four available
rooms. Four ladies arrived and each took a room; these are the
Queens. Then four old men (the Kings) arrived and asked for rooms
and the hotel owner suggested they share rooms with each of the
young ladies, thinking: old men = no harm. (Sure). Then four young
men (Jacks) arrived and the same thing happened. For some reason
four Aces arrived after this, I think they were the overcrowded-hotel-
room police or something and were there to either protect the Queens
or to protect the good name of the hotel. (Even at the tender age of
five, I suspected the reason had something to do with orgies, which at
that age I imagined it to have something to do with very loud
conversations). The police orders everybody out. This is when you
collect all the cards and magic commences! The person you're telling
the story to (the mark, the sucker... five-year-old me, in this example)
is asked to cut the deck a few times and then the magician says a
magic word and places the cards back into the four stacks (the 4
rooms). And voila! The four ladies are together in one room, the four
old men in another, the four young men in another and for some
reason, the police took the fourth room. I never understood that part
either.
 By the way, the two tips my uncle gave me were:

Collect the cards in equal stacks. For example, if the first four cards are
arranged as Q, K, J, A make sure all four stacks are collected in that
exact same order before you pile them together.
Cut the cards but don't shuffle them.

We'll use an online console again for this but this time I'll use the
JavaScript language. You should load this URL https://jsbin.com/?js,console
or go to https://jsbin.com and make sure the JavaScript and Console buttons
are selected and none of the others, to clear up some space. You will add your
code inside the JavaScript panel. In the real world, this code would go inside
an HTML page or inside a script file, usually saved with a .js extension.
JavaScript is a dynamically and weakly-typed, multipurpose, and multi-
paradigm language, once relegated to web browsers but which now can be
found everywhere—in part because HTML can be found everywhere
nowadays: games, mobile apps, desktop applications... It has nothing to do
with Java, just another badly named thing in the Computer World. It's
ridiculously popular and famous for being the headless chicken of
programming languages. Cut your JavaScript code's vital parts and it keeps
running even though it shouldn't; in most cases, it might not be running at all
but simply a local phenomenon which only you can see and experience. It's
that crazy at times. Naturally, everybody decided to use it!
Let's go over the logic of the magic trick and see what JavaScript is all
about. You could, if you wish, write the same thing using Python or C#,
translating the code as I list it here. But do notice how similar these languages
are. You should be able to understand what most of the code is trying to do.
We have four rooms.
var totalRooms = 4;

Each room will be a separate array contained within another array. This is
known as a two-dimensional array when a collection contains other
collections. So let me create this now:
var rooms = [];
var i = 0;
while (i < totalRooms) {
 rooms.push(new Array());
i++;
}

I could have done the above like this:

var rooms = [new Array(), new Array(),
new Array(), new Array()
];

Or even:
var rooms = [ [],[],[],[] ];

And then derive the number of rooms from rooms.length instead of

having a separate variable. Whatever. Arrays are mutable in JavaScript and
not type-safe at all. You can create collections containing different types if
you want.
I create a function to add guests to the rooms.
function addGuests (guest) {
var i = 0;
while (i < totalRooms) {
rooms[i].push(guest);
i++;
}
}

It takes a string for the Queen, King, Jack, and Ace. Again, this could be
written in various different ways. JavaScript has a forEach loop, for
instance, so we could have done the same thing like this:
function addGuests (guest) {
rooms.forEach (function (room) {
room.push(guest);
});
}

Notice that JavaScript's forEach loop is actually a higher-order function.

The syntax looks like this: array.foreach ( function (element)
{ } );.
I pass it a function as an argument which will run for every single element
in the array, and which has the element as its parameter. function
(element) {} is JavaScript's version of an anonymous function (lambda).
C# has a similar forEach loop using an anonymous function:
myList.ForEach ( (element) { } );

JavaScript has another version of the forEach method in case you need
the array index for anything:
array.forEach (function (element, index) { });

This can be helpful at times. And do you remember what we call methods
or functions that exist in multiple forms or versions? We say they're
overloaded.
I add the Queens to the "rooms".
addGuests("Q");

I add the Kings.

addGuests("K");

I add the Jacks.

addGuests("J");

And finally the Aces.

addGuests("A");

Next, I need to collect all the cards into one pile. I chose to do it with a
function that returns an array that combines all four rooms.
function collectCards () {

var result = [];

var i = 0;

while (i < totalRooms) {

var room = rooms[i];

room.forEach(function(card) {
result.push(card);
});
 i++;
}

return result;
}

Or we could have written two forEach loops, one inside the other.
Remember, you can nest anything in programming:
var result = [];
rooms.forEach ( function (room) {
room.forEach( function(card) {
result.push(card);
});
});
return result;

Another way to do this would be to concatenate the arrays, like we do with

strings. JavaScript can do this with the array.concat() method.
var result = [];
var i = 0;
while (i < totalRooms) {
var room = rooms[i];
result.concat(room);
i++;
}
return result;

And finally, we could combine the last two solutions, using a forEach
loop and array concatenation:
var result = [];

rooms.forEach ( function (room) {

result.concat(room);
});

return result;

Array.concat(Array2) takes the second array and adds its elements

to the end of the first one:
var one = [1,2,3,4]
var two = [5,6,7,8]
var concat = one.concat(two);
//concat = [1,2,3,4,5,6,7,8]

I use the collectCards() function to create our deck. The one we'll
cut and do our magic trick with.
var deck = collectCards();

I want to see what it looks like at this stage, so I'll write it to the console.
console.log(deck);

When you run the application, the code prints this to the console:
["Q", "K", "J", "A", "Q", "K", "J", "A", "Q", "K", "J", "A", "Q", "K", "J",
"A"]
At this point in the trick, I already fulfilled one of the rules. I collected the
cards following the same pattern: "Q", "K", "J", "A" in this case.

Note: Eventually, you'll want to clear the console of all log

messages, just use the Clear button you see at the top of the console.
And of course, keep clicking the Run button to run the code.

We want to cut the deck next, and do this a few times. So we make a
function for it:
function cutDeck (deck) {
var randomCount = Math.floor(
Math.random() * deck.length
);
if (randomCount == 0) randomCount = 1;
var cut = deck.splice(0, randomCount);
return deck.concat( cut );
}

We select a random count. In JavaScript Math.random() returns a float

value between 0.0 and 1.0, not including 1. I use that value to multiply the
length of our deck. So if random gives us the value 0.2, the random index
will be 0.2 * the length of the array. Since we can't use floats as array
indexes, I use another function from JavaScript's Math library:
Math.floor(). This will round the number down, turning it into an
integer in the process. So, in JavaScript if you want a random item from an
array you do it like this, in one line:
var item = array[ Math.floor( Math.random() * array.length) ];

Because Math.floor( Math.random() * array.length )

will return a value from 0 to array.length - 1, in other words the complete
range of indexes in the array (in JavaScript arrays are also zero-based).
Since it is possible to get 0 as a result, and we don't want to cut the deck on
the zero index (what would be the point?), in that case, I add one to my cut
index.
var randomCount = Math.floor(Math.random() * deck.length);
if (randomCount == 0) randomCount = 1;

I could handle this odd condition in one line when generating the random
index:
var randomCount = Math.floor( Math.random() * (deck.length - 1) ) +
1;

This way I'd get a value from 1 to array length - 1.

I use this count to Array.splice() the array.
var cut = deck.splice(0, randomCount);

With this line, I'm saying: remove all items from the deck array starting at
0 and taking randomCount items, and return that as a new array.
For instance, if I had this array:
var a = [1,2,3,4,5];

And I ran the following splice operation:

var b = a.splice(0, 3);

The array b would have these values: [1,2,3]

And array a would be left with: [4,5]
This is similar to slicing in Python and C#, but you can also use it to
"splice" new elements into an array at a specific index. So JavaScript's
splice combines insert and slice in one method.
At the end of the function, I return the recombined cut deck:
var cut = deck.splice(0, randomCount);
return deck.concat( cut );

This is equivalent to cutting a deck of cards, and putting the bottom portion
of the cut above the top portion, essentially switching the two parts.
Let's cut the deck a few times using that function and print the result to the
console each time:
deck = cutDeck(deck);
console.log(deck);

//["J", "A", "Q", "K", "J", "A", "Q", "K", "J",

// "A", "Q", "K", "J", "A", "Q", "K"]

deck = cutDeck(deck);
console.log(deck);

//["A", "Q", "K", "J", "A", "Q", "K", "J",

// "A", "Q", "K", "J", "A", "Q", "K", "J"]

deck = cutDeck(deck);
console.log(deck);

//["A", "Q", "K", "J", "A", "Q", "K", "J",

// "A", "Q", "K", "J", "A", "Q", "K", "J"]

Finally, we say the magic word:

function sayMagicWord () {
console.log("Pleeeeeeease!");
}

sayMagicWord();

And then we show our result with one last function. This one needs to take
the current deck and then distribute the cards back into the rooms (four
stacks). The first card goes to the first room, the second card goes to the
second room...:
function fillRooms (deck) {

rooms = [[],[],[],[]];

var i = 0;

while (deck.length > 0) {

rooms[i].push ( deck.shift() );
i = (i + 1) % rooms.length;
}

rooms.forEach( function (room, index) {

console.log("Room " + (index+1) + ": " + room);
});
}

Not surprisingly, there are a number of ways we could have written this last
function. I did it with a loop and with an Array.shift() method. I start
by clearing the rooms since we're refilling them with guests:
rooms = [[],[],[],[]];

I could have done this dynamically, using our number of rooms variable.
Can you think of a way? I could also have looped the rooms array and cleared
each internal array it contains.
Next, I set the room index to the first room, meaning this room will get the
first removed card:
var i = 0;

And then I loop until the deck is empty, using Array.shift() to

populate the room arrays. This method removes the first element in the array
and returns that element. So this next line is removing the current first card
from the deck array, reducing the deck in the process and adding that
removed card to rooms[i]:
rooms[i].push( deck.shift() );

I repeat this inside a loop until my deck is empty:

while (deck.length > 0) {
rooms[i].push (deck.shift() );
i = (i + 1) % rooms.length;
}

The way I'm updating i (using the modulo operator) is just a fancy way of
doing the following:
i++;
if (i == rooms.length) {
i = 0;
}

Because we need i to loop through the four rooms, going from 0 to 3

(rooms.length - 1) and then back to 0. If we don't wrap that index
value and just keep incrementing it we'll end up looking for room 5 or 6 or
7... and they don't exist. This will throw an error. Our old friend Null
Reference error. But this line:
i = (i + 1) % rooms.length;

Takes care of both incrementing i and making sure it wraps around the
length of the rooms array.
We finish the magic trick by making a call to:
fillRooms(deck);

The entire series of calls are, in order:

addGuests("Q");
addGuests("K");
addGuests("J");
addGuests("A");

deck = collectCards();

deck = cutDeck(deck);
deck = cutDeck(deck);
deck = cutDeck(deck);

sayMagicWord();
fillRooms(deck);

The resulting console log inside fillRooms()...

rooms.forEach( function (room, index) {
console.log("Room " + (index+1) + ": " + room);
});

... shows something like:

"Room 1: Q,Q,Q,Q"
"Room 2: K,K,K,K"
"Room 3: J,J,J,J"
"Room 4: A,A,A,A"

You can see that the secret, as my uncle said, was to collect the cards in the
proper order first and never shuffle. The "trick" is that the cut doesn't really
change anything because the values still wrap around inside the array
following a pattern as you can see in the console:
["J", "A", "Q", "K", "J", "A", "Q", "K", "J", "A", "Q", "K", "J", "A", "Q",
"K"];
All the cut does is change the order the cards will appear when placed
around the "four rooms" but will keep the pattern unchanged. As long as you
place a card in each room, going around the stacks, and keep distributing the
cards in the same order until the deck is finished, this will produce four stacks
of identical cards.
So much for my uncle's magic powers...
 7
Oh, Monty!
"Maybe women look at math problems differently than men."
Ouch. I still wince every time I read this. And then I smile.
I first learned about this story in the excellent book The Curious Incident of
The Dog in the Night-time by Mark Haddon. The main character in that book
is obsessed with odd mathematical problems and he mentions this one in
particular. It is known as the Game Show Problem or The Monty Hall
Problem.
The problem itself has many versions and it's quite old. But it became
famous in September 1990 when it was asked by a reader of a newspaper
column called Ask Marilyn; posed to the columnist herself Marilyn vos
Savant. She was famous for being included in the Guinness World Record as
the person with the highest IQ ever recorded. I happen not to believe much in
the standard IQ test. And I guess there was something of an As Seen On TV
genius about her. She seemed to be the Ginsu Knife of intelligent people, if
you know what I mean. For one thing, her last name sounded totally fake to
me. You're intelligent and your last name is Savant? Is this made up or
nominative determinism doing its thing too well?
But then there were those who picked on her answer for no better reason
than she was a woman. But boy, did she shut people up big time. And more
than that, she was absolutely gracious about it. If you want a feel-good story,
with some serious mansplaining at the heart of it, and don't know about The
Game Show Problem debacle, do yourself a favor and look for her original
posts in archive.org.
(https://web.archive.org/web/20130121183432/http://marilynvossavant.com/game-
show-problem/)
Here's the problem as originally stated:
 Suppose you’re on a game show, and you’re given the choice of
three doors. Behind one door is a car, the main prize. Behind the
others, goats. You pick a door, say # 1, and the host, who knows
what’s behind the doors, opens another door, say # 3, revealing one of
the goats. He says to you, "Do you want to switch to door # 2 or stick
to your first choice, door # 1?" The question is: Is it to your advantage
to switch your choice of doors?

People told Marilyn vos Savant there's a 50-50 chance at that stage in the
game, so there's no point in a switch. And she told them: nope, you increase
your chances if you switch. And you increase it by a lot. You pick a door.
The host reveals that another door you didn't pick doesn't have the prize and
Marilyn said if you switch doors, you're more likely to win now. Not only
that, but you're twice as likely to win.
The problem itself is somewhat similar to a paradox known as Bertrand's
Box, and that one had already been turned into The Three Prisoners Problem
published in one of Martin Gardner's books (I love those books!).
You know what will happen next, I'm sure. We'll write it in code, of
course. And since it's the Monty problem, we'll use Python again.
Once again, I want you to stop and think about how you'd write a test for
The Monty Hall Problem. The goal is to run a bunch of "games". Each game
has three doors, one containing a prize and two containing goats. The player
randomly selects one of them. Then we find another door with one of the
goats and reveal it to the player, basically removing it from the game. We
need to check whether it's true that by switching to the remaining door the
player doubles his chance of winning the game.
Can you think of a way to do all that?
Go ahead.

We need Python's random number generator. In python this must be

imported from a module as we've seen: import random
Now, let's define some properties.
numTests = 1000
winsWithSwitch = 0
wins = 0
 We'll keep track of the games the player would win with each strategy: by
switching doors, and by sticking to the first choice. Next, let's create a
function to run all the tests.
def runGames (numGames):

This function will eventually change the values of wins and

winsWithSwitch, which were declared in an outside scope. In Python, in
order to change values declared in global scope I must do this:
def runGames (numGames):
global winsWithSwitch
global wins

I must tell the function these properties I'm about to change were declared
in the global scope and should not be considered new variables declared
inside the function scope and which happen to have the same name as the
other variables. Why? Python did away with the var keyword and this
creates problems distinguishing between previously declared variables and
newly declared ones. Python has a harder time distinguishing between
reference and declaration. It leaves this problem to the user. You.
In our function, we'll create each game like this:
numTests = 1000
winsWithSwitch = 0
wins = 0

def runGames (numGames):

global winsWithSwitch
global wins
for _ in range(numGames):
game = [0,0,0]
game[random.randint(0,2)] = 1

By the way, I could also have written the globals like this, in one line:
global winsWithSwitch, wins

A game is an array with 3 zeroes, these stand for goats.

Next, I replace one of the zeroes with the prize, represented by 1. Now that
we have the game doors, we can make the player pick a door, also randomly.
doorIndex = random.randint(0,2)
del game[doorIndex]

We delete that door from the list using del. We just need to check the
value of the last remaining door to know if the player won or not, so it doesn't
matter what door the player picked at this point. We're not trying to win a car,
we're trying to prove a point.
We find one of the goats. There must be at least one at this stage. And we
also delete that index.
goatIndex = game.index(0)
del game[goatIndex]

We use List.index() which returns the first index of a value, in this

case, 0, which stands for goat. We delete that door so we can focus on the one
value we care for. Now the game has one door. If that door has a value of 1, it
means that the player would have won if he or she had made the switch.
If the door has a goat (0), it means the player picked the winning door the
first time around.
if game[0] == 1:
winsWithSwitch += 1
else:
wins += 1

And that's it for our function:

def runGames (numGames):
global winsWithSwitch
global wins

for _ in range(numGames):
game = [0,0,0]
game[random.randint(0,2)] = 1

doorIndex = random.randint(0,2)
pickDoor = game[doorIndex]
del game[doorIndex]

goatIndex = game.index(0)
del game[goatIndex]
 if game[0] == 1:
winsWithSwitch += 1
else:
wins += 1

All it's left for us to do is call it.

runGames(numTests)

And print the value we got from our games:

print("WINS: ", wins)
print("WINS WITH SWITCH: ", winsWithSwitch)

Here's the entire code:

import random

numTests = 1000
winsWithSwitch = 0
wins = 0

def runGames (numGames):

global winsWithSwitch
global wins
for _ in range(numGames):
game = [0,0,0]
game[random.randint(0,2)] = 1

doorIndex = random.randint(0,2)
pickDoor = game[doorIndex]
del game[doorIndex]

goatIndex = game.index(0)
del game[goatIndex]

if game[0] == 1:
winsWithSwitch += 1
else:
wins += 1
runGames(numTests)

print("WINS: ", wins)

print("WINS WITH SWITCH: ", winsWithSwitch)

You'll see that the values get pretty close to doubling, for the switch
strategy.
 8
Let's Ruin Magic... Again
With this next trick, things become way more interesting. For one, we need
a full deck this time. So let's make one very quick. I'll use JavaScript once
more.
var suits = ['d','h','s','c'];
var faces = ['A','K','Q','J','2','3',
'4','5','6','7','8','9','10'];

var deck = createDeck(suits, faces);

function createDeck (suits, faces) {

var result = [];

faces.forEach(function(face) {

suits.forEach(function(suit) {
result.push(face+suit);
});

});
return result;
}

console.log(deck)

/*
["Ad", "Ah", "As", "Ac", "Kd",
"Kh", "Ks", "Kc", "Qd", "Qh",
"Qs", "Qc", "Jd", "Jh", "Js",
"Jc", "2d", "2h", "2s", "2c",
"3d", "3h", "3s", "3c", "4d",
"4h", "4s", "4c", "5d", "5h",
 "5s", "5c", "6d", "6h", "6s",
"6c", "7d", "7h", "7s", "7c",
"8d", "8h", "8s", "8c", "9d",
"9h", "9s", "9c", "10d", "10h",
"10s", "10c"]
*/

console.log(deck.length);

//52

The suits stand for Diamonds, Hearts, Spades, and Clubs. We should end
up with a deck of 52 cards. One of the requirements for this trick to work is
that you must have a deck with an even number of cards. If you prefer, you
can create a deck with the numbers 1 to 52, but that's not as fun is it?
Next, we shuffle the deck.
deck = shuffle(deck);

function shuffle (deck) {

return deck.sort(function() {
return 0.5 - Math.random() }
);
}

This is a quick random shuffle algorithm for Javascript using the

Array.sort() method, which can take a sorting function (making
Array.sort() another higher-order function). The sorting function must
be a predicate. If you recall, a predicate is a function that will run on each
item of an array and make a decision regarding the item. A predicate will
usually return a boolean, like we've seen in filter methods, stating whether or
not an item should be added to the result array. With sorting of the sort (oh,
oh) we're using here, the predicate will return a 0, 1 or -1 to indicate the three
states of equality: equals to, larger than, less than. These values will
determine which of two elements in the array should come first or whether it
doesn't matter because the two elements are equal. You can write sorting
functions to sort strings alphabetically, or numerically, in ascending or
descending order, or in any number of ways described by your predicate. It
all depends on what condition will return 1, 0 and -1.
 The predicate I used returns 0.5 - Math.random(). This will
randomly return values that are negative something or positive something. It's
not the greatest shuffling method, but for our example, it's enough. The
sort() function will pick items from the array, always in twos, and
randomly decide which one is "greater" than the other, swapping elements
around based on this random decision.
Now comes the first essential part of the trick. You must cut the deck by
half. Exactly half.
function cutInHalf (deck) {
if( deck.length % 2 != 0) {
throw "We need an Even number Deck!";
}
var index = deck.length / 2;
var cut = deck.splice (0, index);
return {deck1: cut, deck2: deck};
}

var cut = cutInHalf(deck);

We use modulus again (%) to check if we have an even number of cards. If

the deck can't be divided by two (deck.length % 2 != 0), we throw
an error and the program stops dead. Throw is a special command that can
be used to print out a message in the console and stop the execution of our
program all at the same time. This is another form of defensive programming
and can be used to ensure that operations that can produce a blocking error in
a program will be handled properly.
Then we use our old friend, Array.splice() and we return what
JavaScript calls an Object. It's a key-value-pair data collection, not unlike a
Dictionary in Python or in C#. This means you can name your values
anything you want and then refer to them by name, using dot notation:
var you = {name : "John", surname: "Smith"};
console.log(you.name);
console.log(you.surname);

JavaScript Objects are not limited to storing one type only for its values,
and its keys have no type—they are variable names, rather. I use an Object in
the cut function to return the two halves:
return {deck1: cut, deck2: deck};

So now we have the deck cut into two equal stacks. We'll shuffle the first
one and use it to "ask the audience" to pick a card:
var cut = cutInHalf(deck);

var deckToPickCardFrom = shuffle(cut.deck1);

The other half-cut we'll use to find a "magic number". We shuffle that as
well:
var deckToPickNumberFrom = shuffle(cut.deck2);

In the real world, you would pick the half deckToPickCardFrom and
flip through the cards in such a way so that only the audience can see the
cards until they select one—which also should remain hidden to you, the
magician. After that, you place the chosen card at the bottom of the deck, still
making sure you don't see it. In the code, this looks less showbiz:
function pickACard (deck) {
var index = Math.floor(Math.random() * deck.length);
var pickedCard = deck.splice(index,1);
return pickedCard;
}

console.log("PICK A CARD, ANY CARD");

var pickedCard = pickACard (deckToPickCardFrom);

With this function, we're changing the deck being passed into it, by
removing a random card. We then add it back to the deck, to the end of the
array:
deckToPickCardFrom.push(pickedCard);

console.log("YOU PICKED THE CARD: " + pickedCard);

I log the selected card so I'll know the trick worked.

Next, in order to wow the audience, we throw in a fake shuffle:
deckToPickCardFrom = fakeShuffle(deckToPickCardFrom);

function fakeShuffle (deck) {

 var lastCard = deck.pop();
var deck = shuffle(deck);
deck.push(lastCard);
return deck;
}

Can you read in the code what the fake shuffle does? Yep, it keeps the
chosen card at the bottom of the deck, it only shuffles the other cards. It's not
that hard to do it in real life but in code, it requires zero practice and dexterity
(I can do it with one finger). Now we move to the second stack of cards we
got from our cut. This is the one we'll pick a number from.
First, we cut it:
var cut2 = cutDeck (deckToPickNumberFrom);

function cutDeck (deck) {

var index = Math.floor(Math.random() * deck.length);
if (index == 0) index = 1;
var cut = deck.splice (0, index);
return {deck1: cut, deck2: deck};
}

This cut can be random, just avoid 0 like we did last time in our previous
magic trick. As an exercise you might want to combine the cutDeck()
logic with the cutInHalf() logic, passing it a flag stating whether or not
the cut must be random or at exactly half. Or maybe pass it the percentage
value of the cut: 0.5 for the half and something random for the other cut.
One of the cuts will be used as The Magical Number, like this:
var number = cut2.deck1.length;

console.log("YOU PICKED NUMBER: "+ number);

I'll show you what we'll do with this number in a second. But the idea is to
count the cards from one of the stacks resulting from the audience's cut and
use that number later in the trick. The magician would make a big show of
counting the cards and then announcing the number the audience "picked",
even though it came as the result of this cut.
We pick the remainder cards from this second cut:
var remainder = cut2.deck2;

We concat() this remainder to our recently fake-shuffled deck, the one

the audience picked a card from:
var finalDeck = deckToPickCardFrom.concat(remainder);

The stack we counted to pick our magic number is discarded.

As a refresher, this is what we did with the cards so far:

The Magic Trick

With a complete deck, we cut it in half. Half A was used to randomly pick
a card from. Half B was cut randomly, one cut was used to determine a
Number, the other cut was added to Half A.
The second most important part of the trick comes now. We need to do a
special kind of shuffle known as the Klondike Shuffle. If you don't know what
that is, see if you can figure it out from the code:
finalDeck = klondikeShuffle(finalDeck);

console.log(finalDeck);

function klondikeShuffle (deck) {

var result = [];

var len = deck.length;
while (result.length < len) {
if (deck.length > 0) result.push(deck.pop());
if (deck.length > 0) result.push(deck.shift());
}
return result.reverse();

The Klondike Shuffle creates a new array of cards by removing the top card
and the bottom card from our original deck, and repeating this process until
we're through with the deck. The progression looks like this:
deck =[A,B,C,D,E,F,G,H,I,J]
shuffled = []

deck = [B,C,D,E,F,G,H,I]
shuffled = [A,J]

deck = [C,D,E,F,G,H]
shuffled = [B,I,A,J]

deck = [D,E,F,G]
shuffled = [C,H,B,I,A,J]

deck = [E,F]
shuffled = [D,G,C,H,B,I,A,J]

deck = []
shuffled = [E,F,D,G,C,H,B,I,A,J]

In my code I had to Array.reverse() at the end because I chose to

push the values, putting the new cards at the end of the resulting array and
not at the beginning, which is what the Klondike shuffle requires. JavaScript
allows you to use Array.unshift(), which is a command that adds
elements to the beginning of an array, removing the need for
Array.reverse():
function klondikeShuffle (deck) {
var result = [];
var len = deck.length;
while (result.length < len) {
if (deck.length > 0) result.unshift(deck.pop());
if (deck.length > 0) result.unshift(deck.shift());
}
return result;
}

It really doesn't matter. I just happen to find the name unshift silly. The
end result needs to match this transformation: from [A,B,C,D,E,F,G,H,I,J] to
[E,F,D,G,C,H,B,I,A,J] and however you choose to do it, it's fine.
Remember the number you got from counting the cards in the cut the
audience did earlier? You use that number with this final shuffled deck and
you flip the cards from the top, counting up to that number. For any number
n, the nth card in the pile is the same one the audience picked. Every time.
//use number-1 because array is zero-based
var yourCard = finalDeck[number-1];

console.log ("IS THIS YOUR CARD? " + yourCard);

Fun for all the family. Can you see in the code how the trick works? Print
out the arrays to the console as you do the cuts and after each iteration of the
Klondike shuffle and you'll see. If not, I'll give you a quick explanation at the
end of this chapter, but it's still easier to see it with the help of the arrays.
Here's the complete code:
var suits = ['d','h','s','c'];
var faces = ['A','K','Q','J','2','3','4',
'5','6','7','8','9','10'];

var deck = createDeck(suits, faces);

console.log(deck);
console.log(deck.length);

deck = shuffle(deck);

//cut in half
var cut = cutInHalf(deck);

var deckToPickCardFrom = shuffle(cut.deck1);

var deckToPickNumberFrom = shuffle(cut.deck2);

//pick a card
var pickedCard = pickACard (deckToPickCardFrom);

deckToPickCardFrom.push(pickedCard);

console.log("YOU PICKED THE CARD: " + pickedCard);

deckToPickCardFrom = fakeShuffle(deckToPickCardFrom);

//pick a number
var cut2 = cutDeck (deckToPickNumberFrom);

var number = cut2.deck1.length;

console.log("YOU PICKED NUMBER: "+ number);

var remainder = cut2.deck2;

var finalDeck = deckToPickCardFrom.concat(remainder);

finalDeck = klondikeShuffle(finalDeck);

console.log(finalDeck);

var yourCard = finalDeck[number-1];

console.log ("IS THIS YOUR CARD? " + yourCard);

function klondikeShuffle (deck) {
var result = [];
var len = deck.length;
while (result.length < len) {
if (deck.length > 0) result.push(deck.pop());
if (deck.length > 0) result.push(deck.shift());
}
return result.reverse();
}

function fakeShuffle (deck) {

var lastCard = deck.pop();
var deck = shuffle(deck);
deck.push(lastCard);
return deck;
}

function pickACard(deck) {
var index = Math.floor(Math.random() * deck.length);
var pickedCard = deck.splice(index,1);
return pickedCard;
}

function cutDeck (deck) {

var index = Math.floor(Math.random() * deck.length);
if (index == 0) index = 1;
var cut = deck.splice (0, index);
return {deck1: cut, deck2: deck};
}

function cutInHalf (deck) {

if( deck.length % 2 != 0)
throw "We need an Even number Deck!";
var index = deck.length / 2;
var cut = deck.splice (0, index);
return {deck1: cut, deck2: deck};
}

function shuffle (deck) {

return deck.sort(function() {
return 0.5 - Math.random() });
}

function createDeck (suits, faces) {

var result = [];
faces.forEach(function(face) {
suits.forEach(function(suit) {
result.push(face+suit);
});
});
return result;
}

One interesting side-note. When I first wrote the Klondike algorithm, I

wrote it like this:
function klondikeShuffle (deck) {
var result = [];
while (deck.length > 0) {
result.push(deck.pop());
result.push(deck.shift());
}
return result.reverse();
}

Can you spot my mistake? JavaScript didn't crash, unlike most other
languages, which made it a bit harder for me to find the error in my logic, in a
process commonly known as debugging. I noticed in the console the shuffled
array would sometimes start with a comma: ,2d,3s...
I got this every time the values didn't match at the end of the trick—when
the picked card and the one revealed weren't the same. But with the help of
the console I also noticed that when I failed to pick the card, I was always off
by one. So of course that extra comma meant the algorithm was adding an
element, an empty one, at the beginning of the array. And sure enough, when
I counted the array going in and the one coming out, I found that when the
error happened an array with x elements would go in, and an array with x+1
elements would come out. But not all the time. Sometimes, the code just
worked.
"What gives?" thought I. The problem was that sometimes I needed to
Klondike shuffle arrays with an odd number of elements. So in the last
iteration, after I did a pop(), there was nothing to shift() because the
array had run out of elements. JavaScript, with its enormous heart, was
adding an undefined element to the result array under that condition. Trying
to spare me, I guess.
Other languages would crash with a Null-pointer error, and I'd be alerted to
the problem much earlier. Browsers can be told to ignore these errors or not,
so JavaScript can go on ticking as if nothing happened and ruining magic for
everybody.
So I changed the algorithm to this, the final version:
function klondikeShuffle (deck) {
var result = [];
var len = deck.length;
while (result.length < len) {
if (deck.length > 0) result.push(deck.pop());
if (deck.length > 0) result.push(deck.shift());
}
return result.reverse();
}

But that was overkill. I guess I panicked. I could have used most of the
original logic, and just account for the "Odd Number Of Items" condition
inside the while loop.
Now go out there and wow people with your magic code.
Also, go to YouTube and do a search for simple card tricks, the ones said
not to require sleight of hand—these tricks are based on good old math. Then
transform them into code, using your favorite language. It's one of the best
ways to practice and learn a new language since it will certainly involve all
major elements in programming: manipulating data inside collections in
specific ways and matching the result against specific conditions.
Plus, you know, it's magic! Good times.

And by the way, did you notice how this second magic trick works?
You have three stacks of cards, A, B, and C. The length of B + length of C
equals the length of A. This is important. It's why we cut the deck in half at
the beginning and therefore why the deck must have an even number of
cards.
 At the bottom of the largest pile, A, you have the picked card. You then
place that on top of pile B.
With Klondike, we remove a card from the bottom of the pile and one from
the top. So by the time we reach the picked card we removed a B amount of
cards both from the top and from the bottom. This leaves the pile with the
same amount of cards as pile C, which we use as the magic number, on top of
the picked card. We continue on with Klondike until all cards are shifted, but
by now the picked card is already buried under the same amount of cards pile
C has.
It's all math. And simple math at that. Divisions and subtractions. Who
knew.
 9
The Shape Of The Planet
Once upon a time, there was this famous painter from Florence, Italy, who
dabbed in all sorts of disciplines and subjects. A meddler, they called him. I
guess. One day he decided to figure out for himself the shape of the planet.
He knew it was round, like a circle, from eclipses and the funny tricks played
by the horizon. But he didn't know whether it was a disk, like a coin, a
mound, like a hill, or something else entirely. So he got to thinking. Back in
the 15th century, when he lived, this was still a thing: thinking. He did loads
of it. As a matter of fact, because thinking was such a rage back then, people
already knew the shape of the planet but this Italian painter wanted to prove it
for himself. A rebel, they called him. I guess. His reasoning was quite
beautiful if you like that sort of thing:

He knew if he dropped something, let's say a pebble, the pebble rushed

towards the ground.
Since all pebbles he dropped did the same thing, no matter where he
was, they must be moving towards the same place, the same point. He
never once dropped a pebble and the thing showed any confusion or
hesitation to where it must go; which was bound to happen if there were
multiple possible destinations for the pebbles to go to. Therefore, one
single destination. A point.
He also noticed all pebbles moved towards this point via the shortest
route possible. No zigzagging!
So he concluded: if all things on earth were doing the same thing all the
time, moving towards the same point via the shortest route possible,
there was only one shape the earth could be.

So, what is that shape?

Note: I mentioned the book and the movie The Martian a few
 chapters back, and I just wanted to point out that the movie in
particular is a major spoiler alert for what we'll be figuring out in this
chapter. It shows Earth from space, which is a huge giveaway.

Note: We'll be doing this in 2D so the result will be two-

dimensional; if anyone concludes from this the planet is two-
dimensional, I want them to take a long look at themselves... Because
they wouldn't be able to if space were two-dimensional.

Note: I was going to call this chapter The Da Vinci Code, but then I
didn't, out of respect for you in particular.

We'll need to do some drawing and for that, we'll use JavaScript. Head over
to https://jsbin.com/ and in the middle of the screen select the options:
JavaScript, Console and Output. The drawing bit of the code will be new to
you, but otherwise, this is all old hat. Oh, and there will be math ahead. Quite
a bit, but fret not.
Let's start by creating some space:
var width = 1200;
var height = 800;

Those units are in pixels. If your monitor is particularly tiny, you can
reduce those numbers a bit.
Alternatively, you can create a text file inside a new folder in your
computer, name the file something.html and add this to it:
<html>
<body>
<script src="something.js"></script>
</body>
</html>

Inside the same folder, create a new text file and name it something.js.
Write the code to this file, save it and open the HTML page in a browser.
Refresh the page to see new changes applied.
Next, we create something we can draw on:
var canvas = document.createElement("canvas");
canvas.id = "myCanvas";
canvas.width = width;
canvas.height = height;
document.body.appendChild(canvas);

var ctx = canvas.getContext("2d");

JavaScript was born in close relationship with HTML pages and browsers,
although nowadays it can exist on its own. It has an entire suite of properties
and commands related to HTML, so when I say:
document.createElement("canvas");

This JavaScript, which happens to be attached to an HTML document, will

create an HTML element of type canvas inside this document:
<canvas></canvas>

The keyword document refers to the page the script is attached to, and
the createElement() method belongs to the document object. These
other commands:
canvas.id = "myCanvas";
canvas.width = width;
canvas.height = height;

Will result in an HTML element that looks like this:

<canvas id="myCanvas" width="1200" height="800"></canvas>

This will be created through the code and placed inside the HTML body
tags because in the code I used the instruction
document.body.appendChild() :
<body>
<canvas id="myCanvas" width="1200" height="800"></canvas>
</body>

JavaScript can create HTML tags before a page is loaded, essentially

building an entire page, or parts of it, through code. And with the last line:
var ctx = canvas.getContext("2d");

We grab something called the 2D Context of the canvas object we created

so we can draw on. Remember, all this is API stuff and has nothing to do
with programming as such. We're stuck with what other people decided to
call things and how they decided things should work, so don't panic.
Programmers often call this, "boilerplate code", meaning the code you need
to go through in order to appease some library and before you can do your
own thing or accomplish the thing the library was built for. Rather like
bureaucracy. We need to go through these particular steps in order to draw. If
you don't feel like memorizing this stuff, don't bother. Whenever I need to
draw something in JavaScript, which is rare, I end up Googling all this API
code (I have more important memories to keep). And by the way, we could
have added the canvas element to our HTML ourselves and then grabbed the
2D context like this:
var canvas = document.getElementById("myCanvas");
var ctx = canvas.getContext("2d");

In this case, the canvas element in the HTML would need to have the
right id, myCanvas, in order for this to work. But why work on two things
when you can work on one?
And just what is the canvas? This is an HTML element you can add to your
page to draw stuff on. You can use it to show images and videos as well. It
contains a property known as 2D Context you can use to draw two-
dimensional graphics (and also a 3D context called "webgl", because why
would anyone use names that make sense?).
We'll try to follow Da Vinci's reasoning as closely as possible with our
code. So we need pebbles. Lots of pebbles! And that means a collection of
pebbles.
var pebbles = [];

These pebbles will move at a certain speed towards a point.

var speed = 20;
var center = {x: width / 2 , y: height / 2};

I used a JavaScript key-value pair object to create a point, with an x and y

values. Why x and y? I'll show you in a bit. We start with the point center
in the middle of the canvas so x and y will be set to the width and height of
the canvas divided by two.
Next, we create our pebbles. Five hundred should do:
for (var i = 0; i < 500; i++) {
var radius = 2 + Math.random() * 10;
pebbles.push( {x:0, y: 0, radius: radius} );
}

Notice the use of the old-school for loop for (var i = 0; i <
500; i++). It says: with variable i starting at 0, and incrementing until it
reaches 499, run the following block using the different values for i (or not)
in each iteration.
I decided that our pebbles need three properties:

Two for the x and y position.

And one for the radius, because I decided the pebbles should be of
different sizes. The radius is at least 2.something pixels and at the most
11.99999999...

One of the great things about JavaScript is the ability to easily create
complex key-value pair objects like:
var pebble = {x:0, y: 0, radius: 20};
console.log(pebble.radius);

So why an x and y for the position? For this, we have a mathematician to

thank. He devised a way to place things in two-dimensional space known as
Cartesian coordinates:
 Points in Cartesian Coordinates

Every point has an x and y component describing its location in relation to

the two axes. The horizontal one is called the x-axis and the vertical one the
y-axis. This is what your computer monitor uses in order to place things on
the screen. Every object in your monitor will have its position described as x
and y components, like ships in a battleship game.
It's common to use pixels as the unit of measurement when addressing
points. If your monitor is set to a resolution of 1600 x 900 pixels, for
instance, this means it will have 1600 pixels on the x-axis and 900 pixels on
the y-axis. Place something at position x = 1650 or y = 1000 and this
something will not appear on your screen. In the same way, objects may be
hidden when placed in negative x or negative y.
 Objects on the screen

These are known as Cartesian coordinates because the dude who said "I
Think Therefore I Am" came up with them. (I don't know why I feel like I
should tell you this, but for the sake of full disclosure: He was French).
If you intend to work with graphical user interfaces in your programming
adventures, working with Apps or Games, for instance, you will have to deal
with x and y coordinates all the time. That's how buttons, text, menus,
images... are placed on the screen.
The 0,0 origin point may be placed at different spots on your screen,
depending on the language or program you're using. The origin will be placed
either at the top-left corner or bottom-left corner. The JavaScript canvas has a
top-left origin. So a (100,100) coordinate will be placed at 100 pixels on the
x-axis and 100 pixels on the y-axis, measured from the top left corner of the
canvas object:
 Canvas Point (100, 100)

With our canvas, I created a "drawing board" with 1200 pixels on the x-
axis and 800 pixels on the y-axis. Even if your monitor has a higher
resolution, items placed inside this canvas at x > 1200 or y > 800 will not
appear on screen or might be cut-off. The same thing goes for negative x or y
values.
Back to our pebbles... Let's draw them to the canvas. But first, let me make
a change to the way they're initialized.
for (var i = 0; i < 500; i++) {
var radius = 2 + Math.random() * 10;
pebbles.push( {x: width * Math.random(),
y: height * Math.random(),
radius: radius} );
}

I'll use Math.random() to distribute them all over the canvas so we

don't draw all the pebbles on the same spot. By multiplying the canvas width
and height by Math.random() I get a random range of values from
0.something% to 99.9999% of the total length of the width and the height,
essentially distributing the positions randomly across the canvas.
And how can we draw the pebbles? I'll write a function that loops through
the pebbles and draws them to the 2d context using the drawing API provided
by JavaScript:
function draw() {

ctx.clearRect(0, 0, width, height);

pebbles.forEach ( function (pebble) {

ctx.fillStyle = "#FFA500";
ctx.beginPath();
ctx.arc(pebble.x,
pebble.y,
pebble.radius,
0,
2 * Math.PI);
ctx.fill();
});
}

So what is going on here? First off, most of the code here is pure API stuff,
meaning this is how JavaScript draws circles and we must appease the API.
The first line clears the canvas, so whatever we drew before gets erased,
reinforcing the illusion of animation rather than a series of overlapping
snapshots because once we start changing the x and y value of each pebble,
they'll appear as if they're moving across the canvas.
We loop the pebbles and draw circles for each one, filling them with an
orange color represented by a hexadecimal value "#FFA500". You can
stroke, fill, or both any shape you draw. By using context.fill()
I'm choosing to fill the drawings, with the fill color I specified. The reason I
repeat the fillStyle() line for each pebble is that, in a moment, we'll add
logic to pick a random color for each pebble and get rid of all this orange. But
for now, let's continue with the drawing logic.
context.beginPath() initiates a new drawing, we're letting
JavaScript know we wish to draw a path, a shape in this case. We use the
context.arc() method used to draw arcs (fractions of a circle). The
parameters are: x and y position of the center of the arc, the arc radius, the
angle at which the arc starts, and the angle at which the arc ends. In order to
draw a full circle, you give it 0 for the start-angle and 2 times PI for the end-
angle. Angles can be measured in degrees from 0 to 360 or in radians from 0
to 2 * PI. Computers will use both units for different reasons. Here,
JavaScript wants an angle in radians. We finish each drawing by filling it.
Again, this is how JavaScript decided to do it. Some languages will have a
method specific for drawing circles and a separate one for arcs, but
JavaScript decided to combine the two. We could easily implement our own
draw circle function. It would look something like this:
function drawCircle (context, x, y, radius, color) {
context.fillStyle = color;
context.beginPath();
context.arc(x, y, radius, 0, 2 * Math.PI);
context.fill();
}

If we wanted a random color we could write a function that creates a

random hex string:
function getRandomColor() {
var letters = "0123456789ABCDEF";
var color = "#";
for (var i = 0; i < 6; i++) {
color += letters[Math.floor(Math.random() * 16)];
}
return color;
}

It generates a string starting with # and containing 6 characters randomly

selected from the hexadecimal sequence 0123456789ABCDEF. Why six?
Two for red, two for green and two for blue. Computers use a range of 256 (0
to 255) values for each one of these colors and you can use 2 hex symbols to
represent values up to 255. FF, with F standing for 15 as you recall, and
therefore FF = 15 * 1 + 15 * 16 = 255.
And now we can change the color of the pebbles in the
context.fillStyle property:
function draw() {
 ctx.clearRect(0, 0, width, height);
pebbles.forEach ( function (pebble) {
ctx.fillStyle = getRandomColor();
ctx.beginPath();
ctx.arc(pebble.x,
pebble.y,
pebble.radius,
0,
2 * Math.PI);
ctx.fill();
});
}

Or we could add the color to the pebble object when we first create them:
pebbles.push( {x:0, y: 0, radius: radius, color: getRandomColor()} );

And draw them like this, instead, referring to their color property:
function draw() {
ctx.clearRect(0, 0, width, height);
pebbles.forEach ( function (pebble) {
ctx.fillStyle = pebble.color;
ctx.beginPath();
ctx.arc(pebble.x,
pebble.y,
pebble.radius,
0,
2 * Math.PI);
ctx.fill();
});
}

OK. So far our program looks like this:

var pebbles = [];
var width = 1200;
var height = 800;
var center = {x: width * 0.5, y: height * 0.5};
var speed = 20;

var canvas = document.createElement("canvas");

canvas.id = "myCanvas";
canvas.width = width;
canvas.height = height;
document.body.appendChild(canvas);
var ctx = canvas.getContext("2d");

for (var i = 0; i < 500; i++) {

var radius = 2 + Math.random() * 10;
pebbles.push({x: width * Math.random(),
y: height * Math.random(),
radius: radius,
color:getRandomColor()});
}

draw();

function draw() {
ctx.clearRect(0, 0, width, height);

pebbles.forEach (function (pebble) {

ctx.fillStyle = pebble.color
ctx.beginPath();
ctx.arc(pebble.x,
pebble.y,
pebble.radius,
0,
2 * Math.PI);
ctx.fill();
});

function getRandomColor() {
var letters = "0123456789ABCDEF";
var color = "#";
for (var i = 0; i < 6; i++) {
color += letters[Math.floor(Math.random() * 16)];
}
return color;
}
 And it produces this result (don't forget to call draw() at some point in
your code):

Randomly placed pebbles

Cool. Just like that Sony Bravia commercial. Now we need a function to
move the pebbles towards our center point. If you don't like math take a deep
breath because we will need some Trigonometry here, I'm afraid. I will add
the explanation for the math we'll use at the end of this chapter. I've said
before you don't need to know math in order to become a programmer and I
meant it. I've worked with programmers in the game industry who treated the
things we're about to code as one treats an odd-looking API, like the ones
we've used for drawing or loading files. They simply memorized the steps
necessary to achieve these goals.
Here's the function I wrote to move the pebbles towards the center point,
updating the x and y of each pebble so that when we draw them, they appear
to be moving:
function moveTowardsCenter () {

pebbles.forEach (function ( pebble ) {

var diffx = center.x - pebble.x;
var diffy = center.y - pebble.y;
var angle = Math.atan2(diffy, diffx);
pebble.x += speed * Math.cos(angle);
pebble.y += speed * Math.sin(angle);
});
}
 So what's going on inside that for loop? What does it look like to you?
Greek?! That's right! Greek math. Well done.
We want this to happen:

Object P1 moving towards target

We want to move a pebble towards a point. Not place the pebble on the
point, but gradually move it towards it. If the movement were all vertical or
all horizontal, nothing could be simpler. We'd only need to change x or y by a
little bit each time to achieve our goal. I determined the speed to be 20 pixels,
so in each iteration, the pebble would change its x or y by 20 pixels. But what
if the movement needs to occur on a slanted path? If I move the pebble by 20
pixels on a slanted path what would be the values for x and y corresponding
to this new position? This is the problem math solves for us. Math says we
need to break this into two steps:

Find the angle of that slanted line.

Use that angle and the amount you want to move by to determine the x
and y values using certain ratios.
 The reason this solution is the best one is that it works for all instances,
even if the pebble is moving only on the x or only on the y axis. In JavaScript
we find the angle like this:
var diffx = center.x - pebble.x;
var diffy = center.y - pebble.y;
var angle = Math.atan2(diffy, diffx);

If you're really curious about what the math is doing here, you can read the
explanation at the end of this chapter. But for now, keep in mind you need to
feed the Math.atan2() function the difference in the y and the difference
in the x positions between center point and pebble:

X and Y difference between two points

This gives you the angle of the slanted line in radians. In JavaScript you
find out where 20 pixels along that slanted line will fall (the x and y values
for that point) by using:
pebble.x += 20 * Math.cos(angle);
pebble.y += 20 * Math.sin(angle);
 You use Math.cos() for the x value and Math.sin() for the y value.
This is used in games a lot. If a bullet moves at an angle A (in radians) with a
speed of 100 pixels, it will move like this:
bullet.x += 100 * Math.cos(A);
bullet.y += 100 * Math.sin(A);

Moving 100 units along an angle A will add a certain value to the bullet's
current x and y position.
And just to show you how common these math libraries are, here is the
same logic used in the moveTowardsCenter() function, but this time in
Python:
import math

for pebble in pebbles:

diffx = center.x - pebble.x
diffy = center.y - pebble.y
angle = math.atan2(diffy, diffx)
pebble.x += speed * math.cos(angle)
pebble.y += speed * math.sin(angle)

And in C# :
pebbles.ForEach(
(p) => {
var diffx = center.x - pebble.x;
var diffy = center.y - pebble.y;
var angle = Math.Atan2(diffy, diffx);
pebble.x += speed * Math.Cos(angle);
pebble.y += speed * Math.Sin(angle);
}
);

We need a way to animate the pebbles and this means we need to be able to
clear the canvas and redraw it. But right now we're only drawing it once.
How can we change that? In JavaScript you can tell the window object (the
browser's window in this case) to call a function just as it's ready to repaint
the screen:
window.requestAnimationFrame();
 We need to pass it the function we want the window to call:
window.requestAnimationFrame(update);

function update() {

moveTowardsCenter();

draw();

window.requestAnimationFrame(update);
}

Do you see the trick there that makes animations possible? What this will
do is call our function update() and inside that function we sign up to the
same window notification again which will call update() before the next
repaint, essentially creating a loop. This is one-way animations are created
inside web pages using JavaScript.
Inside update(), we can call the moveTowardsCenter() and the
draw() functions. This will update x and y of the pebbles, clear the canvas
of any previous drawings and redraw the pebbles in their new positions.
Animation!
If you were to run this application now you would see all the pebbles
eventually occupying the same point in space once they reached the center
point. But this does not happen in the real world. We need to write a function
that keeps the pebbles from running into each other. We need a function to
check collisions between the pebbles. The function takes two pebbles and
separates them if they overlap. More math ahead:
function checkPebbles (pebble1, pebble2) {

var diffx = pebble2.x - pebble1.x;

var diffy = pebble2.y - pebble1.y;

if (diffx * diffx + diffy * diffy >=

(pebble1.radius + pebble2.radius) * (pebble1.radius +
pebble2.radius) )
return;
 var angle = Math.atan2(diffy, diffx);
pebble1.x = pebble2.x - (pebble1.radius + pebble2.radius) *
Math.cos(angle);
pebble1.y = pebble2.y - (pebble1.radius + pebble2.radius) *
Math.sin(angle);
}

What we need to do here is:

Find the distance between the two pebbles.

If this distance is less than the sum of their radii, this means they've
collided and their positions are overlapping.
If that's the case, move one of the pebbles away by precisely the amount
of the sum of their radii (making them touch each other but not overlap).

For the last step, we use most of the math we used before when moving a
pebble towards a center point. Only here, we're moving it away from a point.
We once again determine the angle, this time between the two pebbles, using
Math.atan2():
var diffx = pebble2.x - pebble1.x;
var diffy = pebble2.y - pebble1.y;
var angle = Math.atan2(diffy, diffx);

And we find the new x using Math.cos(angle) and the new y using
Math.sin(angle).
pebble1.x = pebble2.x - (pebble1.radius + pebble2.radius) *
Math.cos(angle);

pebble1.y = pebble2.y - (pebble1.radius + pebble2.radius) *

Math.sin(angle);

I chose to move pebble1 using the position of pebble2 as a starting

point. And this time, instead of using the 20-pixel speed to move the pebble, I
used the sum of their radii to make them touch each other but not overlap.
But remember, we only get to this last step of moving the pebble away if
the distance between the two is less than the sum of their radii.
 Distances between pebbles

How do we find the distance between two points? Once again, if they were
separated vertically or horizontally we could simply subtract their x or y
values and get the distance that way. But if they're separated at a slanted
angle, we need Pythagoras famous law to help us find the length of that
slanted line. For this, it helps us to see our distance problem as a triangle
rectangle:
 Distance between two pebbles seen as a triangle

Pythagoras said of triangle rectangles: the squared distance equals the sum
of x squared and y squared. Well, I paraphrased him a bit. He said this
essentially:
var x = pebble2.x - pebble1.x;
var y = pebble2.y - pebble1.y;
var distance = Math.sqrt ( x * x + y * y );

This is Pythagoras law written in JavaScript using our pebbles as an

example. Pythagoras says:
distance * distance = x * x + y * y;

So in order to find the distance, I'd need to get the square root value of the
right side of the equation.
But I don't need to do this here because I know what the ideal distance
should be and because I'm not trying to find out the exact length of the
slanted line but whether or not the length is greater or equal the ideal length.
In this example, if the distance happens to be greater than the sum of the
radii, I don't need to bother with the pebbles, because in that case, they are
not colliding.
This is why I do this:
if (diffx * diffx + diffy * diffy >=
(pebble1.radius + pebble2.radius) * (pebble1.radius +
pebble2.radius) )
return;

I called the x and y side of the triangle diffx and diffy respectively.
And diffx * diffx + diffy * diffy is the right side of that
Pythagoras equation:
distance * distance = x * x + y * y;

So if that side of the equation is greater or equal the ideal distance, which is
the sum of the radii, I'm good. And I need to use the sum of the radii squared
because that's what the left side of the equation says:
distance * distance
Therefore, using the ideal distance:
(pebble1.radius + pebble2.radius) *
(pebble1.radius + pebble2.radius)
Or if you prefer: Math.pow(pebble1.radius +
pebble2.radius, 2).
And this is what's going on here:
function checkPebbles (pebble1, pebble2) {

var diffx = pebble2.x - pebble1.x;

var diffy = pebble2.y - pebble1.y;

if (diffx * diffx + diffy * diffy >=

(pebble1.radius + pebble2.radius) * (pebble1.radius +
pebble2.radius) )
return;

var angle = Math.atan2(diffy, diffx);

pebble1.x = pebble2.x - (pebble1.radius + pebble2.radius) *
Math.cos(angle);
pebble1.y = pebble2.y - (pebble1.radius + pebble2.radius) *
Math.sin(angle);
}

Now we can run a check on all pebbles, calling checkPebbles() inside

a separate function:
function checkCollisions () {
for (var i = 1; i < pebbles.length; i++) {
var pebble1 = pebbles[i];
for (var j = 1; j < pebbles.length; j++) {
if (i != j) {
var pebble2 = pebbles[j];
checkPebbles(pebble1, pebble2);
}
}
}
}

We start with the second pebble and check it against every other pebble.
We skip the first one because we can safely assume the first pebble is okay,
and live with it if it isn't. This type of check won't be enough to fix all issues.
Once we move an overlapping pebble we might place it on top of another and
only fix that in the next iteration. But for our purposes, this check will be
good enough. If we were coding this inside a game we'd use something called
a physics engine to guarantee that all objects are spaced evenly, using a more
complex algorithm than the one used here.
I used the old for loop in that function, but I could have used the forEach
like this:
function checkCollisions () {
pebbles.forEach( function (pebble1, i) {
if (i > 0) {
pebbles.forEach( function (pebble2, j) {
if (j > 0 && j != i) {
checkPebbles(pebble1, pebble2);
}
});
}
});
}

Using the version of forEach that provides the anonymous function with
an index.
If you run this in your browser the result ought to be quite pleasing, if not
necessarily a huge surprise: The earth is a sphere. Every speck of dust is
moving towards the same point and trying to get there by the shortest route,
pushing each other like animals! Well, to be completely honest, the actual
shape is a spheroid. If you mess about with the size of the pebbles and
quantities you'll get all sorts of weird asteroid-like shapes. The key elements
here are the overall volume of stuff and consequently the power behind the
pulling. I mean, the earth is quite big in case you haven't noticed, many times
bigger than the thing we did just now in JavaScript inside a 1200 by 800-
pixel canvas. And with something that massive it's a cert you'll end up with a
sphere.
But then again, we could change our code so that when you click your
mouse somewhere else on the canvas the whole thing shifts towards that
point like a swarm of bees and that would look many times cooler than
anything we can do with the Earth.
How?
We can redefine the center point's position when we click on the canvas
with our mouse, by adding this to our code:
window.onmouseup = function (e) {
center.x = e.clientX;
center.y = e.clientY;
}

We're using window again to hook up to an event: onmouseup. I've said

before that programming is all about strings, numbers and booleans and even
when we create more complex types we're still mainly dealing with strings,
numbers, and booleans. We've seen a great deal of these three elements in our
code and events are really a kind of super boolean. Think of a blinking light:
It has two states, on and off, 1 or 0, or true or false. An event is a signal
notifying one of those two states, or both of them, or any change in the state.
This notification often carries some extra information but the event itself can
be thought of as a signal of booleans. With mouse clicks, we could have a
stream like:
 00000X00000XXXXX0000000X000000000X00000000X
With x representing a click, and O representing the lack of a click across
time. The onmouseup notification is triggered when the mouse button is
released after clicking on the browser window and it carries with it an event
object that contains all sorts of information related to that specific event, like
the x and y screen position of the mouse when the mouse button was
released. You don't need to worry about the logic that generates mouse-click
events, because this is one of the many events JavaScript can "notify" your
code of. When we write something like this:
window.onmouseup = function(e) {}

We're writing the event handler: The function we want to run whenever our
window object receives a notification of this particular event. Events are a
huge part of programming when working with client applications like
websites, games, or apps. You will often "hook" your own logic to various
types of notifications; these can be key-presses, screen touches, or when an
application has started running or is about to close. In a previous example,
when we listened to user input in the console, we used a form of event that
blocks execution until the application is notified of a certain key-press. But in
general, events don't need to be blocking operations and may run parallel to
your code like a subroutine.
Now, when you run the application and click somewhere in the canvas the
whole mass of pebbles will shift towards that point.

As an exercise, you could add the concept of a core. The area so tightly
packed with the tinniest stuff nothing else can move through it. Say this core
has a depth of one hundred pixels:
var core = 100;

And nothing can move past this tightly-packed boundary around the center
of the earth. You would only need to change one function to add this to your
logic: moveTowardsCenter(). And you'd get a result like this:
 The planet's core

Not surprisingly, the core too takes the shape of a sphere.

Not bad for an artist named after a turtle.

So what made Math.atan2() give us an angle and Math.cos() give

us the x position while Math.sin() gives us the y? It's called
Trigonometry. And trigonometry is all about ratios. Like the ones we saw in
our conversion code:
weightOnMars = 0.38

This time not related to your weight on Mars but distances (lengths) and
other magnitudes in geometric shapes, particularly triangles.
The Pythagoreans identified all sorts of relationships (or ratios) the lines
and the angles in a triangle rectangle have with each other. A triangle
rectangle is a triangle with a 90-degree angle.
 For instance:

The three triangles

Look at the three triangles marked in the image: ABC, ADE, AFG. All
three have the same angle ø. The ratios in this triangle dictate that with an
angle ø when the horizontal (x) line reaches point C, the slanted line will
reach point B at a certain height (y) in order to create a 90-degree angle
between horizontal and vertical lines. It's a rule of three all over again.
Increase one side, and the other grows proportionally and this ratio is related
to the angle.

with angle ø when x = 10 => y = 20

with angle ø when x = 15 => y = ?

Trigonometry has funny names for the ratios: sine, cosine, tangent, arc-
sine, arc-cosine, arc-tangent. And why so many ratios? Because depending on
what you know about the triangle, you'll have to use different ratios to find
out the thing you don't know. The basic elements, as I said, are the length of
x, the length of y, the length of the slanted line, and the angle. And depending
on the problem you're trying to solve, you'll need specific ratios between
them.

The parts of a triangle rectangle

Pythagoras (or some student of his) called the x and y sides of the triangle
the Cathetus (the plural is Catheti, and it's generally translated as legs) and he
called the slanted line the Hypotenuse. The Catheti are further divided into
the adjacent and opposite legs in relation to the angle.
If you know the angle and the length of the hypotenuse, you can find the
length of x (the adjacent leg) using the cosine of the angle (this is the ratio)
times the length of the hypotenuse.
If you know the angle and the length of the hypotenuse, you can find the
length of y (the opposite leg) using the ratio sine of the angle times the length
of the hypotenuse.
And on and on it goes, until a ratio was determined for each possible
purpose: sine, cosine, tangent, arc-sine, arc-cosine, arc-tangent. The arc- ones
are inverted versions of the non-arc ones. They give the angle based on the
lengths you have whereas the non-arc ones, as I showed you, give you a
length based on the angle. Programming languages provide a special version
of the arc-tangent, often called atan2(). Give it the length of the opposite
leg and the length of the adjacent leg and it will give you the angle. And its
used a lot whenever you wish to move something towards another point on
the screen.
At least JavaScript does all the calculations for you. Our poor painter had
to do his calculations all by hand. And he liked writing backward!
He was weird. But cool.
 10
Space-time
We just saw how much a clever painter could do with his mind. Now it's
time to see how much a clever violinist could do with his. We'll use most of
the code we used in the previous chapter with some minor adjustments and a
lot less math. To begin with, let's create some drawing space. For this, we can
repeat the previous code:
var width = 1200;
var height = 800;

var canvas = document.createElement("canvas");

canvas.id = "myCanvas";
canvas.width = width;
canvas.height = height;
document.body.appendChild(canvas);
var ctx = canvas.getContext("2d");

This time, let's draw a representation for our x and y axes:

var border = 10;

function drawCartesianLines () {
ctx.beginPath();
ctx.lineWidth = 2;
ctx.moveTo(border, height - border);
ctx.lineTo(width - border, height - border);
ctx.moveTo(border, height - border);
ctx.lineTo(border, border);
ctx.stroke();
}

function update() {
 ctx.clearRect(0, 0, width, height);
drawCartesianLines();
window.requestAnimationFrame(update);
}

window.requestAnimationFrame(update);

If you run this, the result explains the code better than words:

Drawing lines for our axes

The drawing is done with a stroke instead of a fill. The moveTo() method
moves the "pen" to the point where you wish to start drawing. moveTo()
and lineTo() mean start the line here and end the line there. The two lines
we're drawing belong to the same path and the path is the thing receiving the
stroke command. I added a border of 10 pixels so we could see the lines
clearly instead of drawing right on the edge of the canvas.
Next, we'll draw two circles. These are described like this:
var circles = [
{color:"#0000FF", radius: 20, x: 40, y: 40, vx:0, vy:2},
{color:"#FF0000", radius: 20, x: 100, y: 40, vx:0, vy:0}
];
 They each have a color (blue and red), a radius, a position, and a vertical
and a horizontal speed. And we draw them like this:
function drawCircle (circle){
ctx.fillStyle = circle.color
ctx.beginPath();
ctx.arc(circle.x,
circle.y,
circle.radius,
0,
2 * Math.PI);
ctx.fill();
}

function update() {
ctx.clearRect(0, 0, width, height);

drawCartesianLines();

circles.forEach ( function (circle) {

drawCircle(circle);
});

window.requestAnimationFrame(update);
}

Resulting in:
 Two circles

The first circle has a vy speed of 2. We should use that to move the circle:
function moveCircle(circle) {
circle.y += circle.vy;
}

However, coded like this, when the circle reaches the bottom of the canvas
it'll keep moving off-screen. Let's make it bounce instead:
function moveCircle(circle) {

circle.y += circle.vy;

if (circle.y > (height - border - circle.radius)) {

circle.y = height - border - circle.radius;

circle.vy *= -1;

} else if (circle.y < circle.radius + border ) {

circle.y = circle.radius + border;

circle.vy *= -1;
}
}

We check both at the bottom of the screen and at the top. I subtract the
border and the circle radius so the circle will appear to bounce precisely
inside the canvas—and on the lines, we drew—like a ball hitting a surface. In
order to change direction, we just need to multiply the y speed by -1,
changing positive speeds to negative and negative speeds to positive. And we
need to add the call to move the circles inside our update() function:
function update() {

ctx.clearRect(0, 0, width, height);

drawCartesianLines();

circles.forEach ( function (circle) {

moveCircle(circle);
drawCircle(circle);
});

window.requestAnimationFrame(update);
}

Right now, our x speed is 0 but this will change soon, so let's add support
for that inside moveCircle():
function moveCircle(circle) {

circle.y += circle.vy;
circle.x += circle.vx;

if (circle.y > (height - border - circle.radius)) {

circle.y = height - border - circle.radius;
circle.vy *= -1;
} else if (circle.y < circle.radius + border ) {
circle.y = circle.radius + border;
circle.vy *= -1;
}

if (circle.x > (width - border - circle.radius)) {

circle.x = width - border - circle.radius;
 circle.vx *= -1;
} else if (circle.x < circle.radius + border ) {
circle.x = circle.radius + border;
circle.vx *= -1;
}
}

We will also bounce the circles on the x-axis as you can see in the code,
this time checking the left and right side of the canvas. If you run the
program now the first ball will move up and down, and the other will remain
fixed in place since it has no speed.
Let's be fancy and add a play and pause state as well:
var run = false;

window.onmouseup = function(e) {
run = !run;
}

function update() {
ctx.clearRect(0, 0, width, height);

drawCartesianLines();

if (run) {

circles.forEach ( function (circle) {

moveCircle(circle);
drawCircle(circle);
});
}

window.requestAnimationFrame(update);
}

By clicking on the canvas we switch the value of the boolean run:

run = !run;

This says: run equals not run, resulting in a boolean inversion since not
true = false and not false = true.
 Now we need to click on the canvas in order to see the circles and we can
pause and resume the animation by clicking on the canvas again because we
only run those updates based on the value of run.
We have our test application completed now and we can start messing with
our heads good and proper. Ready?
Imagine that you're bouncing the first circle with a vy speed of 2 on a
sidewalk. And a friend of yours takes the second circle, also bouncing it with
a vy speed of 2, and gets into a train speeding away with a vx of 2.

The movements of each circle

We say that relative to you, the second circle has a vy = 2 but also a vx
= 2, because relative to you, the train speed will be added to the circle and it
will appear as if the circle has a horizontal speed as well. So if you were to
run the animation with these values:
var circles = [
{color:"#0000FF", radius: 20, x: 40, y: 40, vx:0, vy:2},
{color:"#FF0000", radius: 20, x: 100, y: 40, vx:2, vy:2}
];
 And pretend the train belongs to Wonder Woman and is completely
invisible, so that you, standing on the sidewalk, will see the red ball moving
like this:

Ball bouncing inside moving train relative to you

But relative to your friend, inside the invisible train, the red circle is still
only bouncing up and down. To him, the circle data is still:
{color:"#FF0000", radius: 20, x: 100, y: 40, vx:0, vy:2}
 Ball bouncing inside train

But the circle data, relative to you, is:

{color:"#FF0000", radius: 20, x: 100, y: 40, vx:2, vy:2}
 The two movements relative to you

Once again, this is because you add the vx speed of the train to the
displacement of the circle.

As a matter of fact, to your friend on the train, it will be your circle

that will have a vx = -2 (the entire world, relative to him, has a vx
= -2 as the train moves)

This is called Galilean Relativity because Galileo was the first to talk about
it. And go ahead. Sing that bit from the Bohemian Rhapsody. I'll wait.
Relativity says that if you run at 5 miles an hour towards a wall, you'll hurt
yourself. But if the wall is also moving towards you at 5 miles an hour, that
will hurt you more, because relative to the wall, you're moving at a speed of
10 miles an hour. That will be the total speed at which you'll hit the wall even
though nothing is moving at that speed.
And if you run the program with the relative values (relative to the guy on
the sidewalk):
var circles = [
{color:"#0000FF", radius: 20, x: 40, y: 40, vx:0, vy:2},
 {color:"#FF0000", radius: 20, x: 100, y: 40, vx:2, vy:2}
];

Notice that both circles still match their y position but the red circle moves
to the right because of its vx speed. Therefore, although it may not look like
it, the two circles are no longer moving at the same overall speed. The blue
one has an overall speed of 2, and the red one has an overall speed of
2.82842712475. This is calculated through Pythagoras again:
Math.sqrt( Math.pow(vx,2) + Math.pow(vy,2));

The red circle speed is the square root of the sum of vx and vy squared.
Why? Because the hypotenuse in the triangle created by the vx and vy
speeds becomes the total speed.

Total speed is hypotenuse of vx and vy

Now let's make this change:

var circles = [
{color:"#FFFF00", radius: 20, x: 40, y: 40, vx:0, vy:2},
{color:"#FFFF00", radius: 20, x: 100, y: 40, vx:2, vy:2}
];

This will make both circles yellow. Why? In order to represent they are
now particles of light, also known as photons. And let's pretend the height of
our canvas is now 299.792,458 meters because that's how far light travels in a
second. You are with Flashy, your trusty pet photon, standing on a sidewalk
with Flashy bouncing up and down at the speed of light while your friend
took his pet photon into Wonder Woman's train traveling at vx = 2. Have
you got all that?
What happens then? If we run the animation we see the same result, this
time with yellow circles representing our dear pet photons. But this is wrong.
Wrong, wrong, wrong, wrong. Light-speed is never relative. To anything.
Ever. We know this since around the 1900s when we strapped a machine that
can measure the speed of light to this bit of rock called planet Earth. And
while this bit of rock was moving towards the sun, we measured the speed at
which sunlight reached the Earth. Hoping to determine that this speed would
be higher than the speed at which sunlight reached the Earth when the Earth
was moving away from the sun. You know, relativity. It's the same thing with
running towards walls. Only it wasn't. The speed of light did not change, it
measured the same in both cases, when the Earth was moving towards and
away from the sun. The speed of light isn't relative. If your speed was not
relative to the speed of the wall moving towards you, it wouldn't matter how
fast you ran or how slow, this would not change the time it would take for
you to smash into the wall. Crazy, right? This means when we add a vx to
our photon inside the moving train, we still need to make it move at the same
speed Flashy is bouncing on the sidewalk because that's the only speed a
photon can travel at. A total of 2 and not 2.82842712475. And because the
speed of light cannot change through relativity, it requires a special kind of
relativity. Wink wink.
That means, we need to make some changes... How about we move our
first call to update():
window.requestAnimationFrame(update);

Inside a new function, and call that instead to get things rolling:
function init () {

circles.forEach ( function (circle) {

if (circle.vx != 0) {
var angle = Math.atan2(circle.vy, circle.vx);
 var speedOfLight = circle.vy;
circle.vx = speedOfLight * Math.cos(angle);
circle.vy = speedOfLight * Math.sin(angle);
console.log(angle);
}
});

window.requestAnimationFrame(update)
}

init();

Inside init() we use Pythagoras again like we did last time to calculate
the overall vx and vy of each circle whose vx speed is not 0. We know that
the hypotenuse must be 2, no matter what, because I determined that to be the
total speed of the circle (our speed of light, in this case), and therefore, we
recalculate vx and vy on the second circle to ensure it moves with an overall
speed of 2 pixels like the one moving vertically.

Total speed must be 2

 And to make this change really noticeable, let's update the original speeds
and give the second circle a vx of 8 (the speed Wonder Woman's train is
moving, which I know would technically mean her train can move at 4 times
the speed of light which I determined to be 2... anyway... let's say they don't
call her a wonder for nothing):
var circles = [
{color:"#FFFF00", radius: 20, x: 40, y: 40, vx:0, vy:2},
{color:"#FFFF00", radius: 20, x: 100, y: 40, vx:8, vy:2}
];

And this time, let's not clear the canvas before each draw. This way the
drawings will remain on the canvas and overlap one another:
function update() {
//ctx.clearRect(0, 0, width, height);
...
}

Just comment that line out of the code, adding the two forward slashes for
comments, the code will be turned into a comment and not compile along
with the rest.
We see this after the screen is repainted a few times:
 The photon's displacement

The second circle now seems slower, even though it isn't, it just has more
space to cover moving at an angle like that.
You can see that the second circle won't reach the bottom of the canvas at
the same time the first circle will. But remember that the canvas is now
299.792,458 meters high and by the time the first circle reaches the bottom of
the canvas, a second went by because photons travel 299.792,458 meters in a
second and we're pretending both circles are moving at the speed of light. But
what about the photon your friend took inside Wonder Woman's train? As far
as he's concerned, his pet photon is only bouncing up and down and it's
reaching the bottom of the canvas after one second as well. But relative to
you, because of the train's speed, his photon takes longer now to reach the
bottom than yours. Waaay longer. Because normal relativity does not add to
the overall speed of a photon as it does to everything else. But this would
mean that a second to your friend, relative to you, is much much longer.
Waaay longer. Relative to you, time seems to have slowed down inside the
train.
The answer, according to Einstein, the violinist I mentioned at the
beginning, is that we are all moving through space and time at the speed of
light. Time does not actually slow down for the second circle. It's just that
time and space are two sides of the same coin, fused together to create the
same thing we use to move and pass the time in. We are always moving at
299.792,458 meters per second. All of us. You and Usain Bolt. We all move
through space-time at that same speed. Stop moving through space and you're
the first circle, moving only through time at the speed of light. Start moving
through space and your overall speed, which is constant and equals the speed
of light, gets shared between your movement (displacement) through space
and time. In order to move through space—to get that glass of water, or to
see a man about a dog—you have to move less through time. You become the
second circle.
(You also get kind of squished, but who cares about that?)
And Einstein didn't stop there, oh no. He called this light-speed thing his
Special Relativity. Then he moved on to his General Relativity, about ten
years later. Can we use JavaScript to see that? You betcha!
We'll use something called the Equivalence Principle, another thing our
friend the violinist came up with. An idea not unlike what we've been using
all along. Recreate something real in a simulation, with equivalent values,
and whatever oddity you find in the simulation should also exist in the real
thing you're simulating.
Imagine you're inside a spaceship, currently stationary at a point in space
where there is no gravity. You're floating around, chillin'. Then you observe a
single photon pass by you, through the ship (let's pretend you have the ability
to notice these things). The photon of light enters through a window on one
side of the ship, moves across the room and out another window. Its data
looks like this:
var circles = [
{color:"#FFFF00", radius: 20, x: 40, y: 40, vx:10, vy:0}
];

function moveCircle(circle) {
circle.x += circle.vx;
circle.y += circle.vy;
}

No bouncing this time. Just zipping past.

Photon zips by horizontally

Now imagine the spaceship began to move upwards (there is no down),

with a fixed speed. Let's say a vy speed of 3.
var circles = [
{color:"#FFFF00", radius: 20, x: 40, y: 40, vx:10, vy:3}
];

You don't know the spaceship is moving, to you, this feels just like before,
when the ship was stationary. You're still floating about but now you see the
photon move like this across the room:
 Photon zips by at an angle

Okay, a straight line at an angle, nothing fancy. The photon is moving

sideways just like before but this time the room is moving upwards. Relative
to you, who doesn't know the ship is moving, light gets inside the room at a
higher point than it leaves the room because the room is moving, so this vy
speed is actually related to the spaceship and not the photon. And I could
have used Pythagoras to ensure the relative vy = 3 speed does not change
the overall speed of the photon. But this time we don't need to make
comparisons between two photons, so it's okay to leave it like that. For now.
I'm interested in the path taken by the photon relative to this observer: first a
straight horizontal line, then a slanted one.
Now let's pretend the spaceship is not only moving but accelerating at the
same rate of gravity on Earth. You're no longer floating. Inside the room, you
would experience this acceleration the same way we experience gravity and
would still think the spaceship is not moving at all, it just switched on gravity
for some reason. To you, it would feel like being inside any other room on
Earth. Gravity on Earth is equal to 9.8 meters per second squared. Second is
squared because gravity is an acceleration, it keeps increasing speed. In our
example we can slow this acceleration down to say acceleration =
0.1 to make the result more noticeable, and let's start with vy of 0:
var circles = [{color:"#FFFF00", radius: 20, x: 40, y: 40, vx:10, vy:
0, acceleration: 0.1}] ;

And when we update the position of our photon we use the acceleration to
update vy:
function moveCircle(circle) {
circle.x += circle.vx;
circle.y += circle.vy;
circle.vy += circle.acceleration;
}

Meaning we increase vy by 0.1 in each iteration, thus creating an

equivalent "gravity" in our simulation (relative to the person observing all
this from inside the room). And what does that do to our photon's path?

Photon zips by in a curved path

It makes it curve. Huh.

Remember, to you standing inside the room, who does not know the room
is moving at all but instead thinks the room has a gravity equal to the one on
Earth, it will look as if light is bending. In this case, the Equivalence
Principle says that in a scenario where gravity is real and not an illusion
caused by artificial acceleration, the same oddity should be observed.
Meaning, gravity apparently can bend light. Or rather, gravity is a field of
distortion and light bends when passing through a gravity field the way it
"seems" to bend when observed from inside a spaceship accelerating at the
same rate as gravity. Because gravity itself is the result of bending space-
time. Draw a straight line on the palm of your hand and then cup your hand to
represent the bending of space-time and you can see the line you drew bend,
only it doesn't; it's the space around it that bends. There is no spoon.
Matter bends space-time resulting in gravity-fields. This field is a distortion
in both space and time. The curved path described by the photon is longer
than the horizontal path but since light-speed is constant this generates the
same discrepancy we observed in our first example. As an exercise, try to
update the photon's position using what I determined to be the speed of light
in this example, our vx. Use Pythagoras once again to determine the x and y
components of the displacement as vy accelerates, but with an overall
constant speed as the result. A hint: the calculation is very similar to what I've
shown in the previous example, only this time vx is being used for the speed
of light.
With this, we learn that gravity by itself produces the same effect on space-
time as movement does. It "slows" time down—or rather, it changes our
displacement through time. If you lived on the first floor of Burj Khalifa, the
tallest building on Earth, and your twin brother lived on the top floor, he'd get
slightly older than you every second. All because of the effect gravity has on
time.
Again, not bad for a violinist named after a dog.
As another exercise, turn this whole magnificent example of human
understanding into an endless game of pong played by the computer. The
logic for it is all there. The only thing missing is how to draw a rectangle for
the player:
ctx.fillStyle = "#000000"
ctx.beginPath();
ctx.rect(x, y, width, height);
ctx.fill();
 Make a ball bounce across the screen and make two player-rectangles
follow its trajectory. Place the players on each side of the canvas. Make them
match the ball y position, but stick to their respective x position the whole
time.
Einstein would be proud. I guess.
 Part 5:
Paradigms
 1
Walk this way
What follows is an introduction to the three main programming paradigms
based on popularity and application. You've heard me mention when
describing different programming languages, whether a certain language was
multi-paradigm or not. What this usually means is that with multi-paradigm
languages you can code your applications following these three different
"styles", even though there are more than just these three. The paradigms are:

Procedural Programming
Object-Oriented Programming (OOP)
Functional Programming

Just like the programming languages themselves, these paradigms came

about with the idea to solve specific problems, and then, because we're all
lazy monkeys, we ended up forcing them to solve all problems. There is
nothing bad about any of them, although you may not believe this from
hearing me speak about them. Programming suffers from most of the same
issues regular writing does and we can boil them all down to one word:
clarity. How to code without repeating yourself? How to organize your code
so that you don't end up adding to your workload? How to make sure other
people can understand your code? How to make sure you can get back to
your code months from now and still understand it? These are all worthy
concerns in programming and each paradigm will try to address these
problems in their own way.
I chose to introduce the paradigms with the old and tried method of coding
the same thing in the three different styles. For this, I chose the game of
Cluedo (or Clue depending on where on the globe you grew up in). Not
unlike the way we coded the magic tricks, we'll transform a typical game of
Cluedo into code. I suspect the choice for this came from the fact that
procedural is a word often used to describe a type of murder mystery and
because OOP has the idea of "inheritance" as one of its unique concepts and
the word put me in mind of rich aunts being murdered for the sake of their
millions. I fear my mind thinks in puns.
Be aware that with the exception of the first paradigm, it will feel like
you're learning to program all over again. Relax. It's not true. Remember that
programming is just a bunch of simple operations (store, add, multiply,
compare...) built around strings, numbers, and booleans and abstracted to
readable syntax and structures (collections, loops, if statements, and
functions). Try to focus on these building blocks first and then take notice of
the curious ways things are accomplished through each paradigm. We'll be
adding new ways to add context to our code, new kinds of code blocks with
their own special rules, and a whole bunch of new syntax and abstractions,
but at the heart of it, we're still talking about the same thing.
The paradigms also bleed into each other, the lines between them is quite
blurred, and when I introduce a concept connected to one of them I do not
mean that concept is not applicable to the others (remember, the languages
I've shown you here are all multi-paradigm). You can code procedurally with
a slight bent towards objects. You can code objects with a bent towards
functional ideas, and with some functional languages, you can use objects in
your logic.
However, I will not play fair with the code and the examples. I will limit
the paradigm solutions to their core concepts and through heavy-handedness
provide you with perfect illustrations of what I think are the shortcomings of
some of the paradigms (even though these may be easily remedied or avoided
altogether).
You may choose to use these chapters as reference for when you decide to
deep-dive into OOP or Functional Programming. You may skip them for
now. By now, you know the basics and quite a bit more than that. Do keep in
mind that these paradigms could each fill entire books dedicated to the
subject. Just as with any single language out there. Once you do decide on
what you wish to use, then it'll be time for a more in-depth study. In the last
chapter, I'll give you tips on how to further your learning.
Let's get a-murdering!
 2
Procedural Murder
Procedural programming is what we've been doing thus far. It's the "one
damn thing after another" paradigm. Think of a cooking recipe and you're
thinking procedurally. There's no limitation to what sort of problems one can
solve this way, but you tend to find it used in the development of tools more
often than not. These are usually console applications like the ones we've
been building. And if you find console applications a bit out-dated, think
again. It's an unbelievably freeing experience the moment you realize how
many of the things you do with your computer should exist as a series of
console scripts processing specific files inside specific folders. Programmers
who find it hard to express their logic through procedural code are just not
good at it.
Let me talk about the code we'll be working on. If you want to do it
yourself, for the procedural version, here are the main characteristics of the
application we're coding.

We have a list of 5 suspects, a list of 5 murder scenes, a list of 5

murder weapons, and I've added a list of 5 motives because I wanted to
find out how much harder the game can get if we keep adding elements
to it. These are collectively called clues.
We have a list of 4 detectives. In the actual game, the suspects
themselves are the detectives but what's the fun in doing that? Especially
when I get to write code like this: detectives =
["Poirot","Sherlock Holmes","Velma","Shaft"]
We shuffle the murder clues, and then take one of each clue type to
represent the murder; so that we end up with something like: "It was
Colonel Mustard in the library with the pipe for some reason."
We distribute the remaining clues to all detectives.
 The game itself is a loop where each detective generates a theory of
the murder, by picking a suspect, a location, a weapon, and a motive.
This theory is checked against the clues the other detectives own. If
there is a match, the detective posing the theory is informed of this: "It
can't be the pipe," another detective tells him, "because I own the pipe
clue." And so each detective progressively collects more clues with
every generated theory and this, in turn, helps them generate better
theories; narrowing the possibilities down of what is contained inside
the murder.
The game ends when a detective's theory can not be shot down by the
other detectives and therefore must be the ones collected in the murder.

If you have the time, you should try to code this on your own or perhaps
write down some pseudo-code for how the main functions would work.
These are:

How to distribute the clues and generate the murder.

How to generate a theory.
How to check a theory with the other detectives.
How to write the main game loop that runs until the murder is solved.

The problem offers that nice mix of collection manipulation and data
comparisons that you'll find in the vast majority of programs. And I've
decided to use Python for this paradigm, even though, technically, I could
have picked Python for all three.
In this version of the game, we'll make sure a detective does not select the
clues in his or her possession when generating a theory. In the actual game, a
player is free to use different strategies and I'd encourage you to take a crack
at them at some point.
Let me start with the data:
suspects = ["Colonel Mustard","Professor Ketchup","Mrs
Mayonnaise","Miss Relish","Violet Beauregarde"]

locations = ["Library","Drawing Room","Sitting Room","Music

Room","Game Room"]
weapons = ["Pipe","Candle Holder","Rope","Gun","Poison"]

motives = ["Money","Jealousy","Blackmailing","Revenge","Something to
do"]

detectives = ["Poirot","Sherlock Holmes","Velma","Shaft"]

We need to separate the clues a detective owns from the ones a detective
collects throughout the game. Why? Because when a detective shoots down
someone else's theory, this must be done using his or her original clues and
not the ones collected from other detectives throughout the game. (In the
actual game, one player shows another one of his clue cards, the ones he
received at the beginning of the game, proving the theory is at least partially
wrong; and these collected clues are written down in a neat little notepad).
detective_original_clues = {}

detective_collected_clues = {}

And notice the curly braces {} instead of square brackets []. This is a
Dictionary I'm declaring. A dictionary holds key-value pairs. These particular
ones will use a string key and a list of strings for the values. The key will be
the detective name and the list will be the names for the clues. For instance,
Poirot's collected clues may be stored as:
{ "Poirot": ["Colonel Mustard", "Sitting Room", "Rope"]}

This way we can pair the data. If the language we're using did not support
dictionaries, we could use two-dimensional lists like this:
[ ["Colonel Mustard", "Sitting Room", "Rope"], ["Money"],
["Gun","Poison"], [] ]

And match the list to the index of each detective name:

["Poirot","Sherlock Holmes","Velma","Shaft"]

So the first list would be the collected clues belonging to "Poirot"; the
second list, the clues belonging to "Sherlock Holmes". And "Shaft", in this
example, would hold no collected clues, so his list is empty. But this kind of
"pairing" could generate lots of errors. What if your indexes don't match?
Without dictionaries, you'd need to be extra careful with this. But then again,
you're not an idiot, therefore the second option should work just fine.
Next, we need an index for the current detective. This will mean the current
detective generating a theory (the one playing the round).
detective_index = 0

And a boolean to store whether or not the mystery has been solved:
mystery_solved = False

Although this might not be necessary. We'll see.

We have our data. Now comes all the functions we'll need to handle
transformations in the data and all the necessary checks to determine if clues
are correct or not. Let us focus on the four main transformations I listed
before: a way to distribute the clues and generate a murder in the process, a
way to generate a theory, a way to check the theory, and finally the game's
main loop.
I'll start with a function that retrieves a random item from a clue list:
# don't forget to import random
# at the top of the script
import random

def getRandomClue (some_list):

index = int(math.floor(
random.random() * len(some_list)
))
return some_list[index]

I can use that function now to commit murder:

murder = []
murder.append(getRandomClue(suspects))
murder.append(getRandomClue(locations))
murder.append(getRandomClue(weapons))
murder.append(getRandomClue(motives))

Next, we need a function to distribute the clues to all the detectives. But
first, we need to create our detectives' lists of clues:
for d in detectives:
 detective_original_clues[d] = []
detective_collected_clues[d] = []

Each detective name is used as the key in the dictionary and each key starts
with an empty list for their value.
Now we can write a function that distributes clues, appending them to the
correct list. This function takes a list of clues as a parameter and then loops
through all detective names adding clues to the detective's original and
collected clues. Something like:
def distributeClues(clueList):
_clues_len = len(clueList)
while _clues_len > 0:
for d in detectives:
_clue = getRandomClue(clueList)
detective_original_clues[d].append(_clue)
detective_collected_clues[d].append(_clue)
_clues_len -= 1

Why add the clue to both lists? I chose to do it this way to save time later.
When it's time to generate theories, the detective will not form a theory using
clues he or she has already collected (clues the detective knows cannot be
part of the murder). And that includes the original clues distributed at the
beginning of the game. If you do decide to code different strategies, you will
need to make changes to this bit of logic.
Only this function won't work as it is. Can you figure out why?
Two reasons really. There is nothing stopping us from randomly selecting
the same clue more than once. And nothing stopping us from selecting clues
which have already been taken for the murder collection. According to how
the game works, the murder clues must be eliminated from the clues the
detectives get. That's the whole point of the game.
I can pass the murder collection to the function and run an extra check, like
this:
def distributeClues(clueList, murder):
_clues_len = len(clueList)
while _clues_len > 0:
for d in detectives:
_clue = getRandomClue(_clues)
 if _clue not in murder:
detective_original_clues[d].append(_clue)
detective_collected_clues[d].append(_clue)
_clues_len -= 1

But this solves only one of our problems: checking if the clue belongs to
the murder before distributing it. We can still select the same clue multiple
times using that code. So how about...
def distributeClues(clueList, murder):
_clues = list(clueList)
while len(_clues) > 0:
for d in detectives:
_clue = getRandomClue(_clues, True)
if _clue not in murder:
detective_original_clues[d].append(_clue)
detective_collected_clues[d].append(_clue)

I make a duplicate of the clue list so I can pop items out of it locally inside
the function. I can't destroy my original clues list after all, or pop items out
of it, because I'll need the complete list when generating theories later. But by
creating a copy of it inside the function, I can do whatever I want with the
copy. Now the while loop can check on the total length of this cloned list.
And I changed the getRandomClue() function so I can have the option to
get a clue from a list and take it out of the list at the same time:
def getRandomClue (some_list, removeItem = False):
if len(some_list) == 0: return ""
index = int(math.floor(random.random() * len(some_list)))
item = some_list[index]
if removeItem: some_list.remove(item)
return item

You can add default values to function parameters by using the equal sign:
def getRandomClue (some_list, removeItem = False):

This way I can call this function as:

# will use default value and not remove the item
getRandomClue(myList)

# same as above
getRandomClue(myList, False)

# will remove the chosen item from the given list

getRandomClue(myList, True)

Another important programming concept we've seen here is the one about
passing arguments to a function by reference or value. If you were to run
these lines:
print( len(suspect) )
_clue = getRandomClue(suspect, True)
print( len(suspect) )

You'll notice that originally the length of suspect is 5, and after we

removed an item, the length drops to 4. This means getRandomItem() is
receiving the suspect list as a reference and not as a value, and mutating
the original list inside the function. What does this mean?
When arguments are passed as values, this happens:
def multiplyByTwo (n):
n * 2

num = 1

# takes num as value and multiplies by 2

multiplyByTwo(num)

print(num) # prints out 1 and NOT 2

When an argument is passed as a value it gets duplicated inside the scope

of a function (a copy is made and the code acts on the copy). It's no longer
linked to the original variable. So in the code above, the original num doesn't
get changed by the function. But when an argument is passed by reference,
like in our list example, then it is the original variable that gets mutated and
not a copy of it. I said before that variables (or blobs of data in your program)
have a value, a type and an identity (or reference), the latter being the
memory address where the value is stored. Some blobs of data will, when
given to functions as arguments, be passed as their values and some as their
identities (reference). Languages will deal with this in their own particular
way but it's a common feature in programming that primitive types (numbers,
booleans, and strings) are passed as values and more complex types are
passed by reference to avoid copying the data. Some languages like C# will
let you override this default behavior as you wish.
Back to my distributeClues() function. If I run it as is, I'll get an
error in my logic. Detectives will receive a different number of clues. Why is
that? Take a look at the function again:
def distributeClues(clueList, murder):
_clues = list(clueList)
while len(_clues) > 0:
for d in detectives:
_clue = getRandomClue(_clues, True)
if _clue not in murder:
detective_original_clues[d].append(_clue)
detective_collected_clues[d].append(_clue)

Can you see why? According to my logic, if I randomly select a clue that is
contained in murder, I skip the current detective and move on to the next.
So one detective gets nothing in that case. I need to make sure I'm picking
random clues which are never in murder. Sounds like a good place for a
filter(), methinks:
def distributeClues(clueList, murder):
_clues = list(filter (lambda clue: clue not in murder, clueList))

while len(_clues) > 0:

for d in detectives:
_clue = getRandomClue(_clues, True)
detective_original_clues[d].append(_clue)
detective_collected_clues[d].append(_clue)

There. All better. The locally generated _clues list will not contain any
of the clues in the murder collection and so we don't need to worry about
anything anymore. We're good. Phew.
And by the way, special notations are an extra way to add context to
variables and functions. In my Python code I decided that a variable that
starts with an underscore means a local one (when I say local I mean the
function's scope and not the global one):
_clues = list(filter (lambda clue: clue not in murder, clueList))
 It's common to name variables and functions following all sorts of
conventions to increase context and information and reduce collisions and
confusion. Since Python lacks a var to indicate declaration, it helps to
distinguish between a local scope variable and a global one.
We can create detectives and distribute the clues right after we create the
murder. Let me wrap all that inside an initGame() function:
def initGame ():

murder.append(getRandomClue(suspects))
murder.append(getRandomClue(locations))
murder.append(getRandomClue(weapons))
murder.append(getRandomClue(motives))

for d in detectives:
detective_original_clues[d] = []
detective_collected_clues[d] = []

distributeClues(suspects, murder)
distributeClues(locations, murder)
distributeClues(weapons, murder)
distributeClues(motives, murder)

Someone just committed murder. How can a detective generate a theory?

The detective needs to collect a suspect, a location, a weapon, and a motive
not present in the detective's collected clues. So we need a way to get a
random clue which is not present inside another list (same problem we just
solved inside distributeClues()). Again, we might be tempted to do
something like:
def getUniqueClue (clue_list, collected_clues):
_uniqueList = list(clue_list)
while (True):
_clue = getRandomClue(_uniqueList)
if _clue not in collected_clues:
return _clue

We pass it the complete clue list, and the list of already collected clues and
we loop until we get a random clue which has not been collected already.
This code is okay. Not great. Randomness is unpredictable, we could get
stuck here a while. Once again, we could fix this using filter() to
generate our _uniqueList.
_uniqueList = list ( filter(lambda clue: clue not in collected_clues,
clue_list) )

Or the special Python notation known as comprehensive that we used a few

chapters ago to generate a list:
_uniqueList = [clue for clue in clue_list if clue not in
collected_clues]

This mouthful will fill the list with values from clue_list not present in
collected_clues.
In any case, we can now use this function to generate a theory like this:
def getTheory (detectiveIndex):
_detective = detectives[detectiveIndex]
_collectedClues = detective_collected_clues[_detective]
_suspect = getUniqueClue(suspects, _collectedClues)
_location = getUniqueClue(locations, _collectedClues)
_weapon = getUniqueClue(weapons, _collectedClues)
_motive = getUniqueClue(motives, _collectedClues)
return [_suspect, _location, _weapon, _motive]

You might, as an exercise, make this function return a dictionary with more
meaningful keys: {"suspect": _suspect, "location":
_location, "weapon": _weapon, "motive": _motive}. It
would save us from having to remember what clue goes at each index.
And how do we check if a theory is the murder? Here's one way:
def isTheoryRight (theory):
for clue in theory:
if clue not in murder:
return False
return True

But you can rewrite this using comprehensives, or filter, or any number of
ways. You can be neater and pass the function a reference to murder to
reduce coupling.
Finally, we need a way to check if a theory can be shot down by other
detectives. In the actual game, the current round detective checks a theory
first with the next-round detective and we loop all subsequent detectives until
one of them can provide a clue to disprove the theory. If so, this clue gets
added to the collected clues list of the current round detective (the one
positing the theory).
I coded this:
def checkTheory (theory):
_detectiveIndex = (detective_index + 1) % len(detectives)
while (_detectiveIndex != detective_index):
_detective = detectives[_detectiveIndex]
_clues = detective_original_clues[_detective]
for clue in theory:
if clue in _clues:
return clue
_detectiveIndex = (_detectiveIndex + 1) %
len(detectives)
return None

I make a local copy of detective_index and increment its value using

the fancy "increment and wrap the value around a fixed-length" algorithm:
_detectiveIndex = (detective_index + 1) % len(detectives)

As I said, one of the rules in Cluedo is that a player must first ask the
detective sitting next to them whether or not a theory is correct and loop
through the detectives from that position. So the while loop will run until the
index matches the current detective index. Inside the while loop, I grab the
original clues from the next detective:
_detective = detectives[_detectiveIndex]
_clues = detective_original_clues[_detective]

And check if any of them matches any clue in the theory being checked. If
I do find a match I return it, essentially terminating the function, so the clue
can be collected by the detective who posed the theory in the first place.
for clue in theory:
if clue in _clues:
return clue

Otherwise, if no match is found and we looped through all available

detectives, I return None from the function (None is Python's null, and also
its void):
while (_detectiveIndex != detective_index):
...
return None

This means I asked all other detectives and haven't found a match,
therefore I must return None, meaning there are no clues to be collected from
this theory and this means the current detective has solved the murder.
I'll write one more function that collects any returned clue from this
function:
def collectClue (clue):
_detective = detectives[detective_index]
detective_collected_clues[_detective].append(clue)

... appending the clue to the current detective's collected clues list. This
way, the next time this detective generates a theory he or she won't use this
particular clue anymore.
And that's it. We're ready to code the game's main loop.
We initialize the game:
initGame()

And we call our playGame() function. And what would that need to do?

1. It grabs the current detective.

2. It generates a theory based on that detective's clues.
3. It checks this theory against all other detectives.
4. If it gets a clue back, it adds this clue to the current detective's collected
clues list. And then it updates detectives_index and starts back
from step 1.
5. If it gets no clue back, it checks to see if the theory is the murder, prints
out the solution, and breaks the main game loop.

You can write it now if you want, and come back and check my code.
Here it is:
def playGame():

global mystery_solved
global detective_index
game_rounds = 0

while mystery_solved == False:

solution = getTheory(detective_index)
clue_found = checkTheory(solution)

if clue_found is not None:

collectClue(clue_found)

else:

if isTheoryRight(solution):

mystery_solved = True

print(
"{0} solved the mystery!\n{1} in the {2} with the {3} all
for the sake of {4}"
.format(
detectives[detective_index],
murder[0],
murder[1],
murder[2],
murder[3],
))
print(murder)

print(
"Total Rounds: {0}"
.format(game_rounds)
)

# I'll use this returned value in a moment...

return game_rounds
 detective_index = (detective_index + 1)
% len(detectives)

game_rounds += 1

The game will loop until we have a solution to the murder.

I added a total number of rounds so I can write a few tests answering a few
odd questions of my own. For instance, the average number of rounds until
the game is solved, and the chance the game can be solved in one guess.
For this, I'll need a way to reset a finished game so I can run it again:
def resetGame ():

global murder, detective_collected_clues,

detective_original_clues, detective_index, mystery_solved
murder = []
detective_collected_clues = {}
detective_original_clues = {}
detective_index = 0
mystery_solved = False

And then I run a bunch of games in a row and calculate the average number
of rounds. I make playGame() return the number of rounds per each game
and use that to get the average:
def testAverageRounds():
games = 1000
average_rounds = 0

while games > 0:

resetGame()
initGame()
average_rounds += playGame()
games -= 1

print(average_rounds/1000)

And in order to test what are the chances a game can be solved in one
guess:
def testSolveGameInOneGuess():
 games = 10000
average_in_one = 0.0

while games > 0:

resetGame()
initGame()

if isTheoryRight ( getTheory(0) ):
average_in_one += 1
games -= 1

print(average_in_one/10000)

You can run extra tests to see how much harder adding a motive to our
pool of clues made the game overall and then test if by adding new clue types
we make the game exponentially harder or not.
Anyway. This was the easy part. We're now going to code the whole thing
again, using Object-Oriented Programming.
In the real world, applications built in this paradigm make use of something
known as Modular Programming to further help organize code, and this can
help you tackle any large project without too much confusion and messy
code. Using that system, the detective logic would exist inside a separate
script called detective.py and would need to be imported (import
detective) into the murder_mystery.py script, for example. I could do the
same to clues and to the tests. So each part of the logic would be isolated and
self-contained inside modules. This tends to reduce couplings and any global
scope abuse.
Here is the complete code for procedural Cluedo:
import random
import math

suspects = ["Colonel Mustard","Professor Ketchup",

"Mrs Mayonnaise","Miss Relish",
"Violet Beauregarde"]

locations = ["Library","Drawing Room","Sitting Room",

"Music Room","Game Room"]
weapons = ["Pipe","Candle Holder","Rope","Gun","Poison"]

motives = ["Money","Jealousy","Blackmailing",
"Revenge","Something to do"]

detectives = ["Poirot","Sherlock Holmes",

"Velma","Shaft"]

murder = []

detective_original_clues = {}
detective_collected_clues = {}
detective_index = 0

mystery_solved = False

def getRandomClue (some_list, removeItem = False):

if len(some_list) == 0: return ""
index = int(math.floor(random.random() *
len(some_list)))
item = some_list[index]
if removeItem: some_list.remove(item)
return item

def distributeClues(clueList, murder):

_clues =
list(filter (lambda clue: clue not in murder, clueList))
while len(_clues) > 0:
for d in detectives:
_clue = getRandomClue(_clues, True)
detective_original_clues[d].append(_clue)
detective_collected_clues[d].append(_clue)

def getTheory (detectiveIndex):

_detective = detectives[detectiveIndex]
_collectedClues = detective_collected_clues[_detective]
_suspect = getUniqueClue(suspects, _collectedClues)
_location = getUniqueClue(locations, _collectedClues)
 _weapon = getUniqueClue(weapons, _collectedClues)
_motive = getUniqueClue(motives, _collectedClues)
return [_suspect, _location, _weapon, _motive]

def isTheoryRight (theory):

for clue in theory:
if clue not in murder:
return False
return True

def collectClue (clue):

_detective = detectives[detective_index]
detective_collected_clues[_detective].append(clue)

def getUniqueClue (clue_list, collected_clues):

_uniqueList =
list( filter (lambda c : c not in collected_clues,
clue_list) )
return getRandomClue(_uniqueList)

def checkTheory (theory):

_detectiveIndex = (detective_index + 1)
% len(detectives)
while (_detectiveIndex != detective_index):
_detective = detectives[_detectiveIndex]
_clues = detective_original_clues[_detective]
for clue in theory:
if clue in _clues:
return clue
_detectiveIndex = (_detectiveIndex + 1)
% len(detectives)
return None

def initGame ():

murder.append(getRandomClue(suspects))
murder.append(getRandomClue(locations))
murder.append(getRandomClue(weapons))
murder.append(getRandomClue(motives))

for d in detectives:
 detective_original_clues[d] = []
detective_collected_clues[d] = []

distributeClues(suspects, murder)
distributeClues(locations, murder)
distributeClues(weapons, murder)
distributeClues(motives, murder)

def playGame():
global mystery_solved
global detective_index
game_rounds = 0
while mystery_solved == False:
solution = getTheory(detective_index)
clue_found = checkTheory(solution)
if clue_found is not None:
collectClue(clue_found)
else:
if isTheoryRight(solution):
mystery_solved = True
print("{0} solved the mystery!\n{1} in
the {2} with the {3} all for
the sake of {4}".format(
detectives[detective_index],
murder[0],
murder[1],
murder[2],
murder[3]
))
print(murder)
print("Total Rounds: {0}".format(game_rounds))
return game_rounds
detective_index = (detective_index + 1)
% len(detectives)
game_rounds += 1

initGame()
playGame()

As an exercise, work out how to reorganize all the code into modules (a
detective module, a test module and a game module). What would need to
change in terms of the data and the use of global scope? You can see that
version of the code in this book's website at
www.rengelbert.com/codingbook.
 3
Object-Oriented Programming 101
So what is Object-Oriented Programming?
An object is an entity. A blob of data. So far we have seen data stored in
variables like this:
var name = "John";

But if John has a last name, we need to store it as a separate variable:

var name = "John";
var lastName = "Smith";

But John Smith is not collected as one entity, we need the two variables to
represent the name and last name and there's no way to know they go
together like milk and cookies. I could cheat and use Tuples or an Array and
store first and last name that way.
var person = ("John", "Smith");

//or
var person = new string[] { "John", "Smith" };

But then the data itself would not explain to me this is what I did, that the
first bit of data is the first name, and the second the last name. This means the
data is not "descriptive". It lacks context and expression. Every time I create
a new person I have to remember the order the names are stored in the
collection and what type of collection I picked.
What if I used a dictionary?
var person = new Dictionary<string, string> {
"firstName" : "John",
"lastName" : "Smith"
}
 This is better. But I'm stuck with string keys and string values. I can't add
John's age as an integer to this blob of data.
JavaScript has a solution for this. Its key-value pairs can be a mix of types:
var person = {firstName : "John", lastName: "Smith", age: 42};

JavaScript even calls this an object. But person itself is not a type here. A
subtle difference, sure, but an important one as we'll see in a moment.
Besides, John is just a bunch of data, he doesn't do anything. I did say an
object is a blob of data, but not just that. It may also be a set of behaviors or
helper methods attached to this blob of data and which may be used to
transform or collect information from this data. Why would this be helpful?
Well, so far, we've been coding in a task-oriented manner. We have a series
of procedures acting on their targets. "Do this to this variable" or "Make this
change to this collection."
changePersonName (person, "Johnny");
changePersonAge (person, 43);

Object-oriented programming changes that slightly. With it, you can make
a target operate the change on itself and other targets. My entity person could
have methods of its own:
person.ChangeName("Johnny");
person.ChangeAge(43);

This is known as dot notation, I can use it to access something inside the
object, navigating down into its innards using dots:
russianDoll.smallerDoll.smallerDoll.smallerDoll.popOpen();

It's not a feature exclusive to OOP, but it's a big part of what makes objects
interesting.
In programming, the act of bundling data and behavior together is called
encapsulation. And another important feature of encapsulation is the ability
to restrict what gets accessed from outside the object (the things you can drill
into using dots). Something else JavaScript can't do with its key-value pairs
since all elements inside the JavaScript object is accessible from outside.
This is bad encapsulation:
var superman = {KryptonianName: "Kal-El", EarthName: "Clark Kent"};
 Both KryptonianName and EarthName are accessible through dot
notation:
var hisSecretIdentity = superman.EarthName;

Superman doesn't want that information to be freely available, that's why

he uses the best disguise ever: a minute pair of glasses. And speaking of bad
encapsulation, Superman got a lot of headaches because of this too:
var superman = {KryptonianName: "Kal-El", onlyWeakness:
"Kryptonite"};

What if Superman could have restricted the access to those bits of data?
OOP could have helped him with that.
But how do you create an object in OOP? Something with both data and
behavior? Turns out we've done something similar before with internal
functions. Take a look at the following code:
void myFunction (int value) {

var myValue = 10;

int changeValue () {
return myValue * value;
}

return changeValue();
}

It's not the most sensible piece of code you ever saw but it's ideal for our
purpose now. In it, myFunction() contains an internal function called
changeValue() and an internal variable called myValue. Now,
according to the rules of scope, nothing outside myFunction() will be
able to either call changeValue() or refer to myValue. You can't do
either of these things, for instance, using dot notation:
myFunction.myValue = 20;

myFunction.changeValue();

Nothing in the body of myFunction() is accessible from outside.

Encapsulation here is all-restrictive. A class can solve this problem. Take a
look at this:
public class MyClass {

public int myValue = 10;

public int changeValue (int value) {

return myValue * value;
}
}

Just as myFunction(), this class contains a property called myValue

and a function called changeValue(). The public keyword makes both
of those things accessible to the outside through dot notation, once we create
an object using this class template. The public keyword is called an Access
Modifier and these modifiers can be used to expose or hide things inside a
class. You can control what gets exposed to outside code using either the
public or the private keywords next to your class properties and
functions—the ones declared at the root scope of your class:
public class Superman {

//this is known to all

public string kryptonianName = "Kal-El";

//nothing will be able to

//access these, save Superman...
private string earthName = "Clark Kent";
private string onlyWeakness = "Kryptonite";
}

The moment you instantiate a MyClass object, anything with a reference

to that object will be able to access myValue and changeValue() using
dot notation. The same thing goes for Superman objects and his
kryptonianName property.
What does instantiate mean? A class serves as a template for a new data
type. It isn't like a function, which can be called after it's been declared
(although some classes can have a similar behavior through the use of the
static keyword as I'll show you in a moment). A class is a declaration of
an object type. This means it can be used to create instances of this type like
this:
var myClassObject = new MyClass();
myClassObject.myValue = 20;
var result = myClassObject.changeValue(2);

Classes are instantiated by calling a special function inside the class (called
a constructor) that has the same name as the class with the added keyword
new, although this is not a universality with OOP languages.
An instance of a class is called an object of that class. We've seen classes
before whenever we used Lists inside C#, or the StringBuilder class, or
the Math class.
It's not always necessary to combine both state and behavior inside a class.
The Math class in C#, for instance, only has helper methods and properties:
Math.PI;
Math.Cos(angle);
Math.Floor(number);

It does not need to be instantiated and I'll show you why in a second (it also
has to do with the static keyword). But Lists and StringBuilder
objects need to be instantiated with the new command.
You can have a class that holds only state:
public class Person {
public string Name;
public string LastName;
public int Age;
}

Or classes that have a mix of state and helper methods.

public class Person {
public string Name;
public string LastName;
public int Age;

//helper method
public string getFullName() {
return Name + " " + LastName;
 }
}

And then we have classes that contain behavior. These are methods that
can change the state (the instance's data), changing the internal values held by
the instance of a class. Lists are a good example. You can instantiate a list,
fill it with elements (creating an internal state) and then add or remove or
reorder the elements inside the list, changing its state in the process.
This is where OOP may get confusing since one can use object-like things
in programming outside OOP languages. Strings for instance. A string
contains a state:
"Hello World"

And in many languages it will contain properties, helper methods, and

behaviors:
"Hello World".length;
"Hello World".substr(5);
"Hello World".toUpperCase();

The main difference is that with an OOP language you can create your own
data types by writing your own classes.
Let me give you an even better example to illustrate all this. Back in our
JavaScript code that I used to identify the shape of the planet, I used
JavaScript's key-value pair object for the pebbles:
var pebble = {radius: 10, color: "#000000", x: 100, y: 100};

This didn't create a type, however. JavaScript could not distinguish

between the pebble key-value pair and the center point key-value pair ({x:
100, y: 100}). To JavaScript, they were both of the same "type": a key-
value pair object. I happened to instantiate all pebbles inside a loop, but what
if I needed to create a new pebble somewhere else in the code. I might have
easily done this:
var pebble = {r: 10, color: "#000000", x: 100, y: 100};

And now my pebble no longer has a radius property, but instead, it has
an r property. My typo won't be picked up by the language because the
language doesn't know pebble belongs to a type. It thinks it's a new key-
value pair I happened to refer to as pebble. But with classes, I can get rid of
errors like this because I can create my own data type. Take a look:
public class Pebble {
public int radius;
public Color color;
public int x;
public int y;
public int vx;
public int vy;
}

Now Pebble is a type. And if I write myPebble = new Pebble()

and refer to myPebble.r, I'll get an error. The spellchecker will tell me that
the type or class Pebble does not contain a member called r. In the same
way that if you were to type "Hello World".vowels() you'd get an
error saying type string does not have a member called vowels().
The other thing we get with classes is better context. And I don't mean just
the fact that classes are something else we can name (besides variables and
functions) and therefore something else we can use to add context to our
code. In our JavaScript code I would have to write functions like this to
handle pebbles:
function movePebble (pebble) {}
function movePebbleTowardsPoint (pebble, point) {}
function checkCollision (pebble1, pebble2) {}
function drawPebble (pebble) {}

These are tasks operating on objects, as I said before. Each function would
receive key-value pairs representing the data for the pebbles and points—and
in the process, multiplying the sorts of errors I could generate with typos. But
with a class, I can create a Pebble entity containing properties and
behavior:
public class Pebble {
public int radius;
public Color color;
public int x;
public int y;
public int vx;
 public int vy;

public void move(){}

public void moveTowardsPoint(Point p){}
public void checkCollision(Pebble other){}
public void draw(){}
}

Suddenly, we can encapsulate data and behavior inside a Pebble entity.

And instead of calling:
movePebble(myPebble);
movePebbleTowardsPoint(myPebble, center);
checkCollision(myPebble, otherPebble);
drawPebble(myPebble);

I can now call them as:

var myPebble = new Pebble();
myPebble.move();
myPebble.moveTowardsPoint(center);
myPebble.checkCollision(otherPebble);
myPebble.draw();

It may seem like a tiny and superficial difference, but it isn't. Those
functions not only get better context through classes, helping me organize my
code in the process, but the entities (objects) can act on other entities and
contain other entities themselves, forming entire systems of interconnected
objects to help me express solutions. These systems can help me deal with all
sorts of distinctions in my logic.
Let's say we need to draw pebbles, which are basically circles, but we also
need to draw triangles and rectangles in our program representing different
types of objects—we saw that the way we draw shapes differs a lot, we use
one method for circles, another for squares, another for lines... Doing this
procedurally, we would have to handle the shape type somehow, as in:
void draw (shape, shapeType) {
if (shapeType == "Circle") {
drawCircle(shape);
} else if (shapeType == "Rectangle" ) {
drawRectangle(shape);
 } else if (shapeType == "Triangle" ) {
drawTriangle(shape);
}
}

My code would be peppered with logic handling all sorts of different

things: circles, rectangles, triangles... OOP however, allows me not only to
keep these distinctions organized into their own entities but also to group
different types of things and abstract common features they share, like a
draw() function, for instance, so that I can do this:
void draw (List<Shape> shapes) {
foreach (var shape in shapes) {
shape.draw();
}
}

I'll show you how you can accomplish something like this with OOP in a
moment. But for now, keep in mind that what makes this possible is the
ability to create these entities called objects and describe relationships these
objects may share. All through the use of classes.
OOP is a vast subject and it deserves its own book, but I want you to come
out of this chapter with this simple notion: classes put data (state) and
behavior together into one entity. As Feynman said, computers should be
called Data Handlers and OOP particularly should be thought of as a neat
way to describe, control, and organize data; encapsulating values alongside
the functions that will change them. I won't be able to show you all the main
aspects of OOP in the one example we'll work with, but I will try to explain
some of the main topics here. These are:

Static Classes and Properties

I told you just now how the Math class does not hold any state, but only
helper methods. Another peculiarity of the Math class is the fact it isn't
meant to be instantiated at all. It's a so-called static class and all its public
methods are further described with the static keyword. A static property
belongs to the class itself and not to the instances of the class.
public static class Math {
 public static double PI = 3.14159265359;
public static float Cos (float angle) {...}
public static float Floor (float number) {...}
...

You access these by using dot notation with the class name:
Math.PI;
Math.Cos(angle);
Math.Floor(number);

The static keyword is not limited to classes as I showed you. A regular

class might have a property or method declared as static and this will belong
to the class and not the instances. For example, imagine this class:
class Bullet {
public static int SPEED = 100;
public int damage = 10;
public float x;
public float y;
}

And let's say I instantiate a thousand Bullet objects. In the process, I

create a thousand damage variables, one belonging to each of the objects
(perhaps I'll have some bullets that cause more damage than others). But I
decided that all bullets would have the same speed, and therefore it would not
make sense to have a 1000 speed variables, so I made that property static;
this way, I only end up with one SPEED variable, the one declared in the
class (also known as a class level property). I can refer to it in the code like
this:
var newPositionX = x + Bullet.SPEED;

There are plenty other reasons static methods can be helpful, but I wanted
to make the distinction clear as to where they "exist" and how they are
accessed.
 Inheritance
Inheritance is the process by which a class can extend another. The most
common syntax used for this is:
class SubclassName extends SuperclassName {}

Inheritance introduces a new access modifier called protected. We

already saw public and private and these also can be said to take on
special behavior when dealing with inheritance.

A public property or function can be accessed from outside the class,

as we saw already, and it's shared by subclasses (classes that extend
another) and can be overridden by them. I'll show you in a bit an
example of what I mean by overridden.
A private property or function cannot be accessed from outside the
class, neither can it be shared or overridden by subclasses—it remains
hidden even to them.
A protected property behaves like a private property to the
outside, but as a public property to inheriting classes. Meaning, it can
be shared and overridden by subclasses but it is invisible to the outside.

If I create a class like this:

class SeasonOne {
protected List<string> characters;
protected List<string> episodes;
protected List<string> createCast();
private string pilot;
}

I can extend it like this:

class SeasonTwo extends SeasonOne {

I no longer need to declare the same protected or public properties,

in fact, I can't, I can only assign different values to them in my subclass. So
the fact we don't see them in SeasonTwo does not mean SeasonTwo does
not contain these properties, on the contrary. SeasonTwo is said to have
inherited them from SeasonOne. I can fill the lists in SeasonTwo with
new data if I want, or keep the same data I got from SeasonOne. But only
SeasonOne has a pilot because it's declared private and private
properties do not get inherited by subclasses the way public and
protected do. In fact, subclasses are not even aware a pilot exists in
SeasonOne, it's hidden from them.
Why is this inheriting thing important? I can use inheritance in clever ways
to reduce typing and errors. For instance:
class SeasonOne {

protected List<string> characters;

protected List<string> episodes;
private string pilot;

protected List<string> createCast() {

characters = new List<string>();
characters.Add ("John Hannibal Smith");
characters.Add ("Templeton Faceman Peck");
characters.Add ("Howling Mad Murdock");
characters.Add ("B. A. Baracus");
return characters;
}

class SeasonTwo extends SeasonOne {

override protected List<string> createCast() {

//check this out!

characters = super.createCast();

//now I can add new cast

//joining the cast from season one
characters.add ("Tawnia");

return characters;
}
}
 Pay special attention to the new keywords: override and super. Notice
the differences between the two createCast() methods, the one in the
super-class, and the one in the subclass. In SeasonTwo I override
createCast() so I can add my own logic to it (otherwise this method
would work exactly as described in the super-class). The overridden method
makes a call to its super class version and then continues on with the logic
described in the subclass version. It appends to the logic. It could also
override it completely and do its own thing entirely, just by omitting any call
to its super version.
And keep in mind that the protected properties and functions are no
longer accessible from outside the inheritance chain. To the outside, they
behave as private ones.
Inheritance can be used to create complex systems. You can use it to model
real world things and their relationships through code.

Abstract Classes
Not every OOP language supports abstract classes. They are useful in
relation to inheritance. It's a common thing to make your topmost super-
classes abstract. So what is an abstract class? It usually looks like this:
abstract class MyAbstractClass {
}

It cannot be instantiated, it can only be extended. If you try to use new

MyAbstractClass() you'll get an error. I can use the abstract class to
enter details I wish to share with all its subclasses without allowing them to
override or alter these details in any way. So you can use an abstract class to
create properties and behavior which will not vary inside an inheritance
chain.
I should note that the topic Abstraction by itself is a huge part of
programming and computer science in general and it can be applied in a
variety of different ways, in every language, every program. And even then it
can take on different meanings. One of them could be said to be the art of
thinking in general enough terms so that the same solutions can be applied to
the maximum number of problems. For instance, one can think of food and
time as resources and use equal solutions to solve the common issues these
two distinct things have when abstracted to the level of resource: how to get
more, how to use what I have wisely... I'm not saying they're the same, I'm
just saying they can be thought of as the same within a certain context. In this
sense abstraction means to chip away at complexities of a thing to focus on
its simplest elements and then use it to find similarities to many other things.
Programming is said to be an abstraction. Machine code looks like:
[ op | rs | rt | address/immediate]
35 3 8 68 decimal
100011 00011 01000 00000 00001 000100 binary

But we abstract that to something we can read:

void doTheNasty() {}

And this gets translated back by the compiler into machine code.
Here, abstraction means the creation of a higher level of expression, one
that does not deal with the nitty-gritty details and complexities but focuses on
the simple concepts (it leaves the complexity for lower level systems to
handle). Abstraction is a constant concern in OOP (and in many respects, its
downfall): how to make more distinct things be treated as the same thing, at
least as far as some specific problem is concerned. All this can be achieved
with the use of inheritance and abstract classes. But especially with the next
topic...

Interfaces
They are sometimes called Protocols and again not every OOP language
supports them. They can be thought of as "contracts" or "slices of behavior"
and are better explained through an example. So let's say you created a new
cloud service, like Dropbox, and you coded a huge API to let programmers
use code to push things to this cloud drive they rent from you. You tell them
they need to import your library and use your API to instantiate your service
class like this:
var cloudService = new Smoky();

Yes, your cloud company is called Smoky. It comes with all sorts of helpful
public methods. For instance, users can upload files to it:
cloudService.push (notPorn.mp4);

But what if Smoky wants to send its users updates on the upload and notify
them when the upload is finished. Inside the Smoky class, the push()
method looks like this:
void push (Bytes[] file) {}

But since we want to notify the client of upload updates (is it done? if not
how much longer will it take?), we need a reference to the client application
so Smoky can notify it, therefore the client needs to push files like this:
cloudService.push (notPorn.mp4, this);

Passing a reference to itself so it can be notified (that's what the keyword

this is doing). But what does that look inside the Smoky class?
void push (Bytes[] file, ??? client ) {}

I don't know the client type and I don't want to know. It could be anything.
It could be NotPornVideos, or FileUploader, or
ArchivoSubidor... My Smoky class has no ability to talk to its clients!
But fear not. We got interfaces:
public interface ISmokyClient {
void onUploadProgress (float progress);
void onUploadComplete();
void onUploadError();
}

An interface is a contract. It only specifies names and signatures of

functions (and sometimes properties) one should find in anything that claims
to fulfill this contract. The client's class, let's pick ArchivoSubidor for
this, will now look like this:
using Smoky;

public class ArchivoSubidor implements ISmokyClient {

public void onUploadProgress (float progress) {}

public void onUploadComplete() {}
 public void onUploadError() {}

private Smoky cloudService = new Smoky();

public void subirArchivo () {

cloudService.push (notPorn.mp4, this);
}
}

ArchivoSubidor is said to implement the interface ISmokyClient.

It must now contain the same methods listed in the interface.
And Smoky's push method will look like this now:
void push (Bytes[] file, ISmokyClient client ) {
...
}

When I used this inside the subirArchivo() method, this did not
refer any longer to an instance of ArchivoSubidor but to an instance of
ISmokyClient, or rather to an object that implements that interface.
Now the push method can call client.onUploadProgress(),
client.onUploadComplete() and client.onUploadError()
because the client must implement the contract ISmokyClient and
therefore it will contain those methods. No explosions.
The other way you can think of interfaces, as I said, is comparing them to
slices of behavior. We go back to good old abstraction for this. Think of this
class:
class You {
}

You are someone's child, someone's friend, someone's employee,

someone's luuuuuver! You have different behaviors depending on who you're
with (one hopes). But this is all You. However, your employer doesn't care
about your smooching() method, just as your friends don't need to
feed() you. Instead, your behavior is sliced up as a series of interfaces:
IChild, IFriend, IEmployee, ILuuuuuver! (it's a common
convention to name interfaces starting with a capital i). Your Employer
class will treat You as an IEmployee type and interact with You through
that interface only, it doesn't need to know You, it thinks of you simply as an
instance of IEmployee. So will your mother and friends deal with you
through the IChild and IFriend interface respectively. And your special
friend? Through ILuuuuuver!, of course. You can use interfaces to
abstract what different things have in common and therefore your
Employer class will be able to interact with everybody at work through an
IEmployee interface, independent of the fact they're actually You, and
Bob, and Jane... We're all just numbers to these people. ICattle! Nothing
more than ICattle!

Generics
This too is not supported by all OOP languages and it can be found in the
other paradigms. We saw it when we created Lists:
var list1 = new List<string>();
var list2 = new List<IEmployee>();

Generics is the < and > signs containing a type.

The List class is declared like:
public class List<T> {
}

Or something like it. T is a convention for the first generic type a class or
function will handle. It stands for TYPE. You could have multiple generic
types and also use them in functions as well as classes:
void doSomethingWithThis <T, R, Q> (T thingNumberOne, R
thingNumberTwo, Q thingNumberThree);

Generics allows a class or function to handle different types. One code to

rule them all. There's a special syntax you can use to limit what the mystery
TYPE can be, by saying it conforms to certain interfaces, for instance, or that
it's definitely a class and not a primitive type. I can use generics to write one
List class, for instance, that can store any type (string, integers, Murders),
or any type that conforms to certain rules. It makes code more... generic. And
by stating that a certain list stores strings (List<string>), when I retrieve
something from this list the compiler knows to treat it as a string and so it can
help me with code completion and proper error checking if I suddenly decide
to treat the thing as an integer, say. Of course, it should be obvious by now
that generics are only a thing if the language you're using is crazy about
types.
Imagine you want to write a function that shuffles a list. But a list of what?
Ideally, the function would shuffle any list, holding any type. With generics, I
can write this:
public List<T> Shuffle (List<T> list) { ... }

And it would work with any type.

All this leads us, finally, to...

Polymorphism
This is the fancy term used to describe a feature shared by Inheritance and
Interfaces: The ability to make code behave as "many different things" or
accomplish "many different things"—polymorphism means many forms.
When I mentioned that we could solve the problem of drawing many
different shapes like this:
void draw (List<Shape> shapes) {
foreach (var shape in shapes) {
shape.draw();
}
}

I meant the problem can be solved by polymorphism. The Shape class

could be a super-class of Circle, Triangle and Rectangle and that
class contains a draw() method. Polymorphism is the ability in this case to
treat subclasses as instances of their super-class. Circle would implement
its own draw() method, by overriding the one it inherited from Shape. So
would the other shapes. However, the program knows when a Shape is
actually a Circle and knows to call the draw() method implemented
inside the subclass Circle. Just like magic!
And the same thing could be accomplished this way:
void draw (List<IShape> shapes) {
 foreach (var shape in shapes) {
shape.draw();
}
}

Using interfaces this time instead of inheritance. Circle, Triangle and

Rectangle would implement the same interface:
public interface IShape {
void draw();
}

And so be required to implement their own draw() method. In the OOP

world, there is a whole drama going on about which is better: to extend or to
implement an interface? The answer is obviously to implement an interface.
Only idiots use inheritance. (See? I'm doing it too!)
We can achieve something similar with Generics and also higher-order
functions (which are often referred to as polymorphic functions). Ultimately,
this is the ability to make the same code accomplish different results, and to
behave differently according to context.
Polymorphism can be used in all sorts of strange relationships. Its main
goal is not really to save on typing (or not just that), but to create systems that
can expand without causing errors. For instance, this beauty:
public abstract class Kryptonite {
public string GetSymptom(){ return ""; }
}

public class GreenKryptonite extends Kryptonite {

override public string GetSymptom(){
return "Flu-like symptoms";
}
}

public class RedKryptonite extends Kryptonite {

static Random rnd = new Random();

private List<string> _symptoms = new List<string> {

"Turn evil",
 "Insanity",
"Lose powers",
"Grow old"
};

override public string GetSymptom(){

int r = rnd.Next(_symptoms.Count);
return _symptoms[r];
}
}

public class Superman {

public void ExposeToKryptonite (Kryptonite k) {

var effects = k.GetSymptoms();
//code making Superman suffer
//starts here...
}
}

var superman = new Superman();

var specialK = new RedKryptonite();
superman.ExposeToKryptonite (specialK);

We can create odd little systems like this one that allows us to keep adding
new types of Kryptonite without breaking anything in the code. We just need
to create new types that conform to the same relationship, described either as
a super-class or interface, and, this way, keep messing with Superman big
time.
It is a valid goal, in all paradigms, to make your code as polymorphic as
you can. But don't kill yourself over this.
Speaking of killing. Now it's time to actually code something using OOP.
 4
Object-Oriented Murder
So how about coding Cluedo with classes?
In order to code Cluedo in this paradigm, we wouldn't need to change
much. Our game would be a class, with a state and behavior. And so would
our detectives.
I called the game class MurderMystery:
public class MurderMystery {

The class holds the lists of clues as part of its data:

public class MurderMystery {

public List<string> suspects = new List<string> {

"Colonel Mustard",
"Professor Ketchup",
"Mrs Mayonnaise",
"Miss Relish",
"Violet Beauregarde"
};

public List<string> locations = new List<string> {

"Library",
"Drawing Room",
"Sitting Room",
"Music Room",
"Game Room"
};

public List<string> weapons = new List<string> {

 "Pipe",
"Candle holder",
"Rope",
"Gun",
"Poison",
};

public List<string> motives = new List<string> {

"Money",
"Love",
"Blackmailing",
"Revenge",
"Something to do",
};
}

It will also store the murder, but I'll deal with that in a second. I'll keep the
boolean and the detective index same as before:
private bool _myterySolved = false;
private int _detectiveIndex = 0;

There is no need to make these public because A) they're meant for internal
use of the MurderMystery class and B) they're dangerous properties that
can change the entire behavior of the application if manipulated by mistake
from outside the object.
From here on out we could follow most of the logic we coded in the
procedural version. The one main difference would be the creation of a
Detective class. In my procedural code, I had to keep the different
properties for each detective in separate dictionaries keyed to the detective's
name. Now I can create one single Detective entity with properties and
behavior. We have a pretty good notion of what this class should do. A
Detective has:

A name.
A list of original clues.
A list of collected clues.
A method to create theories.
A method to check a theory against its original clues.
 And we can think also in terms of encapsulation: what is it we need to
expose to outside code and what can we keep inaccessible, for internal use
only? The list of clues can be kept private. The method to generate a theory
and to check theories should be public since other objects may need to call
these:
public class Detective {

public string name;

private List<string> _originalClues = new List<string>();
private List<string> _collectedClues = new List<string>();
}

A class has a special method called a constructor. In most OOP languages a

class constructor will have the same name as the class but in some languages,
a constructor has a fixed name like init() or even constructor(). We
can use this method to pass information held by each individual instance of
Detective as we instantiate the objects. Like our detective name.
public Detective(string name) {
this.name = name;
}

Constructors never return anything in C#, coding it otherwise will

cause an error.

The keyword this refers to "this instance" of Detective. It can be

used, as in this example, to distinguish between the instance property name
and the name argument being passed to the function.
Our detective objects would be instantiated like this inside
MurderMystery:
var detective = new Detective ("Poirot");

So the constructor is the function you use with the new keyword. If you
don't need to pass arguments to a constructor you can skip it in your class and
a default constructor will be added by the compiler so that this would work
no matter what:
var detective = new Detective ();
 Default constructors are always parameterless. C# even allows a special
syntax when you use default constructors:
var detective = new Detective {
name = "Poirot"
};

It both creates an instance and sets values to its public properties. We used
them with the List class before.
Since I made the lists private, let me add some public methods to add clues:
public void AddOriginalClue (string clue) {
_originalClues.Add(clue);
AddClue(clue);
}

public void AddClue (string clue) {

_collectedClues.Add(clue);
}

Notice how AddOriginalClue() will also add the clue to the

_collectedClues list. Just as we had in our previous version. Now we
can use dot notation to use these methods with our instances of Detective:
var detective = new Detective ("Poirot");
detective.AddClue("Pipe");

How about adding a MakeTheory() method to our Detective class?

We would hit our first boundary issue here. In our procedural code,
everything was dumped in the global scope and we had access to all the data.
But here, the Detective class has no idea of the lists of clues available in
MurderMystery since it has no reference to an instance of that class. But
in order to build a theory, we need access to the suspects, locations, weapons,
and motives located in that class. Therefore it makes sense that each
Detective should have access to an instance of MurderMystery:
private MurderMystery _mystery;

public Detective(string name, MurderMystery mystery) {

this.name = name;
_mystery = mystery;
}

We change the constructor, passing it a murder mystery instance as a

second parameter and store that as a private property inside Detective. In
OOP this is known as object composition when an object is constructed with
references to other objects. Our MakeTheory() method can now pick
random clues from the various pools, one for a suspect, one for location, one
for a weapon, and one for motive since these are all made public by
MurderMystery. Sounds like a good place for a helper method. Inside
Detective, I add this:
private string GetClue(List<string> clues) {
var random = new Random();
List<string> list =
clues.Where( (s) => !_collectedClues.Contains(s) ).ToList();
return list[random.Next(list.Count)];
}

By the way, by now we need a few imports in our code, like

System.Collections.Generic and System.Linq

We filter the clues list being passed to the method (remember C# calls its
filter() higher-order function: Where()), removing any of the clues we
already collected. The exclamation point, if you recall, means "not".
!_collectedClues.Contains(s)

This means _collectedClues Does Not Contain element s.

I don't want to create a new Random() instance each time I call this
function, so we add yet another property to Detective:
private Random _random = new Random();

And use that inside GetClue():

private string GetClue(List<string> clues) {
List<string> list =
clues.Where(
(s) =>
!_collectedClues.Contains(s) ).ToList();
 return list[_random.Next(list.Count)];
}

We're ready to work on the MakeTheory() method. In our previous

version, we created an array of strings to represent our theory. Let's recreate
that logic first:
public string[] MakeTheory () {
var theory = new string[4];
theory[0] = GetClue(_mystery.suspects);
theory[1] = GetClue(_mystery.locations);
theory[2] = GetClue(_mystery.weapons);
theory[3] = GetClue(_mystery.motives);
return theory;
}

Notice how we grab the lists of clues from our _mystery instance.
But now we can name things better using classes and add context to our
data. We can create a Theory class and use that in our MakeTheory()
method. Something like:
public Theory MakeTheory () {
return new Theory {
who = GetClue(_mystery.suspects),
why = GetClue(_mystery.motives),
where = GetClue(_mystery.locations),
how = GetClue(_mystery.weapons),
};
}

And that class would look like this:

public class Theory {

public string who;

public string where;
public string how;
public string why;

public bool Matches (Theory theory) {

return this.who == theory.who &&
this.where == theory.where &&
 this.how == theory.how &&
this.why == theory.why;
}

public bool ContainsClue (string clue) {

// || means OR in C#
return who == clue ||
where == clue ||
how == clue ||
why == clue;
}

override public string ToString () {

return string.Format("It was {0}, in the {1}, with the {2}, all
for the sake of {3}", who, where, how, why);
}
}

We have a name for each of the clues. A helper method to check if a theory
matches another. A helper method to check if the theory contains a certain
clue. And then we have something... odd. We override a super-class method
but our class does not extend anything. Huh? The reason the third helper
method has the keyword override is because this Theory class, even
though it does not say so, already extends the base C# class Object (all
classes in C# do). The class Theory inherits from the class Object. And
the C# Object class has a ToString() method which details how an
object is described as a string. This string is used whenever you print a type
to the console. When you call Console.WriteLine() passing it an
object, C# will call that object's ToString() and print its result. And if you
want more meaningful strings (to help test your code, for instance) you
override the ToString() method of your classes, creating your own
version of what it's supposed to do when asked to describe itself as a string.
The Matches() function needs to drill into the object itself to guarantee
equality. This can be accomplished in other ways, but it will depend on how
complex your classes are (you might prove equality between objects in all
sorts of different ways). Here, I simply compare the values for who, where,
how, and why from the two theories.
OK. We have a Theory class and our Detective can generate theories.
We're almost done with Detective. We need a way to check theories
against the detective's original clues:
public string CheckTheory (Theory theory) {
if (_originalClues.Contains(theory.who))
return theory.who;
if (_originalClues.Contains(theory.why))
return theory.why;
if (_originalClues.Contains(theory.where))
return theory.where;
if (_originalClues.Contains(theory.how))
return theory.how;
return null;
}

A bit sloppy though, isn't it? I'm forcing an order by which clues are
checked: first who, then why, and so forth. What if I wanted to randomly pick
a clue from the ones I found a match for? I could have added something like
this to the Theory class:
public List<string> ToList () {
return new List<string> {
this.who,
this.where,
this.how,
this.why
};
}

And rewrite CheckTheory() in Detective like this:

public string CheckTheory(Theory theory) {

//get Theory as a list of clues

var clues = theory.ToList();

//shuffle the list of clues

clues = clues.OrderBy(
x => _random.Next()).ToList();

//look for each clue inside _originalClues

foreach (var clue in clues) {
 if (_originalClues.Contains(clue)) {
return clue;
}
}
return null;
}

With this, I can get the clues in Theory as a List and shuffle that. The
line:
clues.OrderBy ( x => _random.Next()).ToList();

... is a quick and simple way to shuffle a list in C#. We've used another
algorithm before in this book when we shuffled a deck of cards with
JavaScript:
return deck.sort(function() { return 0.5 - Math.random() });

In C# we could use the same thing using C# syntax:

clues.OrderBy ( x => 0.5 - _random.NextDouble() ).ToList();

And notice that x is not used for anything in the lambda, remember how we
can write it instead? We can write it as Any.
clues.OrderBy ( _ => 0.5 - _random.NextDouble() ).ToList();

Anyway... where were we? Ah, yes. We finished Detective. Now we

can add a list of detectives to our MurderMystery class:
public class MurderMystery {
private List<Detective> _detectives = new List<Detective>();
...
}

And we can declare our murder:

private Theory _murder;

So how about if our MurderMystery constructor looked like this:

public MurderMystery( string[] detectiveNames ) {

foreach (var name in detectiveNames) {

var detective = new Detective(name, this);
 _detectives.Add(detective);
}
}

We pass it an array of detective names and it takes care of creating the

detectives and storing them in a list. Notice how the instance of
MurderMystery is fed to the Detective constructor using this. Skip
any of these arguments and the editor will let you know you missed
something, a huge advantage when creating your own types.
Next, we can create our murder and distribute the clues just like we did in
our procedural version. We can create the same helper methods as before for
these purposes. Here is the same logic but now in C#:
private Random _random = new Random();

private string GetRandomItem (List<string> list,

bool removeItem = false) {
if (list.Count == 0) return "";
var index = _random.Next(list.Count);
var item = list[index];
if (removeItem) list.Remove(item);
return item;
}

private void DistributeClues (List<string> clues,

Theory murder) {

var _clues = clues.Where(

clue => !murder.Contains(clue)).ToList();

while (_clues.Count > 0) {

_detectives.ForEach((d) => {
var _clue = GetRandomItem(_clues, true);
d.AddOriginalClue(_clue);
});
}
}

Oh, oh. MurderMystery will have its own random number generator,
and each detective will have its own random generator... Nope. Don't like it.
Instead, we declare our _random in MurderMystery like this instead:
public class MurderMystery {

//say this really fast!

public static Random RANDOM = new Random();
...
}

static will make this property class level. It means when I instantiate
MurderMystery, the RANDOM property won't be duplicated, it's
instantiated in the class itself. I can refer to my random generator like this
now:
MurderMystery.RANDOM

And to drive home the point that the static keyword denotes a class
level property, this would throw an error:
var mystery = new MurderMystery();
var randomNumber = mystery.RANDOM.Next();

There is no RANDOM property inside the instance of MurderMystery

only in the class itself:
var randomNumber = MurderMystery.RANDOM.Next();

We need to make some changes now. In MurderMystery we change:

private string GetRandomItem(List<string> list,
bool removeItem = false) {
if (list.Count == 0) return "";
var index = MurderMystery.RANDOM.Next(list.Count);
var item = list[index];
if (removeItem) list.Remove(item);
return item;
}

And in the Detective class as well, where we can remove its _random
property and use the static one from MurderMystery since it has been
declared public. Notice that here, I don't need a special reference to
MurderMystery in order to access that static property. Detective has
access to the MurderMystery class just as it has access to any other class,
like List.
public string CheckTheory(Theory theory) {
var clues = theory.ToList();
clues = clues.OrderBy(x =>
MurderMystery.RANDOM.Next()).ToList();
foreach (var clue in clues) {
if (_originalClues.Contains(clue)) {
return clue;
}
}
return null;
}

private string GetClue(List<string> clues) {

List<string> list =
clues.Where(
(s) =>
!_collectedClues.Contains(s)).ToList();
return list[MurderMystery.RANDOM.Next(list.Count)];
}

We can now create the murder and distribute the clues. And we can do all
that inside the the MurderMystery constructor, which will look like this:
public MurderMystery( string[] detectiveNames ) {

_murder = new Theory {

who = GetRandomItem(suspects),
why = GetRandomItem(motives),
how = GetRandomItem(weapons),
where = GetRandomItem(locations),
};

foreach (var name in detectiveNames) {

var detective = new Detective(name, this);
_detectives.Add(detective);
}

DistributeClues(suspects, _murder);
DistributeClues(weapons, _murder);
 DistributeClues(locations, _murder);
DistributeClues(motives, _murder);
}

This is almost word for word what we did in Python to initialize the game.
Our version of the PlayGame() method would also look very similar to
what we did before. And the only thing missing before we can code
PlayGame() is the helper method that loops through detectives and checks
a theory against their original clues. This goes inside MurderMystery and
it can be made private because it only needs to be accessed locally by the
MurderMystery instance:
private string FindClueForTheory ( Theory theory) {

var _nextIndex = (_detectiveIndex + 1)

% _detectives.Count;

while (_nextIndex != _detectiveIndex) {

var _detective = _detectives[_nextIndex];
var newClue = _detective.CheckTheory(theory);
if (newClue != null) return newClue;
_nextIndex = (_nextIndex + 1) % _detectives.Count;
}

return null;
}

The loop is done the same way as before, but now we can ask each
individual detective objects whether a theory returns a clue using the
detective's own method (_detective.CheckTheory()). We're ready to
code PlayGame():
public void PlayGame() {

var game_rounds = 0;

while (!_myterySolved) {

var detective = _detectives[_detectiveIndex];

var theory = detective.MakeTheory();
var newClue = FindClueForTheory(theory);
 if (newClue == null) {

if (_murder.Matches(theory)) {
_myterySolved = true;

Console.WriteLine(
string.Format(
"{0} solved the mystery! {1}
detective.name,
theory
)
);
Console.WriteLine(
string.Format("Total Rounds: {0}", game_rounds)
);
Console.WriteLine(_murder);

}
} else {
detective.AddClue(newClue);
}
game_rounds += 1;
_detectiveIndex = (_detectiveIndex + 1)
% _detectives.Count;
}
}

If we're unable to find a clue to shoot down a theory,

FindClueForTheory() will return null (which in Python we referred to
as None).
var newClue = FindClueForTheory(theory);

Therefore, if the return is null we can check whether the murder matches
our theory.
if (newClue == null) {
if (_murder.Matches(theory)) {
//we have solved it!
}
}
 If FindClueForTheory() doesn't return null it will return a clue
instead. We collect this clue:
if (newClue == null) {
...
} else {
detective.AddClue(newClue);
}

Finally, we can run the application like this inside Main():

public static void Main(string[] args) {

var game = new MurderMystery (

new string[] { "Poirot", "Sherlock Holmes", "Velma", "Shaft" }
);
game.PlayGame();

Before I can show you a way to improve the code slightly, here's the
complete code:
using System;
using System.Collections.Generic;
using System.Linq;

namespace mystery_solver
{

public class Program {

public static void Main(string[] args) {

var game = new MurderMystery(
new string[] { "Poirot", "Sherlock Holmes",
"Velma", "Shaft" });
game.PlayGame();
}
}
public class MurderMystery {

public List<string> suspects = new List<string> {

"Colonel Mustard",
"Professor Ketchup",
"Mrs Mayonnaise",
"Miss Relish",
"Violet Beauregarde"
};

public List<string> locations = new List<string> {

"Library",
"Drawing room",
"Sitting room",
"Music room",
"Game room"
};

public List<string> weapons = new List<string> {

"Pipe",
"Candle Holder",
"Rope",
"Gun",
"Poison",
};

public List<string> motives = new List<string> {

"Money",
"Love",
"Blackmailing",
"Revenge",
"Something to do",
};

private List<Detective> _detectives = new List<Detective>();

private Theory _murder;
private bool _myterySolved = false;
private int _detectiveIndex = 0;

public static Random RANDOM = new Random();

public MurderMystery(string[] detectiveNames) {

_murder = new Theory {

who = GetRandomItem(suspects),
why = GetRandomItem(motives),
how = GetRandomItem(weapons),
where = GetRandomItem(locations),
};

foreach (var name in detectiveNames) {

var detective = new Detective(name, this);
_detectives.Add(detective);
}

DistributeClues(suspects, _murder);
DistributeClues(weapons, _murder);
DistributeClues(locations, _murder);
DistributeClues(motives, _murder);

public void PlayGame() {

var game_rounds = 0;
while (!_myterySolved) {
var detective = _detectives[_detectiveIndex];

var theory = detective.MakeTheory();

var newClue = FindClueForTheory(theory);
if (newClue == null) {

if (_murder.Matches(theory)) {
_myterySolved = true;
Console.WriteLine(
string.Format("{0} solved the mystery! {1}",
detective.name,
theory
));
Console.WriteLine(
string.Format("Total Rounds: {0}",
game_rounds)
 );
Console.WriteLine(_murder);
}
} else {
detective.AddClue(newClue);
}
game_rounds += 1;
_detectiveIndex = (_detectiveIndex + 1)
% _detectives.Count;
}
}

private string FindClueForTheory(Theory theory) {

var _nextIndex = (_detectiveIndex + 1)

% _detectives.Count;

while (_nextIndex != _detectiveIndex) {

var _detective = _detectives[_nextIndex];
var newClue = _detective.CheckTheory(theory);
if (newClue != null) return newClue;
_nextIndex = (_nextIndex + 1) % _detectives.Count;
}

return null;
}

private void DistributeClues(List<string> clues,

Theory murder) {
var _clues = clues.Where(
clue => !murder.Contains(clue)).ToList();

while (_clues.Count > 0) {

_detectives.ForEach((d) => {
var _clue = GetRandomItem(_clues, true);
d.AddOriginalClue(_clue);
});
}
}

private string GetRandomItem(List<string> list,

 bool removeItem = false) {
if (list.Count == 0) return "";
var index = MurderMystery.RANDOM.Next(list.Count);
var item = list[index];
if (removeItem) list.Remove(item);
return item;
}
}

public class Detective {

public string name;

private MurderMystery mystery;

private List<string> _originalClues =
new List<string>();
private List<string> _collectedClues =
new List<string>();

public Detective(string name, MurderMystery mystery) {

this.name = name;
this.mystery = mystery;
}

public void AddOriginalClue(string clue) {

_originalClues.Add(clue);
AddClue(clue);
}

public void AddClue(string clue) {

_collectedClues.Add(clue);
}

public Theory MakeTheory() {

return new Theory {
who = GetClue(mystery.suspects),
why = GetClue(mystery.motives),
where = GetClue(mystery.locations),
how = GetClue(mystery.weapons),
};
 }

public string CheckTheory(Theory theory) {

var clues = theory.ToList();
clues = clues.OrderBy(
x => MurderMystery.RANDOM.Next())
.ToList();
foreach (var clue in clues) {
if (_originalClues.Contains(clue)) {
return clue;
}
}
return null;
}

private string GetClue(List<string> clues) {

List<string> list =
clues.Where(
(s) => !_collectedClues.Contains(s)).ToList();
return list[MurderMystery.RANDOM.Next(list.Count)];
}

override public string ToString() {

return string.Join(", ", _collectedClues);
}
}

public class Theory {

public string who;

public string where;
public string how;
public string why;

public bool Matches(Theory theory) {

return who == theory.who &&
where == theory.where &&
how == theory.how &&
why == theory.why;
}
 public bool Contains (string value) {
return who == value ||
where == value ||
how == value ||
why == value;
}

public List<string> ToList() {

return new List<string> {
this.who,
this.where,
this.how,
this.why
};
}

override public string ToString() {

return string.Format("It was {0}, in the {1}, with the {2},
all for the sake of {3}",
who,
where,
how,
why
);
}
}
}

Normally, each class would be in a separate text file (with a .cs extension
in C#). But you can code them all in one file like we did here.
I'll leave as an exercise the conversion of the extra tests I coded in Python,
but this time using OOP and the classes seen here. Try creating a
TestClass instead of adding the tests to MurderMystery.
So what else could we do?
Before OOP, I mentioned two ways one could create context in code: by
naming variables and functions. For instance:
var age = 30;
var distanceInKM = 30;
var processedFiles = 30;
addYears(2);
getDistance();
isFileProcessed();

The right context increases the likelihood that you'll know what each
variable stands for and the signature for each one of those functions (what
gets passed to it or returned from it). With OOP we added a third way to add
context: Classes. But we can add two more to that list: Enums and
Namespaces. These are not exclusive to Object-Oriented languages, although
I can't say they're present in every procedural language—JavaScript doesn't
have them, yet—but they are quite common. We saw namespaces in our
imports (when we wrote lines like using System.Text, import
random, import math). Sometimes they're called modules or packages.
Potato, potahto. They are primarily used for code organization and to reduce
conflict or collision. For instance, it's easy to come up with functions called
addYears() for a variety of different purposes; functions that go about
"adding years" in quite different ways. And it's possible you'll work on a
project where your imported modules will have functions sharing the same
name you gave your functions. Namespaces can ensure these functions are
contained within their own context, and so they do not conflict or collide.
And they provide context:
using DogYears;

var dog = new Dog();

dog.age = AddYears(3);
//DogYears.AddYears(3);
...

using EmploymentHistory;

var employee = new Employee();

employee.activeTime = AddYears(3);
//EmploymentHistory.AddYears(3);

Depending on the language, you can create a namespace by adding code to

a specific file and the name of that file will become the namespace. Or to add
code to a specific folder and the same thing will happen with the name of the
folder. Or simply by creating a namespace block as we do in C# :
namespace mySuperDuperApplication {
//my namespace code will go here
}

Enums are, in their most basic form, a neat way to name OR values. What
are these? Imagine you want to store the day of the week some action will
take place.
var iWillDoThisOn = "monday";

Well, okay. But that's not really Monday. That's a string. If you had an if
statement checking when iWillDoThisOn, you'd need to make sure the
value is lowercase so as to reduce errors and make sure other spelling errors
won't get in the way. Or create something like:
const MONDAY = "monday";
const TUESDAY = "tuesday";
...

var iWillDoThisOn = MONDAY;

That way you'll only type the value of each day once. You could also use
integers for values and keep referring to them using the constant's name).
const MONDAY = 0;
const TUESDAY = 1;
...
var iWillDoThisOn = MONDAY;

But then again you might copy and paste code and end up with:
const MONDAY = 0;
const TUESDAY = 0;
...

var iWillDoThisOn = MONDAY;

And there goes your Tuesdays.

Enum, in its most basic form, is a way to simplify this process:
enum WeekDays {
MONDAY,
 TUESDAY,
WEDNESDAY,
THURSDAY,
FRIDAY,
SATURDAY,
SUNDAY,
}

var iWillDoThisOn = WeekDays.MONDAY;

They're called OR types because the value iWillDoThisOn can only be

MONDAY or TUESDAY or WEDNESDAY ... and so forth. This version of
enum, by far the most common you'll see, actually treats each value as an
integer, and simply allows you to refer to them using keywords. They are a
very powerful way to add context by making code easier to read but also by
limiting values in your logic to a closed set.
And how can we use this to help improve our MurderMystery? How
about we change our code this way, declaring an enum:
public enum ClueType {
Suspect,
Location,
Weapon,
Motive
}

And then the clues in MurderMystery are listed using a Dictionary,

with the ClueType enum as the key:
public Dictionary<ClueType, List<string>> clues = new
Dictionary<ClueType, List<string>>() {

{ ClueType.Suspect, new List<string> { "Colonel Mustard",

"Professor Ketchup", "Mrs Mayonnaise", "Miss Relish", "Violet
Beauregarde" }},

{ ClueType.Location, new List<string> { "Library", "Drawing room",

"Sitting room", "Music room","Game room" }},

{ ClueType.Weapon, new List<string> { "Pipe", "Candle holder",

"Rope", "Gun", "Poison" }},
 { ClueType.Motive, new List<string> {
"Money","Love","Blackmailing","Revenge","Something to do" }},

};

As an exercise, I'll leave to you to update the code to use this dictionary
instead. Try to use the enum and change the game classes so that the code
automatically picks one clue from each clue type when generating theories
and printing the solution to the console. Here's a hint. This is how you can
collect all options from an enum type and then loop through them:
var values = Enum.GetValues(typeof(ClueType));

And that's it for OOP. (As if!)

 5
Functional Programming 101
I won't lie to you. Functional Programming will make you feel like you're
starting to learn to program all over again. New syntax, new ideas... I've
heard said that if a new programmer starts learning functional languages first,
he or she will be able to quickly move on to non-functional languages but
that the reverse is not always true. If one starts learning to code with object-
oriented programming, for instance, the hurdles learning this new paradigm
will be steeper. So much so that OOP programmers tend to stay the hell away
from anything we'll see here in this chapter. Want to impress someone who
learned to code with OOP? Tell them you know a functional language.
They'll turn pale and avoid looking you in the eyes.
Functional programming matters a great deal. I believe it can make you a
much better coder and provide you with more opportunities for having fun.
But it won't feel like it at first. We need to go back to that Kierkegaard quote
about limitations making one more resourceful and the whole idea of
constrained writing. Functional programming will feel more constrained than
anything else we've used thus far, but this is in part an illusion since it allows
us to express ideas in more ways than we've seen.
It's not hard to learn functional programming but it is hard to teach it. Read
any book on the subject and it feels like Eckhart Tolle is trying to teach you
programming. I can relate to it and so will you in a moment. This chapter will
feel like Eckhart Tolle is teaching you programming. For that, I apologize.
So what the hell is Functional Programming? It stems from an idea by the
famous mathematician and computer scientist Alonzo Church and his
creation of Lambda Calculus. We get the name lambda for anonymous
functions from that. In essence, it's the idea that every operation must be
described as a function and every function needs to be a pure function. This
"pure-function" thing always sounded a bit Nazi to me. But what it means is a
function that is self-contained: it does not change anything outside its scope
and, ideally, returns some value. And whenever fed the same arguments the
pure function will spit out the same result. Guaranteed.
It's hard to talk about functional programming without talking first of the
problems it tries to address. In almost every definition of this paradigm, you
will find a mention to side effects. And what is a side effect in programming?
Whenever a function, and ideally we're speaking of pure functions here, does
something other than return a value, this something other is called a side
effect. For instance, the print functions we've been using. Those functions
return void (or unit, as F# calls it) and print out something to the console. The
"printing out" thing is a side effect. It's like the function is over-extending
itself. And this is perfectly normal behavior. F# will have many functions that
produce side effects like this. They are not errors, but are rather fissures
through which problems may seep in. I said before how in programming one
needs to think of all possible instances of a program and side effects are
things that have great potential of becoming big problems in some not-so-
obvious instances of your programs. They force programmers to make use of
defensive logic to make sure these problems don't explode in their faces.
Let me give you some examples of what I mean.
Start changing things outside a function's scope and you create couplings,
meaning this function can only operate if the thing outside itself is there.
var myValue = 10

function changeValue () {
myValue += 1
}

What if myValue is no longer there or it's not an integer?

changeValue() will produce an error, that's what'll happen. I admit this is
an odd scenario, and maybe hard to come by in the real world but boy will
humans surprise you! Start creating couplings like this and you create what is
known as a side effect.
And how about this code:
Object myObject = null

if something = true
myObject = new Object("1");
else
myObject = new Object("2");

If statements are... well, statements. They're not expressions. An

expression returns something and since if statements are not expressions I
must first declare a variable pointing to null and change that variable
depending on some condition inside the statement's scope. We could write
the above statement with a ternary expression instead:
var myObject = something == true ?
new Object("1") : new Object("2")

Now, this is an expression and expressions return something. So far so

good. But what about this:
Object myObject = null

if somethingElse = true
myObject = new Object("3")

Now I no longer know if myObject will be null or hold a value.

Whenever I use myObject in my code, I, the programmer, must remember
to check if it does exist, using what it's known as defensive programming.
if (myObject != null) myObject.doSomething()

myObject becomes a kind of side effect—although it might not properly

fit the definition—because it requires that I keep checking on its value
whenever I refer to it but it does not explicitly tell me so. I created an
instance of the program where myObject may not exist. In this sense Null
becomes a side effect. In my OOP version of Cluedo, I created at least one
function that can return null (when I checked a detective's theory with other
detectives). I created the need to check whether that function returned
something or not and yet did not make this explicit therefore easy to forget.
Worse still, I made null part of my logic, I used it to solve a problem but the
code has no way of making this clear. To some programmers, this is the
equivalent of kicking a puppy.
Now look at this:
class MyClass1 {
MyClass1( OtherClass object) {}
}

class MyClass2 {
MyClass2( OtherClass object) {}
}

At some point in my code, I will need to instantiate an object of type

OtherClass and use it to instantiate objects of types MyClass1 and
MyClass2. Depending on the logic itself, I might do it like:
var c1 = new MyClass1( new OtherClass() );
var c2 = new MyClass2 ( new OtherClass() );

And so far so good. But what if my logic says the instance of

OtherClass is shared by the other two classes.
var o = new OtherClass();
var c1 = new MyClass1( o );
var c2 = new MyClass2 ( o );

This is perfectly normal behavior for applications. Your code will be jam-
packed with things like this: good old object composition, right? But what if
MyClass2 needs to change the instance of OtherClass or even delete it?
This too is perfectly normal behavior. Now each class will need to check if
their reference to OtherClass still exists or not, resulting in more side
effects and defensive programming. I created more instances of the program
where things can go wrong.
If your code is peppered with defensive programming, you got yourself a
problem. If your code isn't peppered with defensive programming but ought
to be, you got yourself an even bigger problem.
Errors will happen, you will get null values, but it's terribly easy to lose
track of when and where they might occur. Anything can go wrong in a
program. Some operations more than others: loading files, making requests to
a database... But also converting strings to integers and vice versa. Or looking
up things inside a collection assuming they are there. All these operations
may produce side effects. You expect or hope the result will be one thing, but
it turns out to be another. I call it life!
Procedural Programming and Object-Oriented Programming will solve
issues like these through design patterns and so-called "best-practices".
Design patterns are optimum and tested ways to solve common problems,
taking into consideration the limitations imposed by the language and the
paradigm of choice (and oddly enough most of the problems they try to solve
are created by these limitations). Nevertheless, problems like this are still
found in applications. They're the reason applications crash. And applications
do crash.
Functional programming imposes what at first seem like huge constraints
in order to do away with side effects. One of these constraints is
immutability. Nothing can change inside a functional program. Nothing starts
as null and then later becomes something. This is the hardest thing to wrap
one's head around when first learning functional programming. It feels like an
elevator button that doesn't work. Or a game that never does anything after
you clicked play. If you don't change state, things don't move, don't beep,
don't grow. You can't use i++ or set gameState = "paused" because
you can't change a value once it's set. This is immutability. So what gives?
The answer is: it's not true, or at least not entirely correct. Change does
happen in the right places and under special conditions. One thing to keep in
mind from the beginning is that change of state is a design pattern in
functional programming, one of the most important ones. Mutability does
exist in functional languages but it must be handled inside functions through
the creation of a new state, and ideally inside recursive functions.
Recursiveness is another important pattern in functional programming.
Think of a typical while loop (using pseudo-code for now):
var i = 0
while i < 1000 {
doSomething (i)
i++
}

We need to change the value of i in order for the loop to work. Something
functional programming can't do because i is immutable (or ought to be). So
instead it uses recursiveness:
doSomething (i) {
if i < 1000 {
doSomething (i+1)
}
doSomething (0)

doSomething() is recursive and pure. It doesn't really change the value

of i and it isn't coupled to it. You need to pass the function an initial value
for it.
Higher-order functions are also a big thing in functional programming, and
imagine writing that same recursive function but passing the condition i <
1000 and the action doSomething() as parameters.
doSomething (value) {
//do something
}

loop (predicate, action, value) {

if predicate(value) == true
action(value)
loop(predicate, action, value + 1)
}

loop ((v) => return v < 1000, doSomething, 0)

Another important pattern dealing with side effects in functional

programming is the almost legendary Monad. It is said that once you learn
what a Monad is, you lose the ability to explain it. Let's take a look at a
pseudo-program detailing the steps to buy a gallon of milk and use it to learn
monads and to prove to ourselves how cool functional programming can be.
Ready? Imagine a program like this:
getInTheCar();
driveToSupermarket();
findMilk();
pay();
driveHome();

But this is the real world and anything can go wrong. The car might be
broken, or it ran out of gas, the supermarket might be closed, or it ran out of
milk, or we might forget our wallet, or we ran out of money. Side effects
galore! We must check every step of the way if any errors occurred and stop
execution if we find any. At least, that's what we might do with an imperative
language. The term imperative is used as a counterpoint to functional, and it
means a language that details a series of state-mutating steps in order to reach
a goal:
getInTheCar() {
if (noGas) return;
driveToSupermarket();
}

driveToSupermarket() {
if (superMarketClosed) return;
findMilk();
}

findMilk() {
if (noMilk) return;
pay(milk);
}

pay (milk) {
if (noMoney) return;
driveHome(milk);
}

driveHome (milk) {
if (carStolen) return null;
return milk;
}

But what are we returning when problems occur and we use an empty
return;? The function that returns milk returns either milk or null; a bad
sign already but at least it's something. But all the other ones that return void,
what is going on there? Returning nothing just in order to break execution is
very common in imperative programs but in practical terms, it makes no
sense. This is another puppy we just kicked. We allowed our program to
explode into a multitude of different versions: we might get to the car, we
might get to the supermarket, we might get milk... And 99% of these versions
are pointless. They all return void.
Functional languages will treat this entire application as a type with the
following signature:
 (series of operations) -> milk
It returns milk. That's what the application does. In functional
programming what matters more than how. If problems occur, and they will,
you may have to return no milk. This means our application's signature must
reflect that, but it does it like this:
(series of operations) -> Maybe (milk)
This Maybe is an EITHER type. We've seen OR an AND types. An enum
is an OR type:
enum TimeOfDay {
Morning,
Afternoon,
Evening,
}

A TimeOfDay value can be Morning OR Afternoon OR Evening.

A person object is an AND type:
{ String firstName; String lastName; int age}

It has a firstName AND a lastName AND an age.

An EITHER type has EITHER Some value or None. A Maybe milk (also
known as an Optional milk) will be EITHER None or Some(milk). Why
is this useful? Saddle up, you're about to learn about Monads and so lose the
ability to explain it.
Monad is a common pattern in functional programming. It can be used to
describe a type of value (an EITHER type) or a function (and also lists and a
bunch of other things but we don't need to get into those). In the latter case,
the so-called monadic function has the following signature:
(argument1, argument2) -> returnType

Where:

argument1 is an Optional, let's say an Optional of type A

argument2 is a function with the following signature: (A) -> Optional
B. It takes the value A out of argument1 (if it has one) and returns an
Optional B. What this means is a value A will be transformed into
something else (we call it B) and then that transformed value will be
 returned as an optional. Why an optional? Because something might go
wrong transforming A into B. Anything can go wrong!
returnType is an Optional B, the very thing returned by the function
in argument2.

So really, the signature looks more like this:

(Optional A, (A) -> Optional B ) -> Optional B

Yes. I know. You can totally see why people have problems understanding
Monads. So let's bring Schrodinger’s Cat to the rescue, to help us understand
monadic functions and values.
Schrodinger famously had a box with an Optional cat inside it. This is
EITHER Some(cat) or None. Why? Because Schrodinger trapped the cat
inside the box with a flask of poison and rigged a trap using radioactive
emissions that may trigger the trap (or not), releasing the poison (or not). We
don't know what happened to the cat until we open the box. Say you want to
rescue the cat, tie a bow to it or give it some milk... You need first to open the
damn box. The best way to do it, the time tested way, is to use a Monad:
( Optional cat, function rescue(cat) -> Optional Cat ) -> Optional
Cat

If the cat is None, meaning the trap was activated and the cat died, we
return None without running the rescue function on cat since we have no cat
to rescue. That bastard Schrodinger killed it.
If the cat is Some(cat) we can then run rescue(cat):
rescue (cat)
give milk to cat
return Some (cat)

In this case, we return the rescued cat as Some (cat) because who
knows what's in the milk, Schrodinger might have poisoned it. I wouldn't put
it past him based on his unhealthy interest in traps.
Hence the Monad's signature (also known as a monadic function):
(Optional(a), (a) -> Optional(b) ) -> Optional (b)

We get a box that contains an optional cat. We open (or unwrap) the
optional value. If we have no cat, we return no cat wrapped inside an
Optional (the box again). If we have a cat we use it with our transformation
function. The transforming function itself my return a None or Some cat; in
other words, it returns an Optional cat (the box again). And do you remember
what do we call a function that takes another function as an argument? Yes,
monadic functions are a type of higher-order function. They're said to be
polymorphic because we can do all sorts of things to Some(cat) by changing
what the function in the second argument does.
At the beginning of the monadic function, we get a box, and in the end we
return a box. This means I can chain monadic functions:
openSchroedingerBox ( Optional cat ) |> giveMilk (Optional cat) |>
tieBow (Optional cat)

Monads are a way to deal with uncertainty that allows us to build long
chains of functions whose resulting values are wrapped inside a box, like our
cat. These values may be something or nothing, but since we're really just
passing boxes around, our application won't crash. The box may be empty,
sure, but we'll never have a Null box.
Why is this important? Look at this chain of operations, and recall how it
can all go to pieces:
getInTheCar() |> driveToSupermarket() |> findMilk() |> pay(milk) |>
driveHome(milk)

One of the many cool things about functional programming and its focus
on what is that thanks to Monads, I should think of the problem like this:
findMilk() |> getInTheCar( Optional Milk ) |> driveToSupermarket(
Optional Milk ) |> pay( Optional Milk ) |> driveHome( Optional Milk)

This way I get an Optional Milk at the end of the chain no matter what. It
will be EITHER Some(milk) or None. Who says I have to drive to the
supermarket before I can run the findMilk() function? As a matter of
fact, it doesn't really matter the order the functions occur after findMilk()
is called. It's only our silly human bias towards linear thinking that gives
prevalence to how to get milk instead of the what is involved in the process: a
series of operations that returns an Optional Milk. No biggie. I start with
some milk and then check to see if anything happens in the process that may
result in No milk. All uncertainties are dealt with the same way. I don't have
multiple versions of how the program may execute because in every possible
instance I return an Optional milk.

Note: Monadic functions are polymorphic so in reality the chain I

just used as an example would be made by the same function being
called multiple times, each one receiving a different "transforming"
function as its second argument: findMilk() getInTheCar()
driveToSupermarket()...

I admit this strange time-traveling thing doesn't happen a lot when coding
with a functional language; I still tend to "tell little stories" when I code
functionally, but every now and then, it suddenly hits you: this obsession
with chronology is dragging us down!
The other major difference we find in this paradigm is expressiveness.
Functional programming builds upon our basic AND and OR types.
Collectively, these are known as Algebraic Types and they can help express
your ideas and logic, particularly when used in combination with other
special features in functional programming such as pattern matching as we'll
see in a bit. Furthermore, almost everything in a functional language is an
expression. Even if statements can be used to return values:
let myValue = if something = true then
"1"
else
"2"

//F# uses = and not == to assert

equality

I've decided to introduce the syntax and all the main features in functional
programming by porting some of the simpler codes we've seen already in this
book. I'll use F# which is the functional cousin to C#. I should point out that
with F# you can have a mix of imperative and functional programming and
that includes the use of mutable variables if you wish. Also, F# is based on a
language called OCaml (pronounced just like an Irish camel) and that first O
stands for objects, so F# does allow one to create class-like objects
(encapsulating data with behavior). F# can also make use of everything inside
C#, and I do mean everything. I will not use these features, however, and will
focus instead on the elements specific to hard-core functional programming.
But do keep in mind that the use of class-like objects does not break any tenet
of functional programming and can be quite helpful in F# and other
functional languages that support them.

General Syntax
Back in part 4, I showed you this Python code proving regression to the
means:
wife_iq = 120
dumber_cnt = 0
tests = 1000

i = 0
while i < tests:
husband_iq = randint(60,140)
# random() * 100
# randint(0,100)
if husband_iq < wife_iq:
dumber_cnt += 1
i += 1

result = float(dumber_cnt) / float(tests)

print ( result * 100 )

Normally, in a functional program, we would not use while loops because

of their inherent need for mutability—the value of i must change in every
iteration. These sorts of loops are written as recursive functions instead, as
I've shown you. In F# the syntax for that is:
let rec nameOfFunction =
//body of the function starts here

The keyword rec declares the function to be a recursive one, meaning at

one point, based on some special condition, it will call itself. F# does not use
curly braces or semi-colons and rather like Python relies heavily on
indentations to create code blocks. And function declarations look very
similar to properties, as we'll see, because they're both types of expression.
In order to rewrite that Python code, we'll need a recursive function taking
care of the main logic in our test. Let me show you a simple, straight-forward
translation of the code first:
open System

let rand = new Random()

let wife_iq = 120
let tests = 1000

let rec testHusband dumberCnt testCnt =

let husband_iq = rand.Next(60, 140)
let newDumberCnt = if husband_iq < wife_iq then
dumberCnt + 1
else
dumberCnt

if testCnt + 1 = tests then

printfn "%A" (float newDumberCnt / float tests)
else
testHusband newDumberCnt (testCnt + 1)

testHusband 0 0

Note: I had to change code indentation quite a bit to fit some of

the scripts, and I'd recommend you see the code at this book's website
(www.rengelbert.com/codingbook/), at some point. Indentation in F#
matters a great deal as you'll see.

I'd like you to read the body of this function and try to figure out what each
line is doing. Despite the odd syntax and new operators, the function is
accomplishing the same thing as the Python one (in fact, most of the Python
logic could be written in the same functional way because Python is a multi-
paradigm language).
Head over to dotnetfiddle online console and set the language to F#
and test the code seen here. We start by importing the System library, where
Random resides. F# uses let to declare values; these are not variables since
they are immutable.
I start by declaring a random generator and two immutable properties: the
wife's IQ and the number of tests. The recursive function takes the "mutable"
properties in our logic: the dumber_cnt variable and the number of tests
performed. We will change the values for these two properties recursively.
Functions are declared in a similar way to values:
let function_name =
body of function

Like Python, F# needs white spaces to determine code blocks. If I needed

arguments passed to my function, I'd declared these as:
let function_name argument1 argument2 =
body of function

With F# it's up to you to use parentheses for arguments as well as type

notation. This is also valid code in F#:
let function_name (argument1:Type1 argument2:Type2) =
body of function

Or anything in between. Sometimes the compiler will need to know a type,

sometimes one argument will need to be isolated inside parentheses but not
the other arguments. You'll see examples of this throughout this chapter.
Take a look at the recursive function again:
let rec testHusband dumberCnt testCnt =

The function's arguments themselves are immutable. I can't do this inside

the function:
testCnt += 1

At some point I'll need to determine the new values for these properties and
call the next iteration of the function with these updated values:
let newDumberCnt = dumberCnt + 1
...
testHusband newDumberCnt (testCnt + 1)

Notice at the end how I wrap one argument within parentheses but not both
because I need to make clear the second argument is the result of testCnt
+ 1.
 Here's the body of that function:
let husband_iq = rand.Next(60, 140)

let newDumberCnt = if husband_iq < wife_iq then

dumberCnt + 1
else
dumberCnt

if testCnt + 1 = tests then

printfn "%A" (float newDumberCnt / float tests)
else
testHusband newDumberCnt (testCnt + 1)

The only new thing here is the if expression, which returns a value in F#.
And notice that equality is determined by a single = operator in F#.
if testCnt + 1 = tests

Notice too that my recursive function is referring to things outside itself:

rand, wife_iq, tests. These are immutable, therefore safe and I might
refer to them just as I might refer to other functions, but it is an example of
coupling. It would be best to pass them as arguments, or alternatively, and
even better for this particular program, to do it like this:
let testHusbandIQ () =

let rand = new Random()

let wife_iq = 120
let tests = 1000

let rec doTest dumberCnt testCnt =

let husband_iq = rand.Next(60, 140)
let newDumberCnt = if husband_iq < wife_iq then
dumberCnt + 1
else
dumberCnt

if testCnt + 1 = tests then

printfn "%A" (float newDumberCnt / float tests)
else
doTest newDumberCnt (testCnt + 1)
 //call recursive function for the first time
doTest 0 0

testHusbandIQ()

It's a very common pattern to see the recursive part of the logic written as
an internal function. Now rand, wife_iq and tests are the internal
immutable state of the function testHusbandIQ() and no longer side
effects.
Functions without parameters are usually written with the added empty
parentheses to help distinguish them from other expressions:
let testHusbandIQ () =
body of function

And may be called with empty parentheses as well to make them more
readable:
testHusbandIQ()

But this is all a convention.

As I said before spaces are used to create blocks (never tabs!)
let myFunction () =
let myVal = 10
myVal

The convention is for the indentation to match the first letter of the
preceding block's name (value or function).
And that printfn function?
printfn "%A" (float newDumberCnt / float tests)

This is the F# print function. You can provide it with placeholders for the
concatenations, and each placeholder contains the information about the type
of thing you're concatenating. These are:

%s for strings.
%i for integers.
%f for floats.
 %b for booleans.
%A for non-primitives or "anything".

Although I could have used Console.WriteLine() because, as I said

before, you can use anything from C# in F#.

Chaining
We wrote this in C# a few chapters back:
private static Random random = new System.Random();

public static void Main(string[] args) {

TestTheory();
}

static void TestTheory()

{

const int numTests = 1000;

const int numPeople = 23;

var positiveResults = 0;
var i = 0;
while (i < numTests)
{
var people = Enumerable
.Repeat(0, numPeople)
.Select(_ => random.Next(365) + 1)
.Distinct()
.Count();

if (people != numPeople)
{
positiveResults++;
}
i++;
}
Console.WriteLine(
 (float)positiveResults / (float)numTests
);

This is our Birthday Problem. We have a while loop, therefore we'll

probably turn that into a recursive function, mutating the value of
positiveResults as we iterate. Incidentally, F# does allow for mutable
values. You just need to declare them as such:
let mutable myVar = 10

I won't use that here, however, and force myself to keep using immutable
values. But if you do have to, and particularly if those mutable values are
declared inside a function's local scope, then go ahead and do it. Don't be shy.
Here's a quick conversion of the Birthday problem written in C#'s
functional cousin:
open System

let birthdayTest () =

let rand = new Random()

let numTests = 10000
let numPeople = 23

let rec doTest count positives =

let people =
Seq.init numPeople (fun _ -> rand.Next (365))
|> Seq.distinct
|> Seq.length

let newPositives = if people = numPeople then

positives
else
positives + 1

if count = numTests then

printfn "%f" (float positives / float numTests)
else
doTest (count + 1) newPositives
 doTest 0 0

birthdayTest()

Not much different from our previous example except for the simple
awesome beauty of chaining. It's very similar to what we achieved in C#
using the Linq library, which is itself heavily based on functional
programming:
//in C#
var people = Enumerable
.Repeat(0, numPeople)
.Select(_ => random.Next(365) + 1)
.Distinct()
.Count();

This becomes:
let people =
Seq.init numPeople (fun _ -> rand.Next (365))
|> Seq.distinct
|> Seq.length

Chaining is achieved via the |> operator. And it's made possible by
another feature of functional programming: Partial Application. And what is
that when it's at home? In imperative programming I might do something
like:
var bread = new Bread();
var breadAndPeanut = addPeanut( bread );
var breadPeanutJelly = addJelly ( breadAndPeanut );

Or, write it instead as this ugly monster:

var breadPeanutJelly = addJelly ( addPeanut ( new Bread() ) );

Notice how the thing must be read backward in order to get the right order
of operations: first bread, then peanut, then jelly.
In Functional programming I can do this instead:
let breadPeanutJelly = bread |> addPeanut |> addJelly
 But where did the arguments go? You can omit those arguments thanks to
partial-application. The "missing argument" is being passed via the chain.
Partial-application helps with the creation of chains because the output of
one function becomes the input of the next one, and that input can be omitted
(think of it as being inferred by the chain). As long as the "chaining
argument" is the last one in the function, you can take the argument out of the
function. For instance:
var bread = new Bread();
var breadAndPeanut = addPeanut("chunky", bread );
var breadPeanutJelly = addJelly ( breadAndPeanut );

Now I have the "chunky" peanut butter specified in the addPeanut()

function, this can be written as:
let breadPeanutJelly = bread |> addPeanut "chunky" |> addJelly

Since bread is passed as the last argument in addPeanut() partial

application will let that bread come from the left side of the chain.
So what is this doing?
let people =
Seq.init numPeople (fun _ -> rand.Next (365))
|> Seq.distinct
|> Seq.length

Seq (for Sequence) is a type of collection in F#. Here, I'm initializing a

sequence of numPeople length, where each element is created by the
function described in the parentheses:
fun _ -> rand.Next (365)

Yes, the keyword for a lambda in F# is fun! For any element _ in the
sequence, make its value the result of rand.Next(365).
Next, I pass this sequence as the argument of the first function in the chain.
Seq.distinct() will create a sequence of unique elements out of the
sequence I passed from the "left" (or the top in this case). The result is fed
into Seq.length() and that returns the integer value people will be set
to. If that number does not match the number of people we used to create the
sequence, it means we generated duplicate values, which in this test means at
least two people have the same birthday.
There is another use for partial application which involves a process known
as currying, and this can be used for a variety of different purposes. It
involves creating partially applied versions of a function.
let myFunction argument1 argument2 =
argument1 * argument2

let myPartialFunction = myFunction 42

myPartialFunction() holds a reference to a partially applied call to

myFunction(). It will hold the 42 state, like an object would, and can be
called as many times as any other function, with that partially applied state
(42):
let result = myPartialFunction 2

This can be used in order to type less or to hold on processing certain bits
of logic until it's absolutely necessary to do so or to pass around functions
that hold some previously collected state.
It's powerful stuff and it's always a fun moment when you realize you can
use it to help in your logic. There had been times when this happened that
I've caught myself yelling "I can curry!"
So, sad. So true.

Types
Remember this Python code testing coin flips?
heads = 0.0
tails = 0.0

heads_wins = 0.0
tails_wins = 0.0

for i in range (1000):

if random.randint(0,1) == 1:
heads += 1.0
else:
 tails += 1.0
if heads > tails:
heads_wins += 1.0
elif tails > heads:
tails_wins += 1.0

# print (heads)
# print (tails)
# print (heads_wins/1000)
# print (tails_wins/1000)

I could have written the F# code just as it is in Python, with the necessary
adjustments for immutability, of course. As a matter of fact, this is the sort of
code I could have done in a variety of different ways in F#. But let me use
this example to show you types. I can create types quite easily:
type CoinFlip = Heads | Tails

This is a typical OR type, just like an Enum. In F#, however, I could use it
to store more data than just a heads or tails "tag":
type CoinFlip = Heads of int | Tails of int

Now CoinFlip is a type that can store the value Heads and an
associated integer, or Tails and an integer, and I could use the integer to
store the number of rounds won by each value, for example. With OR types
in F#, I can use the of keyword to further describe what an option is,
creating complex representations by linking data types. A tiny difference, but
incredibly powerful. If you notice, this gives us one more place where we can
add context to a type. For instance:
type PersonAge = Age of int

let bobAge = Age (30)

let billAge = Age (32)
let janeAge = Age (26)

And all that with a simple declaration. This may seem like a subtle
difference but it isn't. The ability to detail your data and make it more
expressive is vital to programming, particularly in terms of readability and
clarity. Another classic example of an OR type is the following:
type Suit = Clubs | Diamonds | Hearts | Spades

type Card = Ace of Suit

| King of Suit
| Queen of Suit
| Jacks of Suit
| Value of (int * Suit)

That's what I call expressiveness! (The (something * something)

is the signature of a tuple in F#).
But back to the code...
The recursive function in this example needs to take the number of rounds,
the number of heads results, the number of tails results, the number of times
heads was the overall winner and the number of times tails was the overall
winner. This is quite a lot! I could group them inside an AND type:
type CoinFlip = Heads | Tails

type Results = {Rounds:int; Flips:CoinFlip list; Wins:CoinFlip list}

The recursive function would create a new instance of the Results type
in each iteration.
Notice how F# uses semi-colons to separate items (only items in Tuples are
separated by commas in F#). Notice too how the list type is appended to the
list declarations with the type first, followed by the keyword list:
CoinFlip list

In the end, I decided to code it like this:

I used the simple OR type...
type CoinFlip = Heads | Tails

I created a helper function to retrieve the number of times an element

appears in a list.
let countElement lst elm =
lst
|> List.filter (fun e -> e = elm)
|> List.length
 This uses chaining again. I pass the function a list and an element value and
then I filter the list on that element and return the length of the filtered list as
the result. I can use this helper function to count the number of times Heads
or Tails appear in a list containing my CoinFlip type. (And yes, F# calls
filter filter and map map. Well done F#!).
I coded the test function like this:
let testCoinFlips2 () =

let rand = new Random()

let rec testCoinFlip rounds flips wins =

let newFlips = if rand.Next(2) = 1 then

Heads::flips
else
Tails::flips

let heads = countElement newFlips Heads

let tails = countElement newFlips Tails

let newWins = if heads > tails then

Heads::wins
elif tails > heads then
Tails::wins
else
wins

if rounds + 1 = 1000 then

let heads_wins = countElement newWins Heads

let tails_wins = countElement newWins Tails

printfn "heads: %i tails: %i

headWins: %f tailWins: %f"
heads tails (float heads_wins / 1000.0)
(float tails_wins/1000.0)

else
testCoinFlip (rounds + 1) newFlips newWins
 testCoinFlip 0 [] []

Read through the recursive bit of the logic. See if you can figure out what
the :: operator does. The function needs to update the value of rounds as
well as the list flips and the list wins. When I flip a coin, I automatically
create a new list storing the updated results of the flips.
let newFlips = if rand.Next(2) = 1 then
Heads::flips
else
Tails::flips

If I get 1 as the result of the flip, I append a type Heads to the flips list.
Otherwise, I append a type Tails. This is what the :: operator is doing. It's
called the cons operator. It doesn't really append (that's a different operation
as we'll see), it adds a value to the start of an existing list and returns the new
list.
Next, I use my helper function to count the number of heads and tails so
far:
let heads = countElement newFlips Heads
let tails = countElement newFlips Tails

I use those values to create my updated wins list:

let newWins = if heads > tails then
Heads::wins
elif tails > heads then
Tails::wins
else
wins

If heads is greater than tails I add a Heads to the wins list. If

tails is greater I add Tails. If they tie, I make newWins equal the
current wins list.
Finally, we have the recursive bit of the function, checking on the number
of rounds to either print the final results or call the next test:
if rounds + 1 = 1000 then
 let heads_wins = countElement newWins Heads
let tails_wins = countElement newWins Tails

printfn "heads: %i
tails: %i
headWins: %f
tailWins: %f"
heads tails (float heads_wins / 1000.0)
float tails_wins/1000.0)

else
testCoinFlip (rounds + 1) newFlips newWins

I use the same helper function to count Heads and Tails in the
newWins list to get the number of rounds each one of those values remained
the winner.
And that's it.
Could you rewrite the function using the AND type instead?
type Results = {Rounds:int; Flips:CoinFlip list; Wins:CoinFlip list}

This is how you'd call the recursive function the first time:
testCoinFlip {Rounds = 0; Flips = []; Wins = []}

And you use dot notation to retrieve values from an AND type:
let rec testCoinFlip results =
let newFlips = if rand.Next(2) = 1 then
Heads::results.Flips
else
Tails::results.Flips
...

Give it a try.

Pattern Matching
And finally, here's a pretty good joke written in F#. The joke is by
comedian Rich Hall:
let getTomCruiseMoviePlots () =

let rec getMoviePlots characters =

match characters with
| [] -> printfn "all done!"
| head::tail ->
let character = head
printfn "He's a %s, " character
printfn "and a pretty
good %s too, " character
printfn "until he has a
crisis of confidence "
printfn "and can't be a %s
anymore. " character
printfn "Then he meets a
good looking woman"
printfn "who talks him into
being a better %s. " character
printfn "-------------------------"
getMoviePlots tail

getMoviePlots ["cocktail maker";

"race-car driver";
"jet pilot";
"sports agent";
"brother to an autistic guy"]

getTomCruiseMoviePlots()

I use a type of expression called Pattern Matching. They are the shifting
gears of Functional languages. Look for the keyword match in that joke.
This is where you track all possible outcomes of your operations, redirect
your logic, and make sure no side effects like null values are left floating
about in your code. On the surface, they are not that different from if
expressions—and many times they will be interchangeable. But patterns can
drill into the most minute distinctions helping you to build really complex
expressions. There are special operators to describe patterns in lists, tuples,
strings, numbers as well as custom types. The basic syntax looks like this:
match someValue with
| pattern 1 -> return this
| pattern 2 -> return this
| _ -> anything else, return this

Non-functional languages have a type of expression known as

switch that are the actual "closest equivalent" to match expressions
and I purposefully omitted them from this book!

But before I explain what the pattern matching expression in the joke is
doing, let me talk some more about lists.
Elements in lists are separated by semicolons in F#. Only tuple values are
separated by commas as I've said. And you retrieve an indexed element with
a dot, like this:
let character = characters.[0]

Lists and arrays are made of two parts: a head and a tail. The head is the
first element and the tail is the list containing the remaining elements. You
can pattern match a list or array to its head and tail, or to how many elements
it contains, or if it's empty...
match list with
| [] -> do this if the list is empty
| [ _ ] -> do this if the list contains one item
| [ _; _] -> do this if the list contains two items
| [ x ] -> do this if the list contains one item and address that
item as x
| [ x; y ] -> do this if the list contains two items and address them
as x and y
| head :: tail -> do something with the first element (head)
or the remaining ones (tail)

You can append a new head to an existing array with the :: operator as we
saw before:
let newArray = newHead :: oldArray

But in the match expression, the head :: tail is representing a

pattern, it's unwrapping the values for the list's head and tail and assigning
them to the properties head and tail. Those are just the names I provided
the pattern with to use when unwrapping the values. I could have used
anything:
| h :: t ->
//or
| x :: y ->

And now pay special attention to the way I "pop" elements out of the joke
array recursively:
let rec getTomCruiseMoviePlot characters =
match characters with
| [] -> printfn "all done!"
| head :: tail ->
//do something with the head
...
getTomCruiseMoviePlot tail

By recalling the recursive function with the tail as the list argument
characters, we process each individual element as the head of an
increasingly shorter list. This is another common pattern in functional
programming when dealing with collections and it replaces the common for
loop, even though they do exist in F#. Conventionally, for loops are not used
if the body of the loop is causing a state change or returning something.
This barely scratches the surface of how expressive patterns can get. I can
group, for instance, any number of types and and values and pattern match
them together. Say I have a series of values: one is an integer, another a
string, and another a color. I can write patterns like this
match myNumber, myString, myColor with
| 1, "hello", Color.black -> ...
| 2, "what", Color.blue -> ...
| 2, "?", Color.blue -> ...
| _, _, _ -> ...

Pretty neat. The idea being, all the instances of a problem should be
expressed inside a match expression.

Having said all that, let's start coding the Cluedo game in F# already.
 6
Functional Murder
With OOP, we end up worrying about the how to do something and our
classes become doers in the process. They're often named Managers or
Controllers or Loaders and anything + er. We stop describing what needs to
happen and end up focusing on how a thing is done. Functional programming
says, relax. Chill. Think about what you're trying to accomplish and above
all, what is happening to your data. A common way to work with this
paradigm is:

Get your data in order. Make sure it describes the problem and in such a
way that the solution will be clearly expressed through transformations
to the data.
Now code all the ways you'll need to transform the data. These
operations will take place inside pure functions you can easily test
independently (using fake data if needed).
The last step is to build main(). The series of operations that will
describe what you're trying to do with the data throughout the
application's lifetime.

And that's how I'll work on our Cluedo game.

What do we need for the game's data? It's time to think of what we're trying
to do. So far I've been thinking in terms of the thing I've been emulating: the
game of Cluedo. I don't mean now that I wish to get rid of everything that
makes the application what it is. What I want is to think logically about what
actually takes place with the data. I also want to identify what needs to be
mutable in the application. It'll help me plan the way transformations are
taken care of. Looking at the previous code I've identified these properties as
the mutable state:

The detective index.

 The lists of collected clues per detective.
The number of rounds (this is not relevant to the game but I still want to
track the data so I can compare to the numbers I've been seeing so far
and make sure things are working properly).

As I mentioned earlier, changes to state are a pattern in functional

programming. Ideally, you put them inside recursive functions or functions
that can return a new state based on the old one. I already know that a simple
recursive function could take care of the detective index and the number of
rounds, this would be the main game loop where we go around the list of
detectives, generating theories and checking them against clues. The lists of
collected clues are a bit more problematic. Another common pattern for a
mutable state is to wrap the thing you wish to mutate inside an AND type
(known as Records) and then create new versions of this object recursively.
F# allows us to make new instances of an object reusing as much data from
the existing version of this object as possible, pinpointing what needs to
change.
So let's create the data.
One of the things I decided to do here, for fun, was to store the murder
clues and the detective clues all in one single collection. In order to do that, I
came up with a few new types.
I start with an OR type (known as Discriminated Unions), serving as our
enum did previously:
type ClueType = Suspect | Location | Weapon | Motive

This next OR type we'll use is brand new:

type ClueOwner = Murder | Player of string

Each clue in the game will have a ClueOwner tag. This can be of type
Murder, meaning the clue is listed in the murder, or of type Player and
this will be associated with a string for the detective's name.
Now I can create the murder and "distribute" the clues simply by assigning
who owns each clue.
The actual clue type is an AND type:
type Clue = {ClueType:ClueType; Value:string; Owner:ClueOwner}
 In F# you can specify the type of a property with the syntax "name colon
type" or omit the type altogether if the compiler can figure out for itself what
the types are based on your logic. F#'s type inference capabilities seem
almost magical at times but not always. And if you find that your code is
more readable by appending type annotations, please do so.
Next, I have the detective Record type:
type Detective = { Name: string; CollectedClues: Clue list }

Each detective has a name and a list of collected clues.

And finally our Game type:
type Game = {Clues: Clue list; Detectives: Detective list;
PlayerIndex:int}

This is the data I'll pass the recursive play() function. It contains
everything needed to play one round of the game. After every round, I'll
create a new Game object, but construct it based on the current one. F# will
optimize the creation of this "new" object by reusing as much data from the
old object as it can (think of the problem StringBuilder solves in C#; it's
pretty much the same idea here). I'll show you how that's done when we get
there.
So far, I only described the data types. I still need to declare the actual
model. I'll use a dictionary for all the clues.
let clueModel =
Map.empty.

Add(Suspect, ["Colonel Mustard";

"Professor Ketchup";
"Mrs Mayonnaise";
"Miss Relish";
"Violet Beauregarde"]).

Add(Location, ["Library";
"Drawing Room";
"Sitting Room";
"Music Room";
"Game Room"]).
 Add(Weapon, ["Pipe";
"Candle Holder";
"Rope";
"Gun";
"Poison"]).

Add(Motive, ["Money";
"Love";
"Blackmailing";
"Revenge";
"Something to Do"])

The ClueType will be the key and a list of clue value strings will be the
values in the Map collection. The syntax used to create the Map is an
interesting one. This is C# code being used inside F#. First, I declare an
empty Map and then proceed to fill it up with data:
Map.empty.Add().Add().Add()

By making sure each function returns the same type, a Map, we can write
chains like the one above, using dot notation. This is known as code fluency
and you see it a lot inside the Linq library as well. empty() returns a Map
and so does Map.Add(). This is different than the chain you get from
partial application, however. This one can be found in non-functional
languages as well but serve as a good example of how important it is to
ensure functions return something whenever possible. And that way we can
compose them like this.
Moving on with our model. For the detective names, I can declare a simple
list of strings:
let detectiveModel = ["Poirot";"Sherlock Holmes";"Velma";"Shaft"]

What next? Well, what I want to accomplish is a list of clues of type Clue:
type Clue = {ClueType:ClueType; Value: string; Owner:ClueOwner}

This list will already be shuffled and each clue already assigned to an
owner. One of each of the clue types will be assigned to Murder and the
remaining to Players of string. If you recall, these values are
wrapped inside my ClueOwner type:
type ClueOwner = Murder | Player of string

I want to accomplish all this in one pass, without using mutable properties.
I confess it took me a while to get to the final version, writing many tiny
functions that got me closer and closer to what I wanted. Remember, all we
have to work with is a list of detective names:
["Poirot";"Sherlock Holmes";"Velma";"Shaft"]

And a map with clue type and clue value strings:

Suspect, ["Colonel Mustard";"Professor Ketchup";"Mrs
Mayonnaise";"Miss Relish";"Violet Beauregarde"]
...

And I want to transform this into one massive list of Clue record types
that will look something like:
[ {ClueType = Suspect; Value = "Mrs Mayonnaise"; Owner = Murder; };

{ClueType = Suspect; Value = "Colonel Mustard"; Owner = Player

"Poirot"; };

{ClueType = Suspect; Value = "Professor Ketchup"; Owner = Player

"Sherlock Holmes"; };

{ClueType = Suspect; Value = "Violet Beauregarde"; Owner = Player

"Velma"; };

{ClueType = Suspect; Value = "Miss Relish"; Owner = Player "Shaft";

};

...
]

The first clue of each clue type will be assigned to Murder and the
remaining clues in each clue type will be assigned to the detectives. The
original list of clue values should be shuffled so that the owners are assigned
to them randomly each time I play the game.
I began by sketching out the main functions to accomplish all this. I
realized that the basic operations would repeat themselves for each different
ClueType. I would distribute first the Suspects, then the Locations,
and so on. This was the best and easiest way to ensure one of each clue type
would be assigned to a Murder owner. So one function would take as
arguments: the list of the detective names, a clue type plus the list of clue
value strings belonging to that type:
let getClues detectiveNames clueType clueValues =
...

At the end of this function, I should get a list of Clue record types for one
entire clue type. I can write this function and test it independently of anything
else, just by passing it the correct arguments.
My solution was this: First, I need to generate a list of all possible
ClueOwner types, getting something like this:
[Murder; Player "Poirot"; Player "Sherlock Holmes"; Player "Velma";
Player"Shaft"]

And assign each one of the owners to the clues value strings within a clue
type:
[ "Mrs Mayonnaise"; "Colonel Mustard"; "Professor Ketchup"; "Violet
Beauregarde"; "Miss Relish" ];

Converting the whole thing into a list of Clue records:

{ClueType = Suspect; Value = "Mrs Mayonnaise"; Owner = Murder; }

{ClueType = Suspect; Value = "Colonel Mustard"; Owner = Player

"Poirot"; }
...

So to start with, I coded a helper function to produce the list of

ClueOwner:
let getOwners detectives =
Murder::(detectives
|> List.map (fun detective ->
Player detective))

It returns a list with Murder at its head and a list of Player of

string for the tail. The List.map() produces the tail list by grabbing
each detective name and running it through:
fun detective -> Player detective

Another helper function I'll need is a way to shuffle the clue value strings
before assigning them to their owners.
let shuffleClues clueValues =
clueValues
|> List.sortBy ( fun _ -> rand.NextDouble())

This uses the same shuffling algorithm I used before when coding in C#.
List.sortBy() uses a random generator I can declare like this,
somewhere in my code:
let rand = new Random()

So in my getClues() function, I start by creating this list of owners,

feeding it the name of the detectives:
let getClues detectiveNames clueType clueValues =
detectiveNames
|> getOwners
...

Then I need to pair each clue value with an owner. I could write a function
that does this, but List already has one. When I first began learning
Functional programming I noticed a phenomenon I call the Zip-A-Dee-Doo-
Dah effect. You start writing your own algorithms, trying to figure out how
to do some list transformation. After you write a dozen or so lines of code,
someone who knows more than you shows up and says: "Oh, you don't have
to do it that way. Use the List.zipADeeDooDah() method, instead. It
does exactly what you want." This will happen a lot to you if you decide to
keep using functional languages. I've already shown you List.map() and
List.sortBy() and now I'm going to use List.zip().
With List.zip() I make this happen:
list1 = [1;2;3;4;5]
list2 = ["A";"B";"C";"D";"E"]
list3 = List.zip list1 list2
//list3 = [(1, "A"); (2, "B");
//(3, "C"); (4, "D"); (5, "E")]
 The signature is:
List.zip : 'T1 list -> 'T2 list -> ('T1 * 'T2) list

Zip takes two lists of generic types (these don't have to be the same type so
the signature represents them as 'T1 and 'T2) and returns a list of tuples
grouping the items in pairs. A Tuple is another special type of collection (we
saw them in Python); you can use it to store items of different types.
When I zip a list of owners and a list of shuffled clues:
let getClues detectiveNames clueType clueValues =
detectiveNames
|> getOwners
|> List.zip (shuffleClues clueValues)
...

I combine clues with owners, getting back tuples like this:

("Colonel Mustard", Player "Poirot")

And since the first owner in the list of owners is of type Murder, this
ensures that I end up with the clues distributed into all the right places: one
goes to murder, the remaining goes to the players. This way I generate a
murder and distribute the remaining clues to the detectives all in one pass.
And the reason I shuffle the clues is so that the distribution gets randomized
each time I play the game.
I was so pleased when I got this working!
But I'm not done. I need to convert those two pieces of data:

The clueType.
And the Tuple with clue value and clue owner.

Into a Clue record type. Using List.map() on the resulting zipped list
should do the trick:
let getClues detectiveNames clueType clueValues =
detectiveNames
|> getOwners
|> List.zip (shuffleClues clueValues)
|> List.map (fun (clueValue, owner) ->
{ClueType = clueType;
 Value = clueValue;
Owner = owner})

I get the list of tuples and map each element transforming them into Clue
types. Notice that this element is already represented as a tuple in the lambda,
and I can "unwrap" the tuple values by assigning them the variables
clueValue and owner respectively.
Inside the Clue record type I used = to assign values to each property. But
anywhere else, the equal sign would stand for equality and would not work to
assign value. In F#, if you have a mutable value, you can assign it a new
value like this:
let mutable x = 10
x <- 15

Cool. I can generate a list of clues for all values belonging to a clue type.
Now I need a way to loop all clue types stored in my clue Map and run
getClues() for each one. By calling getClues() I'll get back a list
each time, but I want to have all lists of clues combined into one. I can use
another Zip-A-Dee-Doo-Dah method: List.concat().
let generateClues clueModel detectiveNames =
seq { for KeyValue(key,value) in clueModel do
yield getClues detectiveNames key value
}
|> List.concat

I used a type of collection called Sequence (seq); we saw this before. I

filled it up with values using the yield operator. With it, you can add items
to a collection following some kind of operation but still make the end result
immutable. Remember, we can't create an empty list and then wait for values
to be added later since the list is immutable. yield solves that problem for
us. I can use it to get data from a server, for instance, or just values from a
loop:
seq {
for x in 1..10 do
yield x
}
 This way you can create a collection and fill it up with elements following
some complex operation, all in one expression. Not unlike what Linq can do
in C# or what Python calls generators or comprehensives. As a matter of fact,
Python got the idea from functional programming. Here too this is called a
list comprehensive even though you can use it with other types of collections.
The code above creates a sequence with the values from 1 to 10.
Besides sequences, you can use comprehensives with lists and arrays. For
instance, the syntax for lists looks likes this:
[ for KeyValue(key,value) in clueModel do
yield getClues detectiveNames key value
]

But I find that using the seq operator makes the code more readable. I
know that I'm creating a sequence of values. I can cast the sequence into a list
later if I need it. I use a for loop to loop the Map keys and values and feed
these to the getClues() function which will yield the elements
contained in the Sequence. But getClues() returns a list, therefore the
result of...
seq { for KeyValue(key,value) in clueModel do
yield getClues detectiveNames key value
}

... will be a sequence of lists. I can pass this result to the function
List.concat() to concatenate all lists into one.
seq { for KeyValue(key,value) in clueModel do
yield getClues detectiveNames key value
}
|> List.concat

List.concat() has the following signature:

concat: seq<'T list> -> 'T list

It takes a sequence of lists holding some generic type 'T and returns a list of
a generic type 'T. This is what I'm doing here, feeding a sequence of lists to
List.concat() and getting one list back.
The entire code generating our list of clues, already distributed to Murder
and detectives, looks like this:
let generateClues clues detectiveNames =
seq { for KeyValue(key,value) in clues do
yield getClues detectiveNames key value
}
|> List.concat

let getClues detectiveNames clueType clueValues =

detectiveNames
|> getOwners
|> List.zip (shuffleClues clueValues)
|> List.map (fun (clueValue, owner) ->
{ClueType = clueType;
Value = clueValue;
Owner = owner})

let getOwners detectives =

Murder::(detectives
|> List.map (fun detective -> Player detective))

let shuffleClues clueValues =

clueValues
|> List.sortBy ( fun _ -> rand.NextDouble())

I can generate all clues for the game like this:

let clues = generateClues clueModel detectiveModel

What next?
I generate the list of Detective objects through a simple List.map()
operation:
let detectives =
detectiveModel
|> List.map (fun n -> { Name=n;
CollectedClues=[] })

The detectives will start with an empty list of collected clues.

And I can finally create the Game object, ready for the first round of the
game:
let game = {Clues = clues; Detectives = detectives; PlayerIndex =
0}

We have our model in place so we can move to the second step in

development, which is detailing all data transformations. In our game, we
need to make theories and check them against clues. Let me tackle the
makeTheory() function first.
I know I'll need a way to collect one clue, randomly, from a pool of clues
belonging to a specific clue type. This should be easy with a filter and a
shuffle:
let getClueForType clues (clueType:ClueType) =
clues
|> List.filter (fun clue -> clue.ClueType = clueType)
|> List.sortBy ( fun _ -> rand.Next())
|> List.head

Take the list of clues, filter out all the clues that do not belong to the given
clue type, shuffle the result, and return the first element in the list (the head).
We can use this function to grab the clues we'll use to form a theory.
The makeTheory() function needs access to the data belonging to each
detective, so we may refer to their list of collected clues. And of course, it
needs the complete list of clues I just generated:
let makeTheory detective clues =
...

First, let's filter all the clues by owner, removing all the clues owned by the
detective. These can be ignored since we know they're not owned by
Murder.
let makeTheory detective clues =
let notOwned =
clues
|> List.filter (fun clue ->
clue.Owner <> Player detective.Name)

<> means not equal in F#.

Next, let's filter out clues that have been collected already. I can do this in
many different ways. This time, instead of using filter, I decided to use an
idea common in Python: subtracting sets.
let notCollected = (Set.ofList notOwned) - (Set.ofList
detective.CollectedClues)
|> Set.toList

If I convert both lists into Sets, I can subtract their content, essentially
removing duplicated values. I take the list of notOwned clues, turn it into a
Set, and do the same to detective.CollectedClues. Then I subtract
the two sets and convert the result back into a List. I can do this because the
two lists are comprised of unique values and I don't care about the order the
elements appear in (a Set, if you recall, can only hold unique values and we
have no control over the order these are stored in).
I'm ready to return an array with the clues picked for the theory. I could do
something like the following at the end of makeTheory() using my
getClueForType() function for each clue type and return an array with
the result:
let suspect =
getClueForType notCollected Suspect

let location =
getClueForType notCollected Location

let weapon =
getClueForType notCollected Weapon

let motive =
getClueForType notCollected Motive

[suspect;location;weapon;motive]

But why not use yield again and make this a bit more readable:
[
yield getClueForType notCollected Suspect
yield getClueForType notCollected Location
yield getClueForType notCollected Weapon
yield getClueForType notCollected Motive
]
 The entire logic to make a theory looks like this:
let makeTheory detective clues =
let notOwned =
clues
|> List.filter (fun clue -> clue.Owner <> Player
detective.Name)

let notCollected = (Set.ofList notOwned) -

(Set.ofList detective.CollectedClues)
|> Set.toList

[
yield getClueForType notCollected Suspect
yield getClueForType notCollected Location
yield getClueForType notCollected Weapon
yield getClueForType notCollected Motive
]

let getClueForType clues (clueType:ClueType) =

clues
|> List.filter (fun clue -> clue.ClueType = clueType)
|> List.sortBy ( fun _ -> rand.Next())
|> List.head

I can now move on to the logic that checks whether or not a theory is
correct. In previous versions of this code, I checked if any detective had a
clue that matched one of the clues in the theory. If so, this clue was returned
so it could be added to the collected clues of the detective posing the theory.
If you remember, I used a loop for this. So how about using a recursive
function now?
I declare the recursive logic inside another function I called
checkTheory(). The function takes:

All the clues,

The theory posed by the round's detective,
A list of all the detectives, so I can loop them,
And the current detective index.
 I use a recursive function so I can change the detective index since I'll need
to check a theory against the clues distributed to the other players, looping
through all detectives if necessary.
let checkTheory clues theory (detectives:Detective list) playerIndex
=

let rec checkPlayerClues index =

...

let index = (playerIndex + 1) % detectives.Length

checkPlayerClues index

I wrote the same expression I've used before to increase the detective index
and wrap this index in a loop. I pass this value to the rec
checkPlayerClues() function.
What do we need to do in the recursive function? First, I grab the next
detective I'll check the theory against:
let rec checkPlayerClues index =
let nextDetective = detectives.[index]

Next, I filter the clues in the theory, keeping only clues owned by the
indexed detective.
let cluesFound =
theory
|> List.filter(fun clue ->
clue.Owner = Player nextDetective.Name)

This will return an empty list if I find no match, meaning this detective has
no clues which can be used to shoot down the theory, or it will return
something. Sounds like the perfect place for pattern matching:
let rec checkPlayerClues index =
let nextDetective = detectives.[index]
let cluesFound =
theory
|> List.filter(fun clue ->
clue.Owner = Player nextDetective.Name)
match cluesFound with
| [] -> let nextIndex = (index + 1) % detectives.Length
 if nextIndex = playerIndex then None
else checkPlayerClues nextIndex
| _ -> Some(cluesFound.Head)

The match expression states:

If the list is empty, it means this detective has no clues matching the
theory. In this case, I increase the detective index and check on that
value:
match cluesFound with
| [] -> let nextIndex =
(index + 1) % detectives.Length
if nextIndex = playerIndex then None
else checkPlayerClues nextIndex
...

If the value matches the current player's index I return None. This means
we did a complete circle, looping through all detectives and found no
matching clue. Otherwise, I call the recursive checkPlayerClues()
again with the updated detective index so I can check the theory against the
next one.

But if the list is not empty, this means we have found a matching clue:
match cluesFound with
| [] -> let nextIndex = (index + 1) % detectives.Length
if nextIndex = playerIndex then None
else checkPlayerClues nextIndex
| _ -> Some(cluesFound.Head)

I return Some and the head of the matching clues list. Or you could pick
one clue randomly, if you like.
A pattern-matching expression must return results of the same type. With
None and Some, we're returning an Optional type. This is where functional
programming really shines, in the way it deals with possible null values.
checkTheory() returns an Optional(Clue), which serves as a one-
type-wrapper for both Some(Clue) or None.
The entire checkTheory() function looks like this:
let checkTheory clues theory (detectives:Detective list) playerIndex
=
let rec checkPlayerClues index =
let nextDetective = detectives.[index]
let cluesFound =
theory
|> List.filter(fun clue ->
clue.Owner = Player nextDetective.Name)
match cluesFound with
| [] -> let nextIndex = (index + 1) % detectives.Length
if nextIndex = playerIndex then None
else checkPlayerClues nextIndex

| _ -> Some(cluesFound.Head)

let index = (playerIndex + 1) % detectives.Length

checkPlayerClues index

I have the logic that generates theories and the logic that checks the theory
against the clues owned by the other players. I'm ready to code the main
recursive logic that will play out the game. This play function needs to do
quite a few things:

It will generate a theory using the round's detective.

It will check the theory against all other detectives, and get an
Optional(clue) back.
It will check whether it got Some(clue) or None and prepare the data
for the next round, if necessary.

I pass this function the Game object and the current round number
(remember, I only use this round value for the final print out).
I start like this:
let rec play game round =
let detective = game.Detectives.[game.PlayerIndex]
let theory = makeTheory detective game.Clues
let result = checkTheory game.Clues theory game.Detectives
game.PlayerIndex
 Pick the round's detective, use it to make a theory, check that theory against
the other detectives. result will either hold Some (clue) or none. We
need a match expression here. It will control whether or not we call play
again, like this:
match result with
| Some(clue) -> PLAY NEW ROUND
| _ -> END RECURSION, WE SOLVED THE MURDER!

In order to play a new round, I need to update the game object. I'll pass it
the new clue returned in Some(clue) and add this to the current detective's
collected clues list. Let me write that in a separate function and show you
how F# can generate new objects out of existing ones. Here's the whole
function, see if you can figure out where the data is being updated:
let updateGame game newClue =
let detective = game.Detectives.[game.PlayerIndex]
let newDetectiveClues =
detective.CollectedClues @ [newClue]
let newDetective = {
detective with CollectedClues = newDetectiveClues
}

let newDetectiveList = game.Detectives

|> List.map (fun d ->
if d.Name = detective.Name then
newDetective
else d)

let newIndex = (game.PlayerIndex + 1) %

game.Detectives.Length
let newGame = { game with Detectives = newDetectiveList;
PlayerIndex = newIndex
}
newGame

The newClue is added to the current detective. I create a new

CollectedClues list with the @operator that appends values to a list and
returns a new list:
let newDetectiveClues = detective.CollectedClues @ [newClue]
 I then create a new Detective object using the with operator. This
ensures that only the new data is updated, in this case, the new list of
collected clues, and the old data is shifted to the new object:
let newDetective = {
detective with CollectedClues = newDetectiveClues
}

This is saying: give me a new detective which is the old detective but with
this new value for CollectedClues.
Now I need to make sure I update the detective list with the new detective
object. I use List.map() to generate a new list using the previous
elements. If the element is our detective, then I replace it with the
newDetective, otherwise, keep the existing element:
let newDetectiveList = game.Detectives
|> List.map (fun d ->
if d.Name = detective.Name then
newDetective else d)

There are a number of ways I could have done this. For instance, I could
combine the past three operations:
let newDetectiveClues =
detective.CollectedClues @ [newClue]

let newDetective = {
detective with CollectedClues = newDetectiveClues
}
let newDetectiveList = game.Detectives
|> List.map (fun d ->
if d.Name = detective.Name
then
newDetective else d)

Into one:
let newDetectiveList =
game.Detectives
|> List.map (fun d ->
if d.Name = detective.Name then
{detective with CollectedClues =
 detective.CollectedClues @ [newClue]}
else d)

We have the new detective and the new detective list. The next thing I need
to update inside the Game object is the detective index, using our trusty
wrapping expression again:
let newIndex = (game.PlayerIndex + 1) %
game.Detectives.Length

Now I can create a new Game object updating the old one with the new
values and I return that from the function:
let newGame = { game with
Detectives = newDetectiveList;
PlayerIndex = newIndex
}

newGame

Notice how you can update more than one bit of data inside an object using
with.
Here's the final version of the updateGame() function:
let updateGame game newClue =
let detective = game.Detectives.[game.PlayerIndex]
let newDetectiveList =
game.Detectives
|> List.map (fun d -> if d.Name = detective.Name then
{
detective with CollectedClues
=
detective.CollectedClues @
[newClue]
}
else d)

let newIndex = (game.PlayerIndex + 1) %

game.Detectives.Length
let newGame =
{
game with Detectives =
 newDetectiveList; PlayerIndex = newIndex
}
newGame

Back to our play() function and the match expression:

match result with
| Some(clue) -> PLAY NEW ROUND
| _ -> END RECURSION

I can now handle the PLAY NEW ROUND bit of the logic using the
updateGame() function and the unwrapped clue:
| Some(clue) -> let newGame = updateGame game clue
play newGame (round + 1)

In the other case, if we get None from checkTheory(), I can print the
game result as I've done before. But just to be sure, let me write a function to
check whether or not a theory has the correct solution:
let checkIfMurder theory =
let murderOwned =
theory
|> List.filter ( fun clue ->
clue.Owner = Murder )
murderOwned.Length = theory.Length

The clues inside theory are filtered, returning a list of clues whose owner
is Murder. If the resulting list has the same length as the theory list, we have
a solution, because this means all clues in the theory are owned by
Murder. Simple as that. Although there are a billion ways I could have run
the same check.
Now the complete play() function looks like this, with the added print
out:
let rec play game round =
let detective = game.Detectives.[game.PlayerIndex]
let theory = makeTheory detective game.Clues
let result = checkTheory game.Clues theory game.Detectives
game.PlayerIndex
match result with
 | Some(clue) -> let newGame = updateGame game clue
play newGame (round + 1)
| _ -> let isCrime = checkIfMurder theory
printfn "%b" isCrime
printfn "%s solved the mystery in %i rounds: It was %s
with the %s in the %s for %s "
detective.Name round theory.[0].Value theory.[2].Value
theory.[1].Value theory.[3].Value

And that's it. At the bottom of the script, I finish our program by calling
play() just after I build up the model:
let clues = generateClues clueModel detectiveModel
let detectives = detectiveModel |> List.map (fun n ->
{Name=n;CollectedClues=[]})
let game = {Clues = clues; Detectives = detectives; PlayerIndex = 0}
play game 1

If you're willing to give functional programming a try, you may try to

convert other code listed in this book as an exercise. Start small, with our
backdoor code, the Caesar cipher, and the Plato's Stick code, for instance.
Then move to the magic tricks and the speed reader trainer. You should be
able to solve most if not all issues using the code listed in this chapter as a
reference. And remember, you're free to use C# code inside F#.
Here's the complete code for Cluedo as a functional program (you can also
see it in this book's web page, free of any size constraints):
open System

type ClueType = Suspect | Location | Weapon | Motive

type ClueOwner = Murder | Player of string
type Clue = {ClueType:ClueType; Value: string; Owner:ClueOwner}
type Detective = { Name: string; CollectedClues: Clue list }
type Game = {Clues: Clue list;
Detectives: Detective list;
PlayerIndex:int}

let clueModel =
Map.empty.
Add(Suspect, ["Colonel Mustard";"Professor Ketchup";
"Mrs Mayonnaise";"Miss Relish";"Violet
Beauregarde"]).
Add(Location, ["Library";"Drawing Room";"Sitting Room";
"Music Room";"Game Room"]).
Add(Weapon, ["Pipe";"Candle Holder";"Rope";
"Gun";"Poison"]).
Add(Motive, ["Money";"Love";"Blackmailing";
"Revenge";"Something to Do"])

let detectiveModel = ["Poirot";"Sherlock Holmes";"Velma";"Shaft"]

let rand = new Random()

let getClueForType clues (clueType:ClueType) =

clues
|> List.filter (fun clue -> clue.ClueType = clueType)
|> List.sortBy ( fun _ -> rand.Next())
|> List.head

let makeTheory detective clues =

let notOwned =
clues
|> List.filter (fun clue -> clue.Owner <> Player
detective.Name)

let notCollected =
(Set.ofList notOwned) - (Set.ofList detective.CollectedClues)
|> Set.toList

[
yield getClueForType notCollected Suspect
yield getClueForType notCollected Location
yield getClueForType notCollected Weapon
yield getClueForType notCollected Motive
]

let checkTheory clues theory (detectives:Detective list) playerIndex

=
let rec checkPlayerClues index =
let nextDetective = detectives.[index]
let cluesFound =
theory
|> List.filter(fun clue ->
 clue.Owner = Player
nextDetective.Name)

match cluesFound with

| [] -> let nextIndex = (index + 1) % detectives.Length
if nextIndex = playerIndex then None
else checkPlayerClues nextIndex

| _ -> Some(cluesFound.Head)

let index = (playerIndex + 1) % detectives.Length

checkPlayerClues index

let getDetectives names =

names
|> List.map (fun n -> {Name=n;CollectedClues=[]})

let getOwners detectives =

Murder::(detectives
|> List.map (fun detective -> Player detective))

let shuffleClues clueValues =

clueValues
|> List.sortBy ( fun _ -> rand.NextDouble())

let getClues detectiveNames clueType clueValues =

detectiveNames
|> getOwners
|> List.zip (shuffleClues clueValues)
|> List.map (fun (clueValue, owner) ->
{ClueType = clueType;
Value = clueValue;
Owner = owner})

let generateClues clues detectiveNames =

seq { for KeyValue(key,value) in clues do
yield getClues detectiveNames key value
}
|> List.concat
let updateGame game newClue =
let detective = game.Detectives.[game.PlayerIndex]
let newDetectiveList =
game.Detectives
|> List.map (fun d -> if d.Name = detective.Name then
{detective with CollectedClues =
detective.CollectedClues @
[newClue]}
else d)

let newIndex = (game.PlayerIndex + 1) %

game.Detectives.Length
let newGame = { game with Detectives = newDetectiveList;
PlayerIndex = newIndex
}
newGame

let checkIfMurder theory =

let crimeOwned =
theory
|> List.filter ( fun clue -> clue.Owner = Murder )
crimeOwned.Length = theory.Length

let rec play game round =

let detective = game.Detectives.[game.PlayerIndex]
let theory = makeTheory detective game.Clues
let result = checkTheory game.Clues theory game.Detectives
game.PlayerIndex
match result with
| Some(clue) -> let newGame = updateGame game clue
play newGame (round + 1)
| _ -> let isCrime = checkIfMurder theory
printfn "%b" isCrime
printfn "%s solved the mystery in %i rounds:
It was %s with the %s in the %s for %s "
detective.Name round
theory.[0].Value
theory.[2].Value
theory.[1].Value
theory.[3].Value

let clues = generateClues clueModel detectiveModel

let detectives =
detectiveModel
|> List.map (fun n -> {Name=n;CollectedClues=[]})

let game = {Clues = clues; Detectives = detectives; PlayerIndex = 0}

play game 1
 7
Other Considerations
Despite the differences between the paradigms, their boundaries are a bit
blurred as I've said before. It's hard to think of a specific problem that would
be better served by a specific style. This gets complicated further by the
languages themselves. Some procedural languages will allow you to create
object-like structures, have namespaces, modules and enums. Some won't.
Some OOP languages won't take the type system very far, won't support
inheritance or interfaces, and the result will be something else entirely. And
some functional languages will allow the use of classes. The differences in
the way I coded Cluedo when using F# —the use of a ClueOwner tag, for
example—could have been used in the other languages. And I'm not
defending it as the better solution either.
The lesson is: All paradigms may be improved by mixing up. And I'd
suggest that no paradigm can be more helpful in improving things than
Functional Programming. That's the paradigm to bring in to the mix
whenever you can. Use it everywhere, particularly in non-functional
languages. They very likely won't support pattern matching, partial
application, chaining... but the main ideas are always applicable.
The other good lesson you can take from these paradigms is that it's best to
think of your data first. Feynman was right when he said computers are "data
handlers." And programming is data handling above all things. OOP offers
more ways to forget this lesson, I find, even if it does offer more ways to
describe data than we can procedurally. It over-complicates things with its
ability to model reality. Reality is overrated. OOP works with "doers". With
them, you tend to forget data handling, forget to describe what happens with
the data in favor of how something is accomplished and who's doing it. But it
doesn't need to be this way.
The game Cluedo is already an attempt to model a real thing and the code I
worked on kept making the same mistake. If I thought about the data
independently of finding parallels with the "real world" I might have come up
with better ideas and insights, but I limited them, thinking in terms of these
parallels. I made my Detective a doer instead of a blob of data; a mere
tag. I ended up playing the game of Cluedo through code, instead of simply
distributing the data until one set of clues—the same contained in the
Murder collection—was recreated inside a detective's collection of clues.
Both OOP and Function programming offer excellent ways to describe
data. Now I could go back to the OOP code and describe the clues like this,
matching what I did in F#:
public class Clue {
public string value;
public ClueType type;
public ClueOwner owner;
}

Or I can make it like this:

public class Clue {
public string value;
public ClueType type;
public ClueOwner owner;
public HashSet<Detective> collectedBy;
}

And now the Clue objects will hold the list of detectives that have
collected them. I'm not saying this creates a better solution but you can see
how the way we describe the data changes the code entirely. It changes how
the problem gets solved. And that whole OOP's "modeling the real world"
nonsense should not be taken too far. We shouldn't think that only a
Detective can sort out the clues because that's what detectives do in the
real world. This gets in the way of describing data effectively. And this
happens a lot in OOP, in my opinion.
Procedural is not as good as describing data as its counterparts, or at least
not as feature-rich. But then again its apparent limitations may put a stop to
any nonsense and increase one's resourcefulness. In modular programming—
a common feature in procedural programs—coupling is all but eliminated.
And the model and the functions that act on it are set wide apart and this
forces the programmer to adhere to really good practices.
 In any event, once you describe your data, the solutions have a tendency to
come to the surface in all three paradigms.
Job-wise, if you want a job as a programmer, you will probably need to be
well acquainted with OOP. It's pretty damn near a universality. It's far more
standardized than the other paradigms and so allows for the easy replacement
of programmers. That's life. But also if you want to work developing games
or apps, you will probably need to use OOP. It's been the industry standard
for too long. Some exceptions do exist using procedural languages, but not
many.
Functional programming has been relegated to small things. It's really good
for programs you intend to run on multiple processors (the immutability thing
helps tremendously with this). Because of this, it became a bit more niche
and developed a reputation for being difficult to work with; a reputation it
does not deserve. But modern OOP languages (and procedural ones) have
caught up and now concepts that were once specific to functional languages
have become more wide-spread.
With procedural programming, you may be expected to work with one or
more of the following: C, Python, GO, JavaScript, Lua... You'll use these to
develop tools that run in the console, to build servers, web-applications, or
scripts used by some game engine.
With OOP you may be expected to work with one or more of the
following: C++, Java, C#, Kotlin, Swift... (and Python, and some hacky
versions of JavaScript and Lua). You'll use these to build servers, web-
applications, apps, games, as well as tools that run in the console.
With Functional programming you may be expected to work with one or
more of the following: F#, Scala, Elm, OCaml, Erlang, Haskell, Clojure... (or
Python and JavaScript to some extent). You'll use these to build concurrent
applications in servers, console tools, and web-applications (including
games).
But here again the boundaries are hard to define, as you can see with the
overlap of possible applications for each language. For instance, If you want
to build console games then C or C++ (and maybe C#) are your best choices.
If you want to build Android apps then Java or Kotlin. iOS apps? Swift. But
you can use C or C++ to build Android apps and iOS apps. It's almost
impossible to state with absolute certainty a language X won't ever be used to
build Y. Things change all the time. And remember, all the languages I've
shown in this book are multipurpose.
The one certainty is that you can use all of these languages to have all the
fun in the world working on your own projects.
Python will likely give you the most return for your investment. The
popular wisdom that there is a mobile app for anything a person may wish to
do also applies to Python. There is a freely available Python library for every
single purpose you can dream of. You can use them to optimize your
workflow if nothing else, and whatever that might be. If you're a writer, you
should know Python. Ditto if you're a musician, illustrator, student, business
person, world adventurer or old lady with a hundred cats... You can use it to
convert files, edit images and sounds, turn your voice recordings into text,
translate your text, organize your life, wake you up in the morning, say good
night and agree with you on all things. You can use it to make platform
games! But sure, you can stick to your phone and miss the fun.
JavaScript is a good option if you found you did not enjoy coding that
much or decided programming is too hard but still want to build stuff other
people can see and use. With JavaScript you can build apps, and games, and
web-pages... You can get a job. But it's not as fun. You'll find yourself coding
things the way some one else decided you should code things way more often
with JavaScript than any other language I know. All because of the twists and
turns people had to conform to in order to make it possible to use JavaScript
to build apps, games and web-pages. When you hammer a square peg into a
round hole, that's a lot like JavaScript. But everybody's got a hammer, so why
not?
Okay, I made it sound a bit on the awful side. That's not true. JavaScript is
alright. It really is. (But you can also draw in Python!)
I use C# and a Python-like script language to build games with (sometimes
also Lua. I like Lua). I use Python for tools (sometimes Go if the job is really
big). I use an OOP language called Dart with an SDK (software development
kit) called Flutter to build mobile apps with. I use Swift to code MacOS
desktop apps if for some reason I can't use Flutter. I use Haxe for a strange
form of nostalgia (that's a long story). I use F# the way people use Sudoku.
You don't have to learn more than one language or more than one
paradigm. This is not a competition.
 But there is no need to stop learning, and this fact ought to be one of the
best things about being alive. But again, this is coming from a guy who likes
to code Orc name generators and then use those names to generate lyrics for
Shirley Ellis The Name Game song using another Python script:

Gruluk, Gruluk, bo-bruluk

Bonana-fanna fo-fruluk
Fee fi mo-mruluk
Gruluk!

Good times.
Which leads us to...
Final Thoughts
... How to Keep Learning?
One of my favorite stories related to learning is the one about the B7 chord
told by Paul McCartney. I first saw it in the book The Element by Ken
Robinson. A young Paul McCartney and John Lennon took a bus across
Liverpool to go ask another kid how to play the B7, one of the three basic
chords everyone needed to know in order to play rock songs: E, A, and B7.
They didn't know the last one, but this other kid did. "That was our only
education experience—showing each other how to do things (..). To start
with, we were just copying and imitating everyone. I was Little Richard and
Elvis. John was Jerry Lee Lewis and Chuck Berry. I was Phil from the Everly
Brothers and John was Don. We just imitated other people and taught each
other. This was a big point for us."
Nowadays Google replaced the bus ride. I'm old enough to miss the bus
rides, but there it goes. This is still the best way to learn a new skill you
happen to be passionate about. Imitate. Figure things out and then teach
other. Take the bus to talk to that kid. Where do you take that bus? Where
does that kid live? Here's what you need to know.
You will probably need a decent code editor. Head over to
https://code.visualstudio.com/download and download Visual Studio Code
for free. Then head over to YouTube and search for step-by-step videos on
how to set up specific languages with Visual Studio Code (Python,
JavaScript, Go, Lua, C#, F#, Scala..).. These instructions will vary depending
on your operating system but are meant to be quite stress-free.
If you choose to work with Python you will also need to learn how to
install libraries using the pip command tool. About 30% of the internet is
made of Python tutorials by now, including how to use pip. And most of
these operations will work from within Visual Studio Code. Again, YouTube
is your best friend for this.
For practice, consider porting the C# code you saw in this book to Python
and the Python code to C#. Or use JavaScript, or F#. Fix all the couplings in
my code. Be nasty about it. There are resources online for more exercises, but
do focus on the ones for beginners at first (Google: "problems to solve with
code"). Some of these resources, like Project Euler, are aimed at more
seasoned programmers. Still, they can be quite a lot of fun, the sort of
problems that stay with you for a while until you finally figure out a neat
solution for them. Just don't be discouraged if the problem seems too
complicated. Go easy on yourself when learning.
Any book with the name Robert Sedgewick on its cover will have a truck-
load of neat little problems you can use for practice. And you'll often find the
solutions for these online, done in a variety of languages from passionate
programmers like you (they're the kid you learn the B7 chord from).
Then comes the real fun. Pick a new language, like Go for instance
(remember Ken Thompson, the guy who created Regular Expressions? He's
one of the people behind Go). And then port everything we've done with
Python into Go. Search for Go cheat sheets or simply Google the following:

How to write a dictionary/list/array in Go?

How to loop a collection in Go?
How to cast a string to an integer in Go?
How to write a function in Go?
How to get a random number in Go?
How to get user input using Go?
How to append/remove/insert to a collection in Go?
How to find an element's index in a collection in Go?
How to sort a collection in Go?

Most of these searches will take you to a website called StackOverflow.

This is your bus ride.
Look for online compilers, like https://repl.it/, and use these at first if you
like.
Code your heart out. Print to the console constantly. Avoid snobs. The
programming world is filled with them. They either try hard to forget their
own mistakes or rush through them so they can impress idiots and make fun
of others. Snobs don't learn and they can't teach.
After that, you can replace Go with anything you like. My personal
recommendations are Lua, Dart, Scala, and Haxe. But throw in C++ too and
good old C. Go nuts. But do find your favorite (or favorites), and give it
special attention.
Subscribe to good YouTube channels. Avoid videos from conference talks
and presentations (anything done on a stage), or videos on programming
interview questions, or any of those videos where people are trying their
hardest to monetize their own broken dreams (lots of snobs here).
freeCodeCamp.org is an excellent channel. Tensor Programming is great too.
And javidx9 (OneLoneCoder) is an absolute must (he mainly uses C++ but
then again, you'll learn C++, which is another +). These channels should lead
you to more good ones if the YouTube sorting algorithm holds.
Cough, cough... buy my books. I build upon the knowledge seen here and
help people hack their own lives building proper apps for a change: their
own. If this interests you, keep an eye out for more stuff. You can check my
blog at www.rengelbert.com for more code samples and projects.
Let me come full circle and tell you, here in the last chapter, that professor
Feynman devised his own learning method and if you don't know about it,
find out. Do yourself this favor.
Above all, know this: there's more fun to be had. Lots more.
Build tools. Turn your computer into a Midi studio. Create your own text-
based RPG saga. Build your own to-do list apps. Build your own mp3 player
and radio station. Navigate the internet in your own browser for a while.
Build a robot Mondrian painter. Code an idea generator for Sci-fi short
stories. Create headlines mixing words from today's real headlines and see
which ones are crazier. Code an NLP script that will identify every murderer
in every mystery novel. Create your own programming language and call it
something obnoxious like Balls (sadly, there is one called Coq already, buy
hey, make it so they can work together).
Plan out your days with if statements if you must, but kick-start Main()
as soon as you can.
Use recursiveness on all your problems and iterate through them, always
focusing on the head, never the tail, until your lists are empty.
Have fun.
Always return something.
 exit 0;

}
Also by Roger Engelbert:

Learning Source Control with Git and SourceTree

Word Games With Unity