37 ms·

Sure, this describes the problems with JS's const, but doesn't really describe why it shouldn't be used?

lhorie 6y ago
Most JS people consider it perfectly fine to use it. It's a just a tool. A minority wants to make a storm in a cup of water because they read this[1] [1] https://jamie.build/const https://jamie.build/const
- edf13 6y ago
  He’s an angry chap isn’t he?
  - lhorie 6y ago
    If you ever feel compelled to google him, you may want to grab some popcorn first :)
- giantDinosaur 6y ago
  Hmm, some good points there. I think I'll avoid const now.
  - yashap 6y ago
    I didn’t think any of these points were very strong. const x = {immutableValue} That tells me the thing is fully immutable. Whether it’s a global variable or not, that’s still nice to know when reading the code! Likewise: let x = {immutableValue} const x = {mutableValue} These tell me different things. The first tells me I should look out for re-assignment, the second that I should look out for mutation of the value. In contrast, this: let x = {mutableValue} Clearly has the most cognitive load. Anything could happen with this. If it’s a bigger, more complex function/whatever, “what happens to x, it could be anything” is just one more thing to fit in my head as I try to figure out what this code does. Enough little uncertainties like this, and I have to give up understanding by reading entirely, and resort to a debugger. Had the author limited the scope of what was possible, it’d be a bit easier to understand, with really no drawbacks. It’s not the end of the world, but “small, simple, easy thing I can do to make the code easier to understand for future readers” ... why not do that?
    - giantDinosaur 6y ago
      Really, I just have a somewhat FP bias, and I'd really enjoy it if const was actually immutable, since it'd be a nice concise way of expressing that. It's just not as useful as you'd think given how often it seems to be used (by contrast I almost never see anyone actually making anything immutable in JS).
      - yashap 6y ago
        I like FP too, but most languages, including FP ones, have both mutable/immutable references and mutable/immutable values. And in JS, things like strings, numbers and booleans are immutable value, plus immutable.js is quite popular for immutable data structures, especially in React+Redux apps.
- russellbeattie 6y ago
  Nice projection. I say over-using const is a fad (which it is) so you repeat it. I have zero idea who that guy is. Not even bothering to click, actually, as I'm sure he's just going to say what I said.
  - lhorie 6y ago
    Ironically, I think your comment falls into the same cognitive trap as the const vs let thing: the always-use-let argument is usually that const does not mean immutable data structure and that fact is confusing, so you should let to signal that the data structure is mutable, even though what let really means is to make the binding mutable, not to indicate anything about the data structure it points to. The counter-argument - despite what it may seem - is not the opposite stance, but rather that because bindings and data structures are two different things, conflating the two is confusing. Likewise, I'm saying that a minority is vocal because reading a rant from a OSS celebrity either reaffirms their preconceptions or sways them through aggressiveness (both of which are objectively true, as I have witnessed cases of both), but you're accusing me of projecting (presumably because you think that I'm making a claim about you personally - which is not true). Consider that some of the words you use are weasel words ("overusing", "fad"), which, IMHO imply a tautology (i.e. "I think X, therefore X", as opposed to "The facts are X, therefore Y"). I originally said that the spec is clear about what const and let are. Implying that following the spec is a fad is needlessly derogatory and doesn't address the double standard with regards to the confusing-ness of const vs let.

Most JS people consider it perfectly fine to use it. It's a just a tool. A minority wants to make a storm in a cup of water because they read this[1] [1] https://jamie.build/const https://jamie.build/const

edf13 6y ago
He’s an angry chap isn’t he?
- lhorie 6y ago
  If you ever feel compelled to google him, you may want to grab some popcorn first :)
giantDinosaur 6y ago
Hmm, some good points there. I think I'll avoid const now.
- yashap 6y ago
  I didn’t think any of these points were very strong. const x = {immutableValue} That tells me the thing is fully immutable. Whether it’s a global variable or not, that’s still nice to know when reading the code! Likewise: let x = {immutableValue} const x = {mutableValue} These tell me different things. The first tells me I should look out for re-assignment, the second that I should look out for mutation of the value. In contrast, this: let x = {mutableValue} Clearly has the most cognitive load. Anything could happen with this. If it’s a bigger, more complex function/whatever, “what happens to x, it could be anything” is just one more thing to fit in my head as I try to figure out what this code does. Enough little uncertainties like this, and I have to give up understanding by reading entirely, and resort to a debugger. Had the author limited the scope of what was possible, it’d be a bit easier to understand, with really no drawbacks. It’s not the end of the world, but “small, simple, easy thing I can do to make the code easier to understand for future readers” ... why not do that?
  - giantDinosaur 6y ago
    Really, I just have a somewhat FP bias, and I'd really enjoy it if const was actually immutable, since it'd be a nice concise way of expressing that. It's just not as useful as you'd think given how often it seems to be used (by contrast I almost never see anyone actually making anything immutable in JS).
    - yashap 6y ago
      I like FP too, but most languages, including FP ones, have both mutable/immutable references and mutable/immutable values. And in JS, things like strings, numbers and booleans are immutable value, plus immutable.js is quite popular for immutable data structures, especially in React+Redux apps.
russellbeattie 6y ago
Nice projection. I say over-using const is a fad (which it is) so you repeat it. I have zero idea who that guy is. Not even bothering to click, actually, as I'm sure he's just going to say what I said.
- lhorie 6y ago
  Ironically, I think your comment falls into the same cognitive trap as the const vs let thing: the always-use-let argument is usually that const does not mean immutable data structure and that fact is confusing, so you should let to signal that the data structure is mutable, even though what let really means is to make the binding mutable, not to indicate anything about the data structure it points to. The counter-argument - despite what it may seem - is not the opposite stance, but rather that because bindings and data structures are two different things, conflating the two is confusing. Likewise, I'm saying that a minority is vocal because reading a rant from a OSS celebrity either reaffirms their preconceptions or sways them through aggressiveness (both of which are objectively true, as I have witnessed cases of both), but you're accusing me of projecting (presumably because you think that I'm making a claim about you personally - which is not true). Consider that some of the words you use are weasel words ("overusing", "fad"), which, IMHO imply a tautology (i.e. "I think X, therefore X", as opposed to "The facts are X, therefore Y"). I originally said that the spec is clear about what const and let are. Implying that following the spec is a fad is needlessly derogatory and doesn't address the double standard with regards to the confusing-ness of const vs let.