DEV Community

Cover image for Book Club: Eloquent JavaScript - Chapter 2
Alex Kharouk
Alex Kharouk

Posted on

Book Club: Eloquent JavaScript - Chapter 2

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
Enter fullscreen mode Exit fullscreen mode

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);
Enter fullscreen mode Exit fullscreen mode

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++;
}
Enter fullscreen mode Exit fullscreen mode

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);
  }
}
Enter fullscreen mode Exit fullscreen mode

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);
  }
}
Enter fullscreen mode Exit fullscreen mode

Top comments (3)

Collapse
 
peerreynders profile image
peerreynders

Anything that produces a value is an expression.

That is an important distinction from a statement. But there is more to it:

  • Expressions evaluate to a result value
  • Statements are instructions that perform some action and do not return a value.

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:

  • Expressions manipulate the flow of values (data)
  • Statements manipulate the flow of control

The most obvious example is the if…else statement_vs. the conditional operator (an _expression).

if (i % 5 === 0) word += 'Buzz';
Enter fullscreen mode Exit fullscreen mode

with an if statement the associated block is only executed if the conditional expression evaluates to a truthy value. The else portion is entirely optional. This is about flow of control.

Contrast this with

const buzz = i % 5 === 0 ? 'Buzz' : '';
Enter fullscreen mode Exit fullscreen mode

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 of i to a value of Buzz or an empty string.

Aside:

let word = 'Fizz';
let other = '';
const  result = other = word += 'Buzz';
console.log(word);   // 'FizzBuzz'
console.log(other);  // 'FizzBuzz'
console.log(result); // 'FizzBuzz'
Enter fullscreen mode Exit fullscreen mode

The addition assignment as well as assignment are expressions, i.e. they produce a value that can be bound. In the case of

word += 'Buzz';
Enter fullscreen mode Exit fullscreen mode

the produced value is simply ignored.

I like to look at expressions as nouns — statements as verbs or actions.

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

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);
  }
}
Enter fullscreen mode Exit fullscreen mode

we could use the conditional operator

function fizzBuzzer(n) {
  for (let i = 1; i <= n; i += 1) {
    const buzz = i % 5 === 0 ? 'Buzz' : '';
    console.log((i % 3 === 0 ? 'Fizz' + buzz : buzz) || i);
  }
}
Enter fullscreen mode Exit fullscreen mode

and jumping ahead a bit

function fizzBuzzer(n) {
  for (let i = 1; i <= n; i += 1) console.log(fizzBuzz(i));
}

function fizz([word, n]) {
  return [n % 3 === 0 ? 'Fizz' + word : word, n];
}

function buzz([word, n]) {
  return [n % 5 === 0 ? 'Buzz' + word : word, n];
}

function fizzBuzz(n) {
  return buzz(fizz(['', n]))[0] || n.toString();
}
Enter fullscreen mode Exit fullscreen mode

and perhaps

const fizz = ([word, n]) => [n % 3 === 0 ? 'Fizz' + word : word, n];
const buzz = ([word, n]) => [n % 5 === 0 ? 'Buzz' + word : word, n];
const fizzBuzz = (n) => buzz(fizz(['', n]))[0] || n.toString();

function fizzBuzzer(n) { 
  for (let i = 1; i <= n; i += 1) console.log(fizzBuzz(i));
}
Enter fullscreen mode Exit fullscreen mode

overdoing it a bit

const makeFbTransform =
  (divisor, fragment) =>
  ([word, n]) =>
    [n % divisor === 0 ? fragment + word : word, n];
const fizz = makeFbTransform(3, 'Fizz');
const buzz = makeFbTransform(5, 'Buzz');
const fizzBuzz = (n) => buzz(fizz(['', n]))[0] || n.toString();

function fizzBuzzer(n) {
  for (let i = 1; i <= n; i += 1) console.log(fizzBuzz(i));
}
Enter fullscreen mode Exit fullscreen mode

and delaying the side effects a bit more

onst makeFbTransform =
  (divisor, fragment) =>
  ([word, n]) =>
    [n % divisor === 0 ? fragment + word : word, n];
const fizz = makeFbTransform(3, 'Fizz');
const buzz = makeFbTransform(5, 'Buzz');
const fbs = Array.from({ length: 100 }, fizzBuzz);

show(fbs);

function fizzBuzz(_value, index) {
  const n = index + 1;
  return buzz(fizz(['', n]))[0] || n.toString();
}

function show(values) {
  for (const v of values) console.log(v);
}
Enter fullscreen mode Exit fullscreen mode

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.

Collapse
 
kharouk profile image
Alex Kharouk

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 is i % 5 === 0 as that returns a value whilst the whole piece of code is a statement? Is word += 'Buzz' a statement as well, with a side effect?

I am having difficulty correlating "nouns" with the capability of producing and transforming values.

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?

If new information replaces the old, you are doing place oriented programming.

It seems like we are constantly writing statements.

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

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.

Collapse
 
peerreynders profile image
peerreynders • Edited

Is word += 'Buzz' a statement as well, with a side effect?

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.

Would you then say the majority of code in JavaScript is place-oriented?

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).

It may have been more expression-based, but it also loses its simplicity (as you mentioned)

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:

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);
  }
}
Enter fullscreen mode Exit fullscreen mode

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

... for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

don't seem to get the boundary they deserve so

function fizzBuzzer(count) {
  for (let i = 1; i <= count; i += 1) console.log(fizzBuzz(i));
}

function fizzBuzz(n) {
  let word = '';
  if (n % 3 === 0) word += 'Fizz';
  if (n % 5 === 0) word += 'Buzz';
  return word || n.toString();
}
Enter fullscreen mode Exit fullscreen mode

Now "the rules" are extracted into fizzBuzz while fizzBuzzer orchestrates generating the necessary input values and outputs the result values. Note the n.toString() to ensure that fizzBuzz returns a string rather than a string | number (sum types).

Now if you're OK with local reassignment/mutation you can stop here.

Eliminating reassignment/mutation takes a bit more work

function fizzBuzzer(count) {
  for (let i = 1; i <= count; i += 1) console.log(fizzBuzz(i));
}

function fizzBuzz(n) {
  return buzz(fizz(n)) || n.toString();
}

function fizz(n) {
  return n % 3 === 0 ? ['Fizz', n] : ['', n];
}

function buzz(value) {
  const [word, n] = value;
  return n % 5 === 0 ? word + 'Buzz' : word;
}
Enter fullscreen mode Exit fullscreen mode

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 and n 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 to buzz.

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 as n |> 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 and buzz - they can be easily homogenized:

function fizzBuzzer(count) {
  for (let i = 1; i <= count; i += 1) console.log(fizzBuzz(i));
}

function fizzBuzz(n) {
  return buzz(fizz(['', n]))[0] || n.toString();
}

function fizz(value) {
  const [word, n] = value;
  return n % 3 === 0 ? [word + 'Fizz', n] : value;
}

function buzz(value) {
  const [word, n] = value;
  return n % 5 === 0 ? [word + 'Buzz', n] : value;
}
Enter fullscreen mode Exit fullscreen mode

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 the word with an array index of 0. At this point somebody may yell "repetition":

function fizzBuzzer(count) {
  for (let i = 1; i <= count; i += 1) console.log(fizzBuzz(i));
}

function fizzBuzz(n) {
  return buzz(fizz(['', n]))[0] || n.toString();
}

function makeTransform(divisor, fragment) {
  return function (value) {
    const [word, n] = value;
    return n % divisor === 0 ? [word + fragment, n] : value;
  };
}

const fizz = makeTransform(3, 'Fizz');
const buzz = makeTransform(5, 'Buzz');
Enter fullscreen mode Exit fullscreen mode

Pros: nice highlighting and separation of commonality and variability.

Commonality:

function makeTransform(divisor, fragment) {
  return function (value) {
    const [word, n] = value;
    return n % divisor === 0 ? [word + fragment, n] : value;
  };
}
Enter fullscreen mode Exit fullscreen mode

Variability:

const fizz = makeTransform(3, 'Fizz');
const buzz = makeTransform(5, 'Buzz');
Enter fullscreen mode Exit fullscreen mode

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 need fizz and buzz.

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:

function fizzBuzz(n) {
  return buzz(fizz(['', n]))[0] || n.toString();
}

function fizz(value) {
  const [word, n] = value;
  return n % 3 === 0 ? [word + 'Fizz', n] : value;
}

function buzz(value) {
  const [word, n] = value;
  return n % 5 === 0 ? [word + 'Buzz', n] : value;
}

function displayValues(values) {
  for (const value of values) console.log(value);
}

displayValues(Array.from({ length: 100 }, (_v, i) => fizzBuzz(i + 1)));
Enter fullscreen mode Exit fullscreen mode

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):

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);
  }
}
Enter fullscreen mode Exit fullscreen mode

with value-oriented (VOP)

function fizz(value) {
  const [word, n] = value;
  return n % 3 === 0 ? [word + 'Fizz', n] : value;
}

function buzz(value) {
  const [word, n] = value;
  return n % 5 === 0 ? [word + 'Buzz', n] : value;
}

function fizzBuzz(n) {
  return buzz(fizz(['', n]))[0] || n.toString();
}

function displayValues(values) {
  for (const value of values) console.log(value);
}

displayValues(Array.from({ length: 100 }, (_v, i) => fizzBuzz(i + 1)));
Enter fullscreen mode Exit fullscreen mode
  • For one we have to acknowledge that if we learned and primarily practice imperative programming it's going to seem "easier" to us than approaches from other paradigms (for example imperative programming doesn't really prepare you for SQL).
  • FizzBuzz is a small enough problem that it Fits in Your Head as is. Real problems tend to be much larger which is why we distribute functionality over multiple functions or objects. However even when partitioned, reasoning about code which freely interacts with other parts of the system (or "the world") via mutation of shared data and side effects can be difficult primarily because the "state" of mutable things varies with time. For example in the PLOP code 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).
  • Looking at the VOP code: It may initially take some time to get your eye in but fizz is extremely simple: it either returns the original [word,n] value or a new [word + 'Fizz',n] value depending on the value of n. Now fizz isn't as descriptive as on3AppendFizzToWord but in this context it's likely good enough so that we can forget about the actual code and just know what fizz is about.
  • Similarly for buzz as it fits exactly the same pattern.
  • In fizzBuzz the compactness of buzz(fizz(['', n]))[0] could be an issue - I think (['', n] |> fizz |> buzz))[0] would be easier to read, i.e. transform ['',n] through fizz and buzz and use the first element of the resulting value. But again fizzBuzz only uses a single line of extremely simple functions and operators. Once parsed you can forget about the code and know what fizzBuzz means.
  • fizz, buzz and fizzBuzz 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:
    • referentially transparent -> simple
    • referentially opaque -> not so simple
  • The idea is to stick to building "simple" functions as building blocks and create other (simple) building blocks by composing them - yielding functions capable of complex value transformations.
  • Aside: Scott Wlaschin views functions as Interfaces (i.e. simple interfaces). With that view functions should be easier to compose because object interfaces can be a lot more complicated.
  • displayValues has side effects. But it doesn't have to know anything about fizzBuzz. 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.