getify
commented
7 years ago I agree re-assignment should be minimized where possible. If I'm using it it's usually because a value is type-changing during the course of a function, and I find it more readable to keep the variable name the same rather than needing some naming convention to keep the "relationship" between two or more variables clear.
I just don't think const adds very much at all to that effort, not enough to outweigh the potential confusion cost.
DrBoolean
Another spot-free chapter tech-wise. Just a few possible suggestions:
I was a bit confused by the diagram for the persistent array data structure. Maybe it'd be good to match the specialArray code below it? I liked the diff analogy and I get the idea, I just couldn't see it from the image. (and I thought I knew this stuff! :) )
there's a typo with
ProcesssingThe
constdiscussion is a const-roversial for sure. As someone who often accidentally names functions the same as variables, I personally find value there, but I see your point. I want to disagree that developers can't understand the difference between immutability and reassignment, but I see that confusion all the time in the industry.In any case, I feel it's worth a mention (somewhere in the book) that reassignment breaks ref transparency (and, therefore, equational reasoning), and adds a substantial obstacle to parallelization, which is why it is not allowed in just about every functional language. I guess I was thinking a note that in FP languages
=means equals, not assignment, which is not the case in JS.I was taken aback by this discussion, though, as it is often cited as improving readability since you don't have to track variable changes as well. As I saw it improved readability was the main aim of this book. I did appreciate and acknowledge, however, that mutation is much less conspicuous than reassignment and priority-wise, should be the focus.