There is joy in reading about JavaScript. It's like catching up with an old friend who is sharing what they've been doing. Lots of cool new ideas; super popular. Yet fundamentally, they haven't changed. They're the same, weird, sometimes awkward friend. That first friend, for some of us. In the end, we're just happy they're doing well.
That's the sensation I'm getting with reading Eloquent JavaScript. Last time, I began reading the book after a difficult interview. It opened my eyes that I know Javascript, but do I really know JavaScript? I've received comments that I should read Kyle Simpson's YDKJS (You Don't Know JS) books. I do own them. I suppose I didn't want to start with a series. I wanted a beginning-to-end kind of story. That said, I wouldn't be surprised if I decide to pick it up after Eloquent JavaScript.
On to Chapter 2, Program Structure.
And my heart glows bright red under my filmy, translucent skin and they have to administer 10cc of JavaScript to get me to come back. (I respond well to toxins in the blood.) Man, that stuff will kick the peaches right out your gills!
-_why, Why's (Poignant) Guide to Ruby
First of all, what a great quote. I read Why's guide a long time ago. It was humorous and showed me how diverse programming language communities are. Okay, back to the chapter two.
Expressions and Statements
We begin with understanding what expressions are and what are statements. Anything that produces a value is an expression. Anything that is written literally is also a value. 22
is an expression. "hello world"
is an expression. Within a line of code, there can be multiple expressions. With that said, the line of code itself would be a statement. 1
is an expression, 1;
is a statement.
Notice the difference?
I like to look at expressions as nouns — statements as verbs or actions. The action can sometimes be implicit, however. In JavaScript, you don't always need to add the ;
to denote the end of a statement, so sometimes, you can omit explicit statements for implicit ones.
Statements can be simple, like 1;
. But these statements aren't interesting; they are useless. Interesting statements affect something. Have an impact on its world. They could display something on the screen or update the state of a program. These statements can impact other statements, creating what is known as side effects.
Side effects might sound familiar to you if you use React Hooks. I've encountered that description due to learning about useEffect
. I always thought side effects were something that the React developers referenced. It's much more than that. A side effect is simply a statement containing an action or result that could impact other statements.
Bindings
Marijn uses bindings to describe a way to store data and keep an internal state. If that sounds familiar to you, it may be because you know what variables are. However, Marijn seems to insist and call them bindings. I suppose it has something to do with their definition of a variable.
A variable is labelled as "not consistent" or having a fixed pattern; it is liable to change. This is partly correct with JavaScript variables. Using keywords like let
or var
makes sense with this definition. Using the keyword const
does not fit this definition. Another way I was taught variables was by thinking about them as boxes. You are designating boxes for data you want to store and use later. If you need that data, you open up the box.
The author asks you to think a bit differently. Think of variables, or bindings, like tentacles rather than boxes. Think of them as pointers to values rather than containing values. Here's an example:
let ten = 10
. ten
doesn't unpack and reveal the data 10
. What it does is it returns you the number 10
that it references.
It's a curious way of thinking about variables, and maybe a bit too much time was spent thinking about whether they're more like boxes or tentacles. I believe the author to be correct. Variables are references to data in memory. If we look at the code, we see that they are equal when comparing the two bindings. Why? Because 10
is saved in memory once, and both ten
and anotherTen
variables reference the number. Same with the string example.
let ten = 10;
let anotherTen = 10;
console.log(ten === anotherTen); // true; they are equal
let word = 'hello';
let anotherWord = 'hello';
console.log(word === anotherWord); // true
Again, something as simple as variables creates a discussion! It's fascinating how, when I first studied Javascript, I essentially skimmed through why things were the way they are. The rest of the chapter discusses loops and conditional execution (if-statements). If you are unsure about these topics, please make sure you read the chapter. Otherwise, I've noticed two things that I was not familiar with when using loops.
Do, while loop.
let yourName;
do {
yourName = prompt('what is your name?');
} while (!yourName);
The difference here is that we always execute the block at least once. We always prompt the user for their name.
If they don't enter an accepted value, we will be in a loop until we get the name. I usually don't use do, while
loops, but it's good to remember as a reference. Another thing about loops, specifically traditional for
loops, is that they must contain two semicolons. I write the usual syntax so frequently that I never contemplated why I needed the semicolons in the loops. Well, the statement before the first semicolon is an expression or variable declaration. After the first semicolon, we have the condition, an expression that is evaluated before each loop iteration. Lastly we have the final expression, which will be evaluated at the end of each loop iteration.
//Notice empty space v -- we don't set a condition so it can run forever if we let it
for (let current = 20; ; current = current + 1) {
if (current % 7 == 0) {
console.log(current);
break;
}
}
var i = 0;
for (;;) {
if (i > 3) break; // we need the break statement, and still need the two semicolons!
console.log(i);
i++;
}
So that's it for Chapter two of the book. What did you think of it? Do you think I focused too much on the theory rather than explaining other aspects, such as loops or if-conditions? Are you enjoying the book yourself? I thought this chapter was a bit of a slower pace compared to the first chapter. A minor spoiler, but I have also read the third chapter Functions, and things pick up. By far my favourite chapter, so it's worth getting through chapter two.
Big thanks for the comments from the dev.to community. If you'd like to see some additional resources recommended by the community, check out the thread for the first chapter here.
Until next time.
Originally posted on my personal blog website, which you could see at alex.kharo.uk
Extra Exercises:
Chapter 2 introduced some exercises, which included a FizzBuzz exercise. My first attempt was the traditional way:
// print fizzBuzz from 1..n
function fizzBuzz(count) {
for (let i = 1; i <= count; i++) {
if (i % 15 === 0) console.log('FizzBuzz');
else if (i % 3 === 0) console.log('Fizz');
else if (i % 5 === 0) console.log('Buzz');
else console.log(i);
}
}
However we were told to think about a cleverer solution, combining the printed text together:
function fizzBuzz(count) {
for (let i = 1; i <= count; i++) {
let word = '';
if (i % 3 === 0) word += 'Fizz';
if (i % 5 === 0) word += 'Buzz';
console.log(word || i);
}
}
Top comments (3)
That is an important distinction from a statement. But there is more to it:
It's in the nature of JavaScript that expression evaluation can have side effects even though it's generally accepted that doing so makes code less understandable.
On a more abstract level one could observe:
The most obvious example is the if…else statement_vs. the conditional operator (an _expression).
with an
if
statement the associated block is only executed if the conditional expression evaluates to a truthy value. Theelse
portion is entirely optional. This is about flow of control.Contrast this with
Being an expression the conditional operator has to return a value one way or another , so an
else
value is required - it's not optional. But given that we are guaranteed to get a value we can "grasp it" with a binding. This is about the flow of values. The expression transforms the value ofi
to a value ofBuzz
or an empty string.Aside:
The addition assignment as well as assignment are expressions, i.e. they produce a value that can be bound. In the case of
the produced value is simply ignored.
I'm not sure if you will find this analogy helpful in the long run and I wonder whether you arrived at this because you focused on constant expressions. While it's true that you ultimately need side effects to get anything done you can also make progress by transforming values (and then only finally performing the side effect). I'm having difficulty correlating "nouns" with the capability of producing and transforming values.
In chapter 3 you'll be introduced to functions and in particular to the concept of "pure functions". All functions in JavaScript return a value, some simply return the undefined value. Pure functions are like expressions because they transform (input) values (producing an identical value for the same input values). Functions with side effects are more like statements. Using pure functions is a more expression-based style while predominantly using functions with side effects leads to a more imperative style (literally programming with statements; do this, then that, then the other thing) of coding.
Another way of looking at it is that expressions are value-oriented while statements are place-oriented (Value of values).
JavaScript allows for a much more expression-based style than other mainstream languages. Starting with
we could use the conditional operator
and jumping ahead a bit
and perhaps
overdoing it a bit
and delaying the side effects a bit more
Now if you learned programming with an imperative, statement-based language (as most people do) then the expression-based style will look alien - simply because it's unfamiliar (Simplicity Matters).
The point is that the expression-based style doesn't rely on mutation in the same way that the statement-based style does.
In JavaScript mutation isn't "evil", it's par for the course. Local mutability is usually fine but mindless, careless mutation can become a problem. Adopting an expression-based coding style can help reduce the use of mutation - as long as the performance cost and memory consumption remains within acceptable limits (there's always a trade-off and it's always a balancing act).
Another thing that may interest you: JavaScript for-loops are… complicated - HTTP203.
Wow, @peerreynders , thanks again for the lovely, in-depth reply.
Just to clarify some things, does that mean in this piece of code:
if (i % 5 === 0) word += 'Buzz';
the expression isi % 5 === 0
as that returns a value whilst the whole piece of code is a statement? Isword += 'Buzz'
a statement as well, with a side effect?I initially looked at expressions as values;
5
is 5, but with your comment on how expressions result from an evaluation, I see that expressions are far more than just "values". As you mentioned, they can also transform values or manipulate the flow. I suppose I did regard them as constant expressions.I have never heard of PLOP or the value of values talk! Interesting. Would you then say the majority of code in JavaScript is place-oriented?
It seems like we are constantly writing statements.
If we look at how you disassembled the
FizzBuzz
example to be more expression-based, it became less and less clear on what exactly was the code suppose to be doing. It may have been more expression-based, but it also loses its simplicity (as you mentioned), so I would add that as a limit alongside performance and memory consumption.Assignments are expressions, the only thing that's a statement is the
if
statement. It's unfortunate but in JavaScript expression evaluation can have side effects.Make no mistake, JavaScript is an imperative language. In fact it's way more statement-based than for example Rust. While also being an imperative language Rust embraced expressions to such an extent that it supports a lot of practices that are typical for functional languages while also supporting an imperative style of coding. But as a result of Brendan Eich being a Scheme fan when he designed JavaScript there is enough wiggle room to pursue a value-oriented style in JavaScript (JavaScript is a LISP). And from what I can judge that is the style that Marijn Haverbeke is leaning towards (though not with any dogma).
I would argue that it actually gains simplicity but loses "easiness" ("simple" scales, "easy" does not).
Before I can dive into that particular discussion it may be useful to expose my thinking behind the various changes:
Again starting with:
For my taste this is a bit of a lumpers solution - it feels more like a script than a function with focus - and given the context that may be OK.
However the core rules
don't seem to get the boundary they deserve so
Now "the rules" are extracted into
fizzBuzz
whilefizzBuzzer
orchestrates generating the necessary input values and outputs the result values. Note then.toString()
to ensure thatfizzBuzz
returns astring
rather than astring | number
(sum types).Now if you're OK with local reassignment/mutation you can stop here.
Eliminating reassignment/mutation takes a bit more work
Functions that accept one single value compose better given that functions only return one value. To be able to simply write
buzz(fizz(n))
fizz
has to return the string andn
simultaneously. Traditionally in JavaScript an object{ word , n }
would be used for that purpose but for just two values that's a bit verbose so a tuple is used to pass the necessary data tobuzz
.Aside:
JavaScript only has arrays, however they can be used in different ways. When an array is used "as a list" it can hold zero to many elements but the elements are often expected to be all of the same type. When an array is used as a tuple it is expected to have a certain, exact length but can hold values of varying types though each position holds the expectation of a specific type. Here
fuzz
returns a[string,number]
tuple (pair, couple).There is a pipeline proposal under consideration. With that
buzz(fizz(n))
could be rewritten asn |> fizz |> buzz
- pipelining values through a chain of functions makes the order of operations more obvious.At this point there is a certain similarity between
fizz
andbuzz
- they can be easily homogenized:This makes
buzz(fizz(['', n]))[0]
a bit more complicated.['', n]
has to be supplied as an initial value and at the end we extract theword
with an array index of0
. At this point somebody may yell "repetition":Pros: nice highlighting and separation of commonality and variability.
Commonality:
Variability:
Cons:
makeTransform
is more difficult to understand. And more importantly I think this is a case of duplication being far cheaper than the (wrong) abstraction given that we know that we'll only ever needfizz
andbuzz
.Now one could be perfectly OK with the reassignment/mutation for the sake of a
for…loop
but staying with the "no destruction of values" theme:Sorry, as far as I'm concerned forEach is an imposter HOF (higher order function), so I'll prefer
for…of
Now back to our originally scheduled programming…
Juxtaposing place-oriented (PLOP):
with value-oriented (VOP)
word
isn't just a simple value but it potentially keeps changing (though given that it's not exposed outside of the loop it isn't a big issue in this case).fizz
is extremely simple: it either returns the original[word,n]
value or a new[word + 'Fizz',n]
value depending on the value ofn
. Nowfizz
isn't as descriptive ason3AppendFizzToWord
but in this context it's likely good enough so that we can forget about the actual code and just know whatfizz
is about.buzz
as it fits exactly the same pattern.fizzBuzz
the compactness ofbuzz(fizz(['', n]))[0]
could be an issue - I think(['', n] |> fizz |> buzz))[0]
would be easier to read, i.e. transform['',n]
throughfizz
andbuzz
and use the first element of the resulting value. But againfizzBuzz
only uses a single line of extremely simple functions and operators. Once parsed you can forget about the code and know whatfizzBuzz
means.fizz
,buzz
andfizzBuzz
are pure functions and therefore referentially transparent. referential transparency is the property of being able to replace a function with its return value for a given input; functions that depend on other factors are referentially opaque, so:displayValues
has side effects. But it doesn't have to know anything aboutfizzBuzz
. These type of functions are necessary but ideally we should separate them for easy identification. Ideally a system should be organized as functional core and imperative shell (Hexagonal architecture). The functional core should be easy to test as it just transforms values.The idea is that VOP scales better than PLOP for larger problems because it can stick to simple building blocks while achieving complex value transformations through composition.
If you're interested Refactoring JavaScript goes through typical tactics used to improve JavaScript code. It discusses OO-practices as well as functional practices. The functional refactoring largely revolves around avoiding destructive actions, mutation, and reassignment.