September 11, 2026 • 22 mins
A hands-on introduction to coding for beginners using the JS Bin online sandbox. The text utilizes a continuous project called The Crypt, a text-based adventure game, to demonstrate how specific programming concepts build a complex application. Part 1 focuses on core building blocks, beginning with variables to store and manipulate individual pieces of data like player names or scores. It then introduces objects, which allow developers to organize related data into cohesive groups using key-value pairs. By following the development of the game's players and locations, readers learn to transition from loose variables to structured, encapsulated data. This practical approach emphasizes learning by doing and provides a roadmap for mastering JavaScript from the console to the browser.
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cyber_security_summary
Get the Book now from Amazon:
https://www.amazon.com/dp/1617293105?lv=shuf&channelId=500&plpRedirect=mhFallback&linkCode=ll2&tag=cvthunderx-20&linkId=c643c5d42f29477fc559956697123470&language=en_US&gaOptInStatus=true&ref_=as_li_ss_tl
Discover our free courses in tech and cybersecurity, Start learning today:
https://linktr.ee/cybercode_academy
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cyber_security_summary
Get the Book now from Amazon:
https://www.amazon.com/dp/1617293105?lv=shuf&channelId=500&plpRedirect=mhFallback&linkCode=ll2&tag=cvthunderx-20&linkId=c643c5d42f29477fc559956697123470&language=en_US&gaOptInStatus=true&ref_=as_li_ss_tl
Discover our free courses in tech and cybersecurity, Start learning today:
https://linktr.ee/cybercode_academy
Listen
Watch
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
Every time you click a button on your favorite website
or swipe across the screen, you're instantly triggering this cascade
of microscopic, invisible robots.
Speaker 2 (00:08):
Oh yeah, like thousands of.
Speaker 1 (00:09):
Them, exactly thousands, and they are executing these highly specific,
really ruthlessly logical instructions in like a frashment of millisecond.
And we've all gotten so used to this seamless digital
universe that we kind of just treat it like magic.
Speaker 2 (00:25):
Right. It creates this illusion of a glowing, impenetrable box.
You ask for something, the box glows and the result
just magically appears. You know, we rarely think about the
actual architecture holding the whole thing together.
Speaker 1 (00:39):
But today we are pausing time to look at exactly
what those microscopic robots are made of. Welcome to the
deep Dies. We're taking a stack of notes drawn entirely
from this really fascinating book, Get Programming with JavaScript by
John R. Larson.
Speaker 2 (00:53):
It's a great foundational text.
Speaker 1 (00:54):
It really is, And our mission today is to give
you a shortcut to being well in full armed about
how software is actually built. We're going to strip away
the intimidating jargon to reveal the the elegant logical building
blocks underneath it all.
Speaker 2 (01:10):
Yeah, getting past all that gatekeeping terminology.
Speaker 1 (01:13):
Exactly, We're going to trace the journey from writing a
single line of raw text all the way to architecting
the foundation of an entire interactive world, specifically a text
based adventure game that Larsen builds in the book called
The Crypt. Oh.
Speaker 2 (01:29):
The crypt is such a perfect sandbox.
Speaker 1 (01:31):
For this, it is. Okay, let's untack this. Where do
we even begin When the goal is to stop treating
the machine like magic and you know, actually start speaking
its language.
Speaker 2 (01:40):
Well, we really have to begin with the philosophy of
learning it. Larson introduces this core philosophy early in the text,
which is that learning follows thinking.
Speaker 1 (01:48):
Learning follows thinking.
Speaker 2 (01:49):
Yeah, meaning you cannot learn the architecture of software by
like passively reading a book or listening to some abstract lecture.
Understanding code requires you to actually manipulate the logic yourself,
your hands dirty. Exactly. You have to force your own
brain to translate a human intention into a strict machine instruction.
Speaker 1 (02:06):
Which means stepping out of the theoretical and getting into
an environment where you can actually, you know, brak things.
I kind of think of it like learning how to
cook by actually burning a few meals in the kitchen
rather than just staring at a recipe book.
Speaker 2 (02:19):
That is a perfect analogy, and it's precisely why Larsen
centers the initial experience around this tool called js bin jaspin. Yeah,
Remy Sharp, who's the creator of jspin, he actually wrote
the ForWord for the book, and he designed this tool
as a totally online sandbox. It is a completely isolated,
(02:40):
no mistakes barred development.
Speaker 1 (02:41):
Environment, and it requires zero setup, right, literally zero.
Speaker 2 (02:45):
You just open your browser, you dismiss this little robot mascot.
Speaker 1 (02:48):
Oh right, Dave the binbo.
Speaker 2 (02:49):
Yeah, Dave Binbot. You dismiss him, and then you're just
staring directly at the console panel.
Speaker 1 (02:53):
It's like jumping straight into a flight simulator. You type
that legendary first command that every programmer learns, right, console
dot log Hello World.
Speaker 2 (03:01):
And you hit run yes, And there is this immediate
raw power in that execution loop.
Speaker 1 (03:08):
It's magical. You just type text and the computer instantly responds. Right.
Speaker 2 (03:13):
Because you issue an instruction and the machine obeys it instantly,
that execution loop fundamentally shifts how you interact with the computer.
You stop being just a consumer of the magic box
and you become a commander.
Speaker 1 (03:24):
I love that consumer to commander.
Speaker 2 (03:26):
But you know, because it is a strict environment, it
also introduces you to the concept of merciless feedback.
Speaker 1 (03:32):
Oh boy, the red text.
Speaker 2 (03:34):
A red text js BINN does not infer your intentions.
If you forget a semi coolin or if you know,
misspell a command by one letter, it immediately throws this
bright red error message at you.
Speaker 1 (03:45):
And reading through the notes, I noticed how much emphasis
ll are some places on those errors. He really frames
them not as failures, which is how we usually take them,
but as the computer just rigidly asking for clarification.
Speaker 2 (03:57):
Yeah, and honestly, that stripped feedback is the only way
to build resilience in programming. I mean, a machine cannot
bridge the gap of human ambiguity, right doesn't know what
you meant to say exactly. You delete a character, the
system breaks, you put it back, the system runs perfectly.
It forces you to adopt this standard of absolute precision.
And that's the foundational mindset you have to have before
(04:18):
you can even start designing complex systems like a game.
Speaker 1 (04:21):
So, okay, you're in this simulator, You're learning precision, you're
commanding the console. But a world without state is entirely static.
If we're going to build an interactive game like the
crypt we need to track what's actually happening. We need
a way to manage data.
Speaker 2 (04:36):
We need to allocate memory, and that is where the
concept of variables comes into play. Variables, Yeah, variable isn't
just a label. It's an actual dedicated space in the
computer's memory that you reserve to hold specific data and
you can retrieve it or mutate it later.
Speaker 1 (04:52):
Let's look at the hypothetical app Larson mentions to illustrate
this because it's hilarious. It's called the fruitinator. Oh yeah,
the fruitinator.
Speaker 2 (04:58):
So imagine a player running around splitting fruit with a
smoothie nine millimeter as.
Speaker 1 (05:03):
One does naturally, and if they shoot a strawberry they
get fifty points. But if they managed to hit a
tricky cum quat, well that's worth a hundred points. To
make that game work, the program needs a reserved space
in memory to track the score, right.
Speaker 2 (05:17):
It needs a variable exactly, and the syntax for that
is pretty straightforward. You use the var keyword, you name it,
and you use the assignment operator, which is just the
equal sign to give it a value.
Speaker 1 (05:27):
And as the state of the game changes, like as
the player hits that cumquat, the program has to reach
back into that specific memory address and update the value.
Speaker 2 (05:36):
It does, which brings up the huge challenge of organization
because in a massive code base, you might have thousands
of these memory spaces, right, So Larsen really emphasizes using
highly descriptive, human readable naming conventions for variables, like using
camel case formatting, where the.
Speaker 1 (05:56):
First word is lowercase and the next word is capitalized.
Speaker 2 (05:59):
Yeah, exactly. So instead of naming a variable CPCH or
just X, you name it cost per hour with a
capital P and H.
Speaker 1 (06:06):
Because if you don't, you're going to confuse yourself.
Speaker 2 (06:07):
Later, oh one hundred percent. That is a critical architectural habit.
You aren't just writing code that a machine can execute.
I mean, machine doesn't care if you call your variable
x or super califragilistic.
Speaker 1 (06:18):
It's all the same to the machine.
Speaker 2 (06:20):
Exactly. You are writing code that future developers can understand
and maintain, and often you know that future developer is
just you, like six months from now, desperately trying to
figure out what a variable named Q was supposed to track.
Speaker 1 (06:33):
I've been there. It's not fun so clear. Naming acts
as embedded documentation precisely, but even with descriptive names, having
thousands of loose variables floating around the game engine just
sounds like a nightmare. Yeah. Like, if we're building the
crypt we have player names, health stats, inventory items, locations.
Speaker 2 (06:52):
Yeah, it's a lot of data.
Speaker 1 (06:53):
If all of those are independent variables, the global scope
of the program just becomes this massive clut warehouse.
Speaker 2 (07:00):
It leads to what developers call global variable pollution pollution.
Speaker 1 (07:05):
Wow.
Speaker 2 (07:06):
Yeah, because when everything is loose, the risk of data
colliding or being accidentally overwritten it just skyrockets. So to
manage that risk, you have to encapsulate the data.
Speaker 1 (07:16):
And Larsen uses this fantastic analogy for this in the
book The First Aid Kit.
Speaker 2 (07:20):
It's such a good visual, right, because if.
Speaker 1 (07:22):
You're going on a hike, you don't carry a bandage
in your left pocket and scissors in your right pocket,
and I don't know a bottle of antiseptic in your shoe.
Speaker 2 (07:29):
That would be absurd.
Speaker 1 (07:30):
You pack them all into one single container. You pass
the whole kit around, and when you need something, you
open the kit and pull out just the scissors, and.
Speaker 2 (07:37):
In JavaScript that container is called an object.
Speaker 1 (07:40):
An object.
Speaker 2 (07:41):
Okay, yeah, so instead of managing disconnected variables, for say
player one name and player one health, you define a
single player object. You use curly braces to group all
that related state into one name space using key value pairs.
Speaker 1 (07:56):
So applying that to the crypt let's say the player's
name is Chondra and her health is fifty. Later on,
when Candor takes damage from a trap, you don't have
to go hunting for some loose health variable. You just
use dot notation like player dot health to drill directly
into that specific container and update the value exactly.
Speaker 2 (08:15):
It creates this beautifully clean, hierarchical structure your chunking information conceptually,
which allows you to model real world entities inside the machine.
Speaker 1 (08:26):
Okay, so objects keep our data perfectly organized in these
little first aid kits. But data just sitting in a
kit is completely static. I mean, a game where a
player's stats just sit in memory isn't much of a game?
Definitely not. How do we actually make the program act
on this organized data over and over again?
Speaker 2 (08:44):
To create action? You need to automate behavior, and for
that you need functions.
Speaker 1 (08:49):
Functions.
Speaker 2 (08:50):
Yes, they are the mechanisms that take your static data
and actually do something.
Speaker 1 (08:54):
Meaningful with it. Okay, I want to push back on
this for a second, on behalf of a pragmatic beginner.
Speaker 2 (08:58):
Sure, go for it.
Speaker 1 (08:59):
Because Larsen used an example of displaying the stats of
three different movies. I think it was inside out Specter.
Speaker 2 (09:05):
In Star Wars, right, I remember that.
Speaker 1 (09:07):
And to print the title, directors and actors to the
console it takes about five lines of code per movie. Honestly,
isn't it just faster for me as a beginner to
write those five lines, highlight them, and copy paste them
two more times? It is tempting, right, Why introduce an
entirely new architectural layer when copy paste solves my problem
(09:28):
in ten seconds?
Speaker 2 (09:29):
Well, copy pasting solves the immediate problem, sure, but it
creates a long term architectural nightmare. How so it introduces
massive redundancy. Let's trace the life cycle of that copied code.
You've got your fifteen lines print in the three movies.
But tomorrow you decide the output is hard to read.
You want to insert a blank dashed line between each
movie to separate them visually.
Speaker 1 (09:50):
Oh, I see the trap.
Speaker 2 (09:51):
Yeah, because you copied and pasted, you now have to
manually hunt down every single instance of that movie block
across your entire code base and update it one by one.
Speaker 1 (10:00):
Which just fine for three movies.
Speaker 2 (10:01):
But exactly what if you scale up to one hundred movies?
You are suddenly spending hours doing manual data entry. Just
add a dashed line.
Speaker 1 (10:09):
So function solve this update nightmare.
Speaker 2 (10:11):
They do by implementing a principle called code on demand.
Speaker 1 (10:15):
Code on demand, Yeah, a.
Speaker 2 (10:16):
Function allows you to define a block of logic exactly.
Once you wrap those five lines of display code inside
a function named, for example, show movie info, then instead
of rewriting the logic, you just call that function whenever
you need it.
Speaker 1 (10:31):
So it's like a central command. Right.
Speaker 2 (10:33):
If you decide to add that dash line, you go
to the central function definition, you modify it in that
one single place, and every instance across your entire program
inherits the update instantly.
Speaker 1 (10:45):
That shifts your role entirely. You stop being this like
typist manually managing lines of texts, and you become an architect,
building reusable tools.
Speaker 2 (10:54):
It is the ESTs of managing complexity. You abstract the
repetitive tasks away. So you can actually focus on higher
level logic.
Speaker 1 (11:01):
But looking at it, there is a potential flaw in
how we've set this up so far. If our show
movie info function relies on a variable that was defined
somewhere else in that global warehouse we talked about, isn't
that dangerous? Very dangerous? Like if the function is hardwired
to look for a specific variable, what happens if that
variable gets renamed or deleted by accident?
Speaker 2 (11:21):
The function immediately breaks. That is called tight coupling. When
a function depends on the external environment to have specific
data sitting in specific places, it becomes incredibly brittle.
Speaker 1 (11:32):
Reading Larsen's notes, I cracked up at how he described
these brittle functions. He calls them rock God musician.
Speaker 2 (11:38):
It's so brilliant.
Speaker 1 (11:40):
Why does he use that specific comparison for a line
of code.
Speaker 2 (11:42):
Though, because it perfectly captures the arrogance of a poorly
written function. Think about it. A rock God musician demands
that a very specific bowl of like green M and
ms must be waiting in their dressing room before they
will even consider walking on stage.
Speaker 1 (11:59):
Right, the eminem's aren't there.
Speaker 2 (12:00):
They throw a tantrum and the show is canceled. A
tightly coupled function does the exact same thing. If the
exact global variable it expects isn't present, the whole program crashes.
Speaker 1 (12:10):
So we do not want arrogant rock god functions. We
want easygoing, portable session musicians who will perform anywhere as
long as you just hand them their.
Speaker 2 (12:17):
Instruments exactly, And to achieve that, we use parameters and
arguments to decouple the function from the global scope.
Speaker 1 (12:26):
Okay, let's clarify that terminology because I hear parameter and
argument used interchangeably all the time, but they represent different
parts of this decoupling process, right they do.
Speaker 2 (12:37):
So think of parameters as the empty placeholders the function
creates for itself in the dressing room. Okay, When you
architect the function, you define parameters inside the prophesies say
play your name and play your health. The function is
formally declaring I don't care about the outside world, but
to do my job, I expect to be handed two
pieces of information when I'm called.
Speaker 1 (12:57):
So the parameters are the empty boxes waiting to be filled,
which means the arguments are the actual data.
Speaker 2 (13:02):
Yes, exactly. The arguments are the specific values you pass
into those boxes at the exact moment you execute the function.
Speaker 1 (13:08):
So if I call showplayer health Candra.
Speaker 2 (13:11):
Fifty, the string candra and the number fifty are the arguments.
The function safely ingests them, runs its internal logic, and
finishes its job without ever needing to look out at
the global scope.
Speaker 1 (13:21):
It makes the function entirely self contained, like you could
rip that function out of the crypt drop it into
a completely different game engine, and as long as you
pass it the right arguments, it's going to execute flawlessly.
Speaker 2 (13:33):
And this modularity becomes exponentially more powerful when you introduce
the return keyword.
Speaker 1 (13:38):
Your return keyword yeah.
Speaker 2 (13:39):
Because up until now, our functions have basically been dead ends.
Speaker 1 (13:44):
Right. They do a job and stop.
Speaker 2 (13:46):
They perform an action like printing text to a screen,
but they don't give the larger program anything back to
work with. The data goes in, gets processed, and basically vanishes.
Speaker 1 (13:55):
So how does return change that?
Speaker 2 (13:57):
It allows a function to evaluate data and then hand
the calculated result back to the main program. Larsen uses
a great example of a plumber calculating a bill.
Speaker 1 (14:06):
Oh where are this?
Speaker 2 (14:07):
You write a total cost function. It takes three parameters,
a slack call out fee, an hourly rate and the
hours worked.
Speaker 1 (14:14):
So if a plumber charges a thirty dollars fee a
forty dollars hourly rate and works for three hours, you
pass those arguments in, so it's like total costs thirty forty.
Speaker 2 (14:24):
Three exactly, and the function acts as this isolated processing plant.
It calculates thirty plus one twenty internally, arriving at one fifty.
Then it uses the return keyword to output that value
return one fifty.
Speaker 1 (14:37):
Got it.
Speaker 2 (14:38):
The crucial architectural concept here is that the function call
itself is literally dynamically replaced by the output in your code.
Wait really yeah, The code total cost thirty forty three
effectively becomes the number one fifty in your larger script.
Speaker 1 (14:52):
Oh wow, which means you can now compose functions together.
You can take that return one fifty and immediately pass
it as an argument into a caxulate tax function, or
subtract it from a budget variable.
Speaker 2 (15:04):
Precisely, the output of one isolated machine becomes the raw
material for the next. It allows you to build these massive,
intricate pipelines of logic where data flows cleanly from one
self contained puzzle piece to another.
Speaker 1 (15:16):
Without ever polluting the global memories exactly. Okay, here's where
it gets really interesting. Oh yeah, we know how to
pass individual arguments to isolate our functions. But as a
game like the crypt scales, passing individual data points just
gets messy. I mean, if I want a function to
process a player's turn, I have to pass their name,
health location, current weapon, their inventory array status effects.
Speaker 2 (15:40):
It's too much. Passing ten different arguments in a very
specific sequence is incredibly fragile.
Speaker 1 (15:45):
Because if I swap the order of two arguments by mistake.
Speaker 2 (15:48):
The game suddenly thinks the player's weapon is their health
score and it crashes.
Speaker 1 (15:53):
Right, So what's the solution.
Speaker 2 (15:54):
This is where we combine our two major concepts. We
emerge the first aid kits with the code on demand.
Speaker 1 (15:59):
Oh objects meaning functions.
Speaker 2 (16:01):
Yes, instead of passing a fragile list of primitive arguments,
you just pass the entire object into the function.
Speaker 1 (16:06):
You just hand the processing plant the entire first aid kit.
Speaker 2 (16:09):
It creates incredibly clean architecture. Larsen illustrates this by passing
a planet object into a calculate size is function. The
function only requires a single parameter, now the object itself.
Speaker 1 (16:21):
Okay, so it takes the whole planet object.
Speaker 2 (16:23):
Right, and once the object is inside the function can
unpack it, read the planet's radius, perform complex geometry, and
then instantly attach brand new properties like area and volume
directly onto the object before returning it.
Speaker 1 (16:36):
So the object goes into the function, gets upgraded, and
comes out with new capabilities exactly. But the relationship between
objects and functions goes even deeper than that, right, because
functions don't just process objects, they can actually live inside them.
Speaker 2 (16:49):
Yes, when a function is a sign as a property
of an object, it becomes what we call a method
a method, and this is the foundation of object oriented design.
It allows you to create names.
Speaker 1 (17:00):
Larsen spacer object is the perfect showcase for why name
spaces matter.
Speaker 2 (17:05):
It really is. In any complex program, you end up
with dozens of small utility functions, for instance, functions to
format text right, adding blank lines, wrapping texts in dashed boxes,
and denting paragraphs. Right. If you leave all those formatting
functions loose in the global scope, they clutter your environment.
Speaker 1 (17:22):
Yeah, you wouldn't want a generic function just named box
floating around, so someone else might write a physics function
named box and suddenly the two are.
Speaker 2 (17:30):
Colliding exactly, So instead you create a single dedicated object
called spacer, and you attach all your formatting functions to
it as methods.
Speaker 1 (17:39):
Oh I see. So now when you want to format
a textbox in your game, you call spacer dot box. Right,
the functionality is buddle directly with the name space. You
know exactly where your tools live, and they are protected
from colliding with the rest of the codebase.
Speaker 2 (17:53):
And you know, while we are exploring methods attached to objects,
there is a behind the scenes technical secret. Larsen reveals
about strings that completely blew my mind when I first
understood the mechanics of it.
Speaker 1 (18:06):
Yes, you were practically vibrating when you read that section, Yeah,
because it completely subverts what we've just learned about objects
and primitive data.
Speaker 2 (18:13):
It really does. So we've established that objects are these
complex structures you architect with properties and methods, right, and
primitive data like a simple string of text, just a
word like Jupiter wrapped in quotes, is just basic data. Technically,
it is not an object, right.
Speaker 1 (18:30):
It doesn't have namespace, it doesn't have methods attached to it.
It's just a raw value.
Speaker 2 (18:34):
But in JavaScript you can take that raw string Jupiter
and call a method directly on it.
Speaker 1 (18:40):
Wait, how you can.
Speaker 2 (18:41):
Type jupiter dot two uppercase and the system instantly returns
the word Jupiter in all capital letters.
Speaker 1 (18:48):
But hold on, If methods only exist inside objects, how
can a raw piece of text execute a method.
Speaker 2 (18:56):
That is the invisible genius of the language's engine. JavaScript
knows that strings are primitive, but it also knows developers
need to format them constantly. So the exact millisecond you
attempt to call a method like to uppercase on a
simple string, the engine secretly.
Speaker 1 (19:10):
Intervenes, secretly intervenes.
Speaker 2 (19:12):
Yeah, it takes your primitive text and instantly wraps it
inside a temporary, invisible string object that contains all those
complex formatting methods.
Speaker 1 (19:20):
So it upgrades the text into an object behind your back.
Speaker 2 (19:22):
Yes, it creates the object, borrows the formatting method to
capitalize your word, hands you the result, and then instantly
destroys that temporary object to free up memory before you
even realize it happened.
Speaker 1 (19:34):
That is astonishing. It's like having an invisible phantom workforce.
You ask a simple piece of text to do something
incredibly complex, and the agent just spins up an entire
architectural structure in the background does the heavy lifting. And
obliterates the evidence before the next line of code even runs.
Speaker 2 (19:50):
It is a masterclass in garbage collection and memory management.
The engine gives you the immense power and convenience of
complex object methods without forcing you to permanently sacrifice the
memory required to store every single word as a massive object.
Speaker 1 (20:05):
It really makes you realize how much aggressive optimization is
happening under the surface of every single.
Speaker 2 (20:10):
Web page, which brings us back to that illusion of
the glowing box. You know, the magic isn't magic, it's
just greath takingly efficient logic.
Speaker 1 (20:18):
So what does this all mean for you? Whether you
are gearing up to write your first text adventure or
you're just trying to understand the digital ecosystem you interact
with every single day.
Speaker 2 (20:28):
Well beyond the syntax understanding how variables, objects, functions, and
methods interact, it's really about learning a new paradigm for
problem solving.
Speaker 1 (20:37):
Oh absolutely.
Speaker 2 (20:38):
Programming forces you to look at a chaotic reality and
synthesize it into modular systems.
Speaker 1 (20:43):
You're learning how to chunk related information to reduce mental load,
which is exactly what objects do. And you're identifying repetitive
patterns and automating them to prevent errors, which what functions do?
Speaker 2 (20:55):
You start to view large problems not as insurmountable monoliths,
but as a series of small, decoupled systems that just
need to pass the correct arguments to one another. You
basically optimize your own workflow the same way you optimize code.
Speaker 1 (21:09):
Which leaves me with a final, slightly provocative thought to ponder.
Inspired by this entire journey, We've just spent this time
dismantling the digital world, realizing that everything on our screens
is ultimately just a massive, intricate collection of encapsulated objects
passing properties into isolated functions.
Speaker 2 (21:27):
Yeah, it is a giant, cascading web of structured inputs
and predictable outputs.
Speaker 1 (21:33):
So how much of our own human behavior could be
mapped using the exact same architecture?
Speaker 2 (21:39):
Oh wow?
Speaker 1 (21:40):
Think about your daily routines, your ingrained habits, your emotional
responses to stress. Are we in some way just executing
highly optimized functions responding to external arguments like when someone
cuts you off in traffic? Is that just an argument
being passed into your stress response function, returning a very
predictable output based on the state of your internal variables
that day?
Speaker 2 (21:59):
It's a really helling framework for introspection. Are we consciously
architecting our responses or are we just running legacy code
that we never bothered to.
Speaker 1 (22:07):
Decouple something to mull over. The next time you find
yourself stuck in a repetitive loop, maybe it's time to
check your dependencies and write a new function. Thank you
so much for joining us on this deep dive. Keep exploring,
keep questioning, and remember even the most complex digital castles
in the world are built from the exact same microscopic,
logical grains of sand.
Every time you click a button on your favorite website
or swipe across the screen, you're instantly triggering this cascade
of microscopic, invisible robots.
Speaker 2 (00:08):
Oh yeah, like thousands of.
Speaker 1 (00:09):
Them, exactly thousands, and they are executing these highly specific,
really ruthlessly logical instructions in like a frashment of millisecond.
And we've all gotten so used to this seamless digital
universe that we kind of just treat it like magic.
Speaker 2 (00:25):
Right. It creates this illusion of a glowing, impenetrable box.
You ask for something, the box glows and the result
just magically appears. You know, we rarely think about the
actual architecture holding the whole thing together.
Speaker 1 (00:39):
But today we are pausing time to look at exactly
what those microscopic robots are made of. Welcome to the
deep Dies. We're taking a stack of notes drawn entirely
from this really fascinating book, Get Programming with JavaScript by
John R. Larson.
Speaker 2 (00:53):
It's a great foundational text.
Speaker 1 (00:54):
It really is, And our mission today is to give
you a shortcut to being well in full armed about
how software is actually built. We're going to strip away
the intimidating jargon to reveal the the elegant logical building
blocks underneath it all.
Speaker 2 (01:10):
Yeah, getting past all that gatekeeping terminology.
Speaker 1 (01:13):
Exactly, We're going to trace the journey from writing a
single line of raw text all the way to architecting
the foundation of an entire interactive world, specifically a text
based adventure game that Larsen builds in the book called
The Crypt. Oh.
Speaker 2 (01:29):
The crypt is such a perfect sandbox.
Speaker 1 (01:31):
For this, it is. Okay, let's untack this. Where do
we even begin When the goal is to stop treating
the machine like magic and you know, actually start speaking
its language.
Speaker 2 (01:40):
Well, we really have to begin with the philosophy of
learning it. Larson introduces this core philosophy early in the text,
which is that learning follows thinking.
Speaker 1 (01:48):
Learning follows thinking.
Speaker 2 (01:49):
Yeah, meaning you cannot learn the architecture of software by
like passively reading a book or listening to some abstract lecture.
Understanding code requires you to actually manipulate the logic yourself,
your hands dirty. Exactly. You have to force your own
brain to translate a human intention into a strict machine instruction.
Speaker 1 (02:06):
Which means stepping out of the theoretical and getting into
an environment where you can actually, you know, brak things.
I kind of think of it like learning how to
cook by actually burning a few meals in the kitchen
rather than just staring at a recipe book.
Speaker 2 (02:19):
That is a perfect analogy, and it's precisely why Larsen
centers the initial experience around this tool called js bin jaspin. Yeah,
Remy Sharp, who's the creator of jspin, he actually wrote
the ForWord for the book, and he designed this tool
as a totally online sandbox. It is a completely isolated,
(02:40):
no mistakes barred development.
Speaker 1 (02:41):
Environment, and it requires zero setup, right, literally zero.
Speaker 2 (02:45):
You just open your browser, you dismiss this little robot mascot.
Speaker 1 (02:48):
Oh right, Dave the binbo.
Speaker 2 (02:49):
Yeah, Dave Binbot. You dismiss him, and then you're just
staring directly at the console panel.
Speaker 1 (02:53):
It's like jumping straight into a flight simulator. You type
that legendary first command that every programmer learns, right, console
dot log Hello World.
Speaker 2 (03:01):
And you hit run yes, And there is this immediate
raw power in that execution loop.
Speaker 1 (03:08):
It's magical. You just type text and the computer instantly responds. Right.
Speaker 2 (03:13):
Because you issue an instruction and the machine obeys it instantly,
that execution loop fundamentally shifts how you interact with the computer.
You stop being just a consumer of the magic box
and you become a commander.
Speaker 1 (03:24):
I love that consumer to commander.
Speaker 2 (03:26):
But you know, because it is a strict environment, it
also introduces you to the concept of merciless feedback.
Speaker 1 (03:32):
Oh boy, the red text.
Speaker 2 (03:34):
A red text js BINN does not infer your intentions.
If you forget a semi coolin or if you know,
misspell a command by one letter, it immediately throws this
bright red error message at you.
Speaker 1 (03:45):
And reading through the notes, I noticed how much emphasis
ll are some places on those errors. He really frames
them not as failures, which is how we usually take them,
but as the computer just rigidly asking for clarification.
Speaker 2 (03:57):
Yeah, and honestly, that stripped feedback is the only way
to build resilience in programming. I mean, a machine cannot
bridge the gap of human ambiguity, right doesn't know what
you meant to say exactly. You delete a character, the
system breaks, you put it back, the system runs perfectly.
It forces you to adopt this standard of absolute precision.
And that's the foundational mindset you have to have before
(04:18):
you can even start designing complex systems like a game.
Speaker 1 (04:21):
So, okay, you're in this simulator, You're learning precision, you're
commanding the console. But a world without state is entirely static.
If we're going to build an interactive game like the
crypt we need to track what's actually happening. We need
a way to manage data.
Speaker 2 (04:36):
We need to allocate memory, and that is where the
concept of variables comes into play. Variables, Yeah, variable isn't
just a label. It's an actual dedicated space in the
computer's memory that you reserve to hold specific data and
you can retrieve it or mutate it later.
Speaker 1 (04:52):
Let's look at the hypothetical app Larson mentions to illustrate
this because it's hilarious. It's called the fruitinator. Oh yeah,
the fruitinator.
Speaker 2 (04:58):
So imagine a player running around splitting fruit with a
smoothie nine millimeter as.
Speaker 1 (05:03):
One does naturally, and if they shoot a strawberry they
get fifty points. But if they managed to hit a
tricky cum quat, well that's worth a hundred points. To
make that game work, the program needs a reserved space
in memory to track the score, right.
Speaker 2 (05:17):
It needs a variable exactly, and the syntax for that
is pretty straightforward. You use the var keyword, you name it,
and you use the assignment operator, which is just the
equal sign to give it a value.
Speaker 1 (05:27):
And as the state of the game changes, like as
the player hits that cumquat, the program has to reach
back into that specific memory address and update the value.
Speaker 2 (05:36):
It does, which brings up the huge challenge of organization
because in a massive code base, you might have thousands
of these memory spaces, right, So Larsen really emphasizes using
highly descriptive, human readable naming conventions for variables, like using
camel case formatting, where the.
Speaker 1 (05:56):
First word is lowercase and the next word is capitalized.
Speaker 2 (05:59):
Yeah, exactly. So instead of naming a variable CPCH or
just X, you name it cost per hour with a
capital P and H.
Speaker 1 (06:06):
Because if you don't, you're going to confuse yourself.
Speaker 2 (06:07):
Later, oh one hundred percent. That is a critical architectural habit.
You aren't just writing code that a machine can execute.
I mean, machine doesn't care if you call your variable
x or super califragilistic.
Speaker 1 (06:18):
It's all the same to the machine.
Speaker 2 (06:20):
Exactly. You are writing code that future developers can understand
and maintain, and often you know that future developer is
just you, like six months from now, desperately trying to
figure out what a variable named Q was supposed to track.
Speaker 1 (06:33):
I've been there. It's not fun so clear. Naming acts
as embedded documentation precisely, but even with descriptive names, having
thousands of loose variables floating around the game engine just
sounds like a nightmare. Yeah. Like, if we're building the
crypt we have player names, health stats, inventory items, locations.
Speaker 2 (06:52):
Yeah, it's a lot of data.
Speaker 1 (06:53):
If all of those are independent variables, the global scope
of the program just becomes this massive clut warehouse.
Speaker 2 (07:00):
It leads to what developers call global variable pollution pollution.
Speaker 1 (07:05):
Wow.
Speaker 2 (07:06):
Yeah, because when everything is loose, the risk of data
colliding or being accidentally overwritten it just skyrockets. So to
manage that risk, you have to encapsulate the data.
Speaker 1 (07:16):
And Larsen uses this fantastic analogy for this in the
book The First Aid Kit.
Speaker 2 (07:20):
It's such a good visual, right, because if.
Speaker 1 (07:22):
You're going on a hike, you don't carry a bandage
in your left pocket and scissors in your right pocket,
and I don't know a bottle of antiseptic in your shoe.
Speaker 2 (07:29):
That would be absurd.
Speaker 1 (07:30):
You pack them all into one single container. You pass
the whole kit around, and when you need something, you
open the kit and pull out just the scissors, and.
Speaker 2 (07:37):
In JavaScript that container is called an object.
Speaker 1 (07:40):
An object.
Speaker 2 (07:41):
Okay, yeah, so instead of managing disconnected variables, for say
player one name and player one health, you define a
single player object. You use curly braces to group all
that related state into one name space using key value pairs.
Speaker 1 (07:56):
So applying that to the crypt let's say the player's
name is Chondra and her health is fifty. Later on,
when Candor takes damage from a trap, you don't have
to go hunting for some loose health variable. You just
use dot notation like player dot health to drill directly
into that specific container and update the value exactly.
Speaker 2 (08:15):
It creates this beautifully clean, hierarchical structure your chunking information conceptually,
which allows you to model real world entities inside the machine.
Speaker 1 (08:26):
Okay, so objects keep our data perfectly organized in these
little first aid kits. But data just sitting in a
kit is completely static. I mean, a game where a
player's stats just sit in memory isn't much of a game?
Definitely not. How do we actually make the program act
on this organized data over and over again?
Speaker 2 (08:44):
To create action? You need to automate behavior, and for
that you need functions.
Speaker 1 (08:49):
Functions.
Speaker 2 (08:50):
Yes, they are the mechanisms that take your static data
and actually do something.
Speaker 1 (08:54):
Meaningful with it. Okay, I want to push back on
this for a second, on behalf of a pragmatic beginner.
Speaker 2 (08:58):
Sure, go for it.
Speaker 1 (08:59):
Because Larsen used an example of displaying the stats of
three different movies. I think it was inside out Specter.
Speaker 2 (09:05):
In Star Wars, right, I remember that.
Speaker 1 (09:07):
And to print the title, directors and actors to the
console it takes about five lines of code per movie. Honestly,
isn't it just faster for me as a beginner to
write those five lines, highlight them, and copy paste them
two more times? It is tempting, right, Why introduce an
entirely new architectural layer when copy paste solves my problem
(09:28):
in ten seconds?
Speaker 2 (09:29):
Well, copy pasting solves the immediate problem, sure, but it
creates a long term architectural nightmare. How so it introduces
massive redundancy. Let's trace the life cycle of that copied code.
You've got your fifteen lines print in the three movies.
But tomorrow you decide the output is hard to read.
You want to insert a blank dashed line between each
movie to separate them visually.
Speaker 1 (09:50):
Oh, I see the trap.
Speaker 2 (09:51):
Yeah, because you copied and pasted, you now have to
manually hunt down every single instance of that movie block
across your entire code base and update it one by one.
Speaker 1 (10:00):
Which just fine for three movies.
Speaker 2 (10:01):
But exactly what if you scale up to one hundred movies?
You are suddenly spending hours doing manual data entry. Just
add a dashed line.
Speaker 1 (10:09):
So function solve this update nightmare.
Speaker 2 (10:11):
They do by implementing a principle called code on demand.
Speaker 1 (10:15):
Code on demand, Yeah, a.
Speaker 2 (10:16):
Function allows you to define a block of logic exactly.
Once you wrap those five lines of display code inside
a function named, for example, show movie info, then instead
of rewriting the logic, you just call that function whenever
you need it.
Speaker 1 (10:31):
So it's like a central command. Right.
Speaker 2 (10:33):
If you decide to add that dash line, you go
to the central function definition, you modify it in that
one single place, and every instance across your entire program
inherits the update instantly.
Speaker 1 (10:45):
That shifts your role entirely. You stop being this like
typist manually managing lines of texts, and you become an architect,
building reusable tools.
Speaker 2 (10:54):
It is the ESTs of managing complexity. You abstract the
repetitive tasks away. So you can actually focus on higher
level logic.
Speaker 1 (11:01):
But looking at it, there is a potential flaw in
how we've set this up so far. If our show
movie info function relies on a variable that was defined
somewhere else in that global warehouse we talked about, isn't
that dangerous? Very dangerous? Like if the function is hardwired
to look for a specific variable, what happens if that
variable gets renamed or deleted by accident?
Speaker 2 (11:21):
The function immediately breaks. That is called tight coupling. When
a function depends on the external environment to have specific
data sitting in specific places, it becomes incredibly brittle.
Speaker 1 (11:32):
Reading Larsen's notes, I cracked up at how he described
these brittle functions. He calls them rock God musician.
Speaker 2 (11:38):
It's so brilliant.
Speaker 1 (11:40):
Why does he use that specific comparison for a line
of code.
Speaker 2 (11:42):
Though, because it perfectly captures the arrogance of a poorly
written function. Think about it. A rock God musician demands
that a very specific bowl of like green M and
ms must be waiting in their dressing room before they
will even consider walking on stage.
Speaker 1 (11:59):
Right, the eminem's aren't there.
Speaker 2 (12:00):
They throw a tantrum and the show is canceled. A
tightly coupled function does the exact same thing. If the
exact global variable it expects isn't present, the whole program crashes.
Speaker 1 (12:10):
So we do not want arrogant rock god functions. We
want easygoing, portable session musicians who will perform anywhere as
long as you just hand them their.
Speaker 2 (12:17):
Instruments exactly, And to achieve that, we use parameters and
arguments to decouple the function from the global scope.
Speaker 1 (12:26):
Okay, let's clarify that terminology because I hear parameter and
argument used interchangeably all the time, but they represent different
parts of this decoupling process, right they do.
Speaker 2 (12:37):
So think of parameters as the empty placeholders the function
creates for itself in the dressing room. Okay, When you
architect the function, you define parameters inside the prophesies say
play your name and play your health. The function is
formally declaring I don't care about the outside world, but
to do my job, I expect to be handed two
pieces of information when I'm called.
Speaker 1 (12:57):
So the parameters are the empty boxes waiting to be filled,
which means the arguments are the actual data.
Speaker 2 (13:02):
Yes, exactly. The arguments are the specific values you pass
into those boxes at the exact moment you execute the function.
Speaker 1 (13:08):
So if I call showplayer health Candra.
Speaker 2 (13:11):
Fifty, the string candra and the number fifty are the arguments.
The function safely ingests them, runs its internal logic, and
finishes its job without ever needing to look out at
the global scope.
Speaker 1 (13:21):
It makes the function entirely self contained, like you could
rip that function out of the crypt drop it into
a completely different game engine, and as long as you
pass it the right arguments, it's going to execute flawlessly.
Speaker 2 (13:33):
And this modularity becomes exponentially more powerful when you introduce
the return keyword.
Speaker 1 (13:38):
Your return keyword yeah.
Speaker 2 (13:39):
Because up until now, our functions have basically been dead ends.
Speaker 1 (13:44):
Right. They do a job and stop.
Speaker 2 (13:46):
They perform an action like printing text to a screen,
but they don't give the larger program anything back to
work with. The data goes in, gets processed, and basically vanishes.
Speaker 1 (13:55):
So how does return change that?
Speaker 2 (13:57):
It allows a function to evaluate data and then hand
the calculated result back to the main program. Larsen uses
a great example of a plumber calculating a bill.
Speaker 1 (14:06):
Oh where are this?
Speaker 2 (14:07):
You write a total cost function. It takes three parameters,
a slack call out fee, an hourly rate and the
hours worked.
Speaker 1 (14:14):
So if a plumber charges a thirty dollars fee a
forty dollars hourly rate and works for three hours, you
pass those arguments in, so it's like total costs thirty forty.
Speaker 2 (14:24):
Three exactly, and the function acts as this isolated processing plant.
It calculates thirty plus one twenty internally, arriving at one fifty.
Then it uses the return keyword to output that value
return one fifty.
Speaker 1 (14:37):
Got it.
Speaker 2 (14:38):
The crucial architectural concept here is that the function call
itself is literally dynamically replaced by the output in your code.
Wait really yeah, The code total cost thirty forty three
effectively becomes the number one fifty in your larger script.
Speaker 1 (14:52):
Oh wow, which means you can now compose functions together.
You can take that return one fifty and immediately pass
it as an argument into a caxulate tax function, or
subtract it from a budget variable.
Speaker 2 (15:04):
Precisely, the output of one isolated machine becomes the raw
material for the next. It allows you to build these massive,
intricate pipelines of logic where data flows cleanly from one
self contained puzzle piece to another.
Speaker 1 (15:16):
Without ever polluting the global memories exactly. Okay, here's where
it gets really interesting. Oh yeah, we know how to
pass individual arguments to isolate our functions. But as a
game like the crypt scales, passing individual data points just
gets messy. I mean, if I want a function to
process a player's turn, I have to pass their name,
health location, current weapon, their inventory array status effects.
Speaker 2 (15:40):
It's too much. Passing ten different arguments in a very
specific sequence is incredibly fragile.
Speaker 1 (15:45):
Because if I swap the order of two arguments by mistake.
Speaker 2 (15:48):
The game suddenly thinks the player's weapon is their health
score and it crashes.
Speaker 1 (15:53):
Right, So what's the solution.
Speaker 2 (15:54):
This is where we combine our two major concepts. We
emerge the first aid kits with the code on demand.
Speaker 1 (15:59):
Oh objects meaning functions.
Speaker 2 (16:01):
Yes, instead of passing a fragile list of primitive arguments,
you just pass the entire object into the function.
Speaker 1 (16:06):
You just hand the processing plant the entire first aid kit.
Speaker 2 (16:09):
It creates incredibly clean architecture. Larsen illustrates this by passing
a planet object into a calculate size is function. The
function only requires a single parameter, now the object itself.
Speaker 1 (16:21):
Okay, so it takes the whole planet object.
Speaker 2 (16:23):
Right, and once the object is inside the function can
unpack it, read the planet's radius, perform complex geometry, and
then instantly attach brand new properties like area and volume
directly onto the object before returning it.
Speaker 1 (16:36):
So the object goes into the function, gets upgraded, and
comes out with new capabilities exactly. But the relationship between
objects and functions goes even deeper than that, right, because
functions don't just process objects, they can actually live inside them.
Speaker 2 (16:49):
Yes, when a function is a sign as a property
of an object, it becomes what we call a method
a method, and this is the foundation of object oriented design.
It allows you to create names.
Speaker 1 (17:00):
Larsen spacer object is the perfect showcase for why name
spaces matter.
Speaker 2 (17:05):
It really is. In any complex program, you end up
with dozens of small utility functions, for instance, functions to
format text right, adding blank lines, wrapping texts in dashed boxes,
and denting paragraphs. Right. If you leave all those formatting
functions loose in the global scope, they clutter your environment.
Speaker 1 (17:22):
Yeah, you wouldn't want a generic function just named box
floating around, so someone else might write a physics function
named box and suddenly the two are.
Speaker 2 (17:30):
Colliding exactly, So instead you create a single dedicated object
called spacer, and you attach all your formatting functions to
it as methods.
Speaker 1 (17:39):
Oh I see. So now when you want to format
a textbox in your game, you call spacer dot box. Right,
the functionality is buddle directly with the name space. You
know exactly where your tools live, and they are protected
from colliding with the rest of the codebase.
Speaker 2 (17:53):
And you know, while we are exploring methods attached to objects,
there is a behind the scenes technical secret. Larsen reveals
about strings that completely blew my mind when I first
understood the mechanics of it.
Speaker 1 (18:06):
Yes, you were practically vibrating when you read that section, Yeah,
because it completely subverts what we've just learned about objects
and primitive data.
Speaker 2 (18:13):
It really does. So we've established that objects are these
complex structures you architect with properties and methods, right, and
primitive data like a simple string of text, just a
word like Jupiter wrapped in quotes, is just basic data. Technically,
it is not an object, right.
Speaker 1 (18:30):
It doesn't have namespace, it doesn't have methods attached to it.
It's just a raw value.
Speaker 2 (18:34):
But in JavaScript you can take that raw string Jupiter
and call a method directly on it.
Speaker 1 (18:40):
Wait, how you can.
Speaker 2 (18:41):
Type jupiter dot two uppercase and the system instantly returns
the word Jupiter in all capital letters.
Speaker 1 (18:48):
But hold on, If methods only exist inside objects, how
can a raw piece of text execute a method.
Speaker 2 (18:56):
That is the invisible genius of the language's engine. JavaScript
knows that strings are primitive, but it also knows developers
need to format them constantly. So the exact millisecond you
attempt to call a method like to uppercase on a
simple string, the engine secretly.
Speaker 1 (19:10):
Intervenes, secretly intervenes.
Speaker 2 (19:12):
Yeah, it takes your primitive text and instantly wraps it
inside a temporary, invisible string object that contains all those
complex formatting methods.
Speaker 1 (19:20):
So it upgrades the text into an object behind your back.
Speaker 2 (19:22):
Yes, it creates the object, borrows the formatting method to
capitalize your word, hands you the result, and then instantly
destroys that temporary object to free up memory before you
even realize it happened.
Speaker 1 (19:34):
That is astonishing. It's like having an invisible phantom workforce.
You ask a simple piece of text to do something
incredibly complex, and the agent just spins up an entire
architectural structure in the background does the heavy lifting. And
obliterates the evidence before the next line of code even runs.
Speaker 2 (19:50):
It is a masterclass in garbage collection and memory management.
The engine gives you the immense power and convenience of
complex object methods without forcing you to permanently sacrifice the
memory required to store every single word as a massive object.
Speaker 1 (20:05):
It really makes you realize how much aggressive optimization is
happening under the surface of every single.
Speaker 2 (20:10):
Web page, which brings us back to that illusion of
the glowing box. You know, the magic isn't magic, it's
just greath takingly efficient logic.
Speaker 1 (20:18):
So what does this all mean for you? Whether you
are gearing up to write your first text adventure or
you're just trying to understand the digital ecosystem you interact
with every single day.
Speaker 2 (20:28):
Well beyond the syntax understanding how variables, objects, functions, and
methods interact, it's really about learning a new paradigm for
problem solving.
Speaker 1 (20:37):
Oh absolutely.
Speaker 2 (20:38):
Programming forces you to look at a chaotic reality and
synthesize it into modular systems.
Speaker 1 (20:43):
You're learning how to chunk related information to reduce mental load,
which is exactly what objects do. And you're identifying repetitive
patterns and automating them to prevent errors, which what functions do?
Speaker 2 (20:55):
You start to view large problems not as insurmountable monoliths,
but as a series of small, decoupled systems that just
need to pass the correct arguments to one another. You
basically optimize your own workflow the same way you optimize code.
Speaker 1 (21:09):
Which leaves me with a final, slightly provocative thought to ponder.
Inspired by this entire journey, We've just spent this time
dismantling the digital world, realizing that everything on our screens
is ultimately just a massive, intricate collection of encapsulated objects
passing properties into isolated functions.
Speaker 2 (21:27):
Yeah, it is a giant, cascading web of structured inputs
and predictable outputs.
Speaker 1 (21:33):
So how much of our own human behavior could be
mapped using the exact same architecture?
Speaker 2 (21:39):
Oh wow?
Speaker 1 (21:40):
Think about your daily routines, your ingrained habits, your emotional
responses to stress. Are we in some way just executing
highly optimized functions responding to external arguments like when someone
cuts you off in traffic? Is that just an argument
being passed into your stress response function, returning a very
predictable output based on the state of your internal variables
that day?
Speaker 2 (21:59):
It's a really helling framework for introspection. Are we consciously
architecting our responses or are we just running legacy code
that we never bothered to.
Speaker 1 (22:07):
Decouple something to mull over. The next time you find
yourself stuck in a repetitive loop, maybe it's time to
check your dependencies and write a new function. Thank you
so much for joining us on this deep dive. Keep exploring,
keep questioning, and remember even the most complex digital castles
in the world are built from the exact same microscopic,
logical grains of sand.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
The Bobby Bones Show
Listen to 'The Bobby Bones Show' by downloading the daily full replay.