5 ms·

> Why not use `const` as default? The argument I made toward the end of the post is that refactoring from `const` back to `let` is more risky than the other wa

by _getify 11y ago

> Why not use `const` as default? The argument I made toward the end of the post is that refactoring from `const` back to `let` is more risky than the other way around. Moreover, surveying my own code, honestly, the vast majority of my declarations should be `var` or `let`, and only a much smaller amount being `const`. I think a lot of people are rushing blindly to `const` without realizing its full behavior. > [`const`] has less rules ... using `let` will introduce complexity I think this is completely backwards. `let` has no special caveats (other than the TDZ thing, which they both have), whereas `const` has this caveat that it's only about assignment bindings and not about values. Imagine a piece of code that has `const x = 2` that you later refactor to `const x = [2]`. The complexity is, you now have to contend with the `[2]` being a mutable value where `2` wasn't, and `const` sorta pretends to keep you safe but doesn't. That's the complexity I disfavor.

codecurve 11y ago
I think that completely depends on the flavour of code you write. If you mostly use imperative styles, then the large proportion of your declarations will be `var` and `let`. It definitely makes refactoring harder in the direction you mentioned. Alternatively, for a functional style, you have to have a fairly good reason for using `var` or `let`. I find myself treating them like I'd treat atoms in Clojure. They end up being the mechanism you use to make controlled side-effects. I'll concede that `const` does have a complexity to understand...initially. However once you understand the distinction between assignment and value (you only have to understand it once), then you're back to a level playing field between both. From then on, `const` gives you a guarantee about the assignment. Objectively, this guarantee eliminates complexity, you can look at a variable anywhere in a scope and know that it has the same value as at time of declaration (same TDZ exceptions apply). I don't see how this could be seen as backwards.
aquilaFiera 11y ago
Using the mantra code is communication, declaring everything as const lets others (and your future self) know that as of last writing they can expect this variable to not be reassigned. I think that small piece of information can be useful. To your point however, `const` does not imply constant in the sense of other languages (like `.freeze()` does) so it does mean your target future audience is someone who is familiar with some of the nuances of recent JavaScript, an assumption that can be dangerous to make. For my recent ES6 escapades I've been using the pattern of `const` first and `let` only when mutability of assignment is needed and I have yet to have that bite me in the ass. However this has been small projects and I can't speak for a larger codebase.
- Nullabillity 11y ago
  > To your point however, `const` does not imply constant in the sense of other languages (like `.freeze()` does) so it does mean your target future audience is someone who is familiar with some of the nuances of recent JavaScript, an assumption that can be dangerous to make. Does any other language than Rust implement it this way? I know Rust needs to, for the borrowing semantics. Java does it the same way as JS. Scala and Haskell both make everything immutable by default as convention, but there's nothing preventing you from mutating a `var` field of a `val` reference, or abusing `unsafePerformIO` to modify an `IORef` from a supposedly pure context.
  - jharger 11y ago
    C++ Assume you have a class Foo, and this: const Foo fooInst(1, 2, 3); if you try to call a method foo.bar() you can't, unless that method bar() is also marked const with this type of signature: int bar() const; Meaning that bar returns an int, but can't assign to any fields or call any other non-const methods. Although, it does have this hideous const_cast<> operator that anyone can use to break these rules.
adrusi 11y ago
`const` has this caveat that it's only about assignment bindings and not about values. Imagine a piece of code that has `const x = 2` that you later refactor to `const x = [2]`. The complexity is, you now have to contend with the `[2]` being a mutable value where `2` wasn't, and `const` sorta pretends to keep you safe but doesn't. If these semantics aren't instantly obvious to you, then that's emblematic of a serious gap in your understanding of programming. I say this not with the intent of shaming, but to recommend that you (and the very many other people with the same lapse) invest some time into developing intuition about reference semantics. The best way IMO is to get initmately familiar with a language that has first class pointers or otherwise explicit indirection. Learn C, get good at C, write something big in C. Focus on the pointer semantics and you'll come out a significantly better programmer in languages where pointers are slightly less immediately visible. Of course if you're making this recommendation because you work with other people who have a lapse in their understanding of references I can understand that. I would encourage you, however, to try to fix the problem rather than work around it by stunting the language. After all, it's an issue that will crop up everywhere, not just the semantics of `const'.
- _getify 11y ago
  Oh, I see. I just need to learn more. The problem is I just don't know JS (or other langs for that matter). http://YouDontKnowJS.com http://YouDontKnowJS.com
  - abritinthebay 11y ago
    I agree that saying this issue is "emblematic of a serious gap in your understanding of programming" is.. well.. douchebaggery. However I feel a lot of the article and many of your posts about it in here come down to "it makes me feel uncomfortable" which.. I mean, ok. Sure. I hate spaces for indentation and think double quotes are better (and I have reasons for both)... but I don't say there's no use to the other options. I feel you're throwing the baby out with the bathwater here. Should const probably have been about value immutability too? Yes, I think so. I totally agree. That's a REALLY important topic to discuss. Maybe pitch it to the ES2016 committee as an iterative upgrade to const? But as it stands it does have value. Yes it mostly just codifies what programmers original did as a language construct but it does also stop redefinitions which was an annoyingly common issue. So it's progress. Small, incremental, and not as full-featured as we'd both like... but it's progress. Drawing attention to the issues with const is important... but there's no reason to rail so hard against its usage when it's understood to have those limitations... is there?
deleted 11y ago
[deleted]

by _getify 11y ago

codecurve 11y ago

I think that completely depends on the flavour of code you write. If you mostly use imperative styles, then the large proportion of your declarations will be `var` and `let`. It definitely makes refactoring harder in the direction you mentioned. Alternatively, for a functional style, you have to have a fairly good reason for using `var` or `let`. I find myself treating them like I'd treat atoms in Clojure. They end up being the mechanism you use to make controlled side-effects. I'll concede that `const` does have a complexity to understand...initially. However once you understand the distinction between assignment and value (you only have to understand it once), then you're back to a level playing field between both. From then on, `const` gives you a guarantee about the assignment. Objectively, this guarantee eliminates complexity, you can look at a variable anywhere in a scope and know that it has the same value as at time of declaration (same TDZ exceptions apply). I don't see how this could be seen as backwards.

aquilaFiera 11y ago

Using the mantra code is communication, declaring everything as const lets others (and your future self) know that as of last writing they can expect this variable to not be reassigned. I think that small piece of information can be useful. To your point however, `const` does not imply constant in the sense of other languages (like `.freeze()` does) so it does mean your target future audience is someone who is familiar with some of the nuances of recent JavaScript, an assumption that can be dangerous to make. For my recent ES6 escapades I've been using the pattern of `const` first and `let` only when mutability of assignment is needed and I have yet to have that bite me in the ass. However this has been small projects and I can't speak for a larger codebase.

Nullabillity 11y ago
> To your point however, `const` does not imply constant in the sense of other languages (like `.freeze()` does) so it does mean your target future audience is someone who is familiar with some of the nuances of recent JavaScript, an assumption that can be dangerous to make. Does any other language than Rust implement it this way? I know Rust needs to, for the borrowing semantics. Java does it the same way as JS. Scala and Haskell both make everything immutable by default as convention, but there's nothing preventing you from mutating a `var` field of a `val` reference, or abusing `unsafePerformIO` to modify an `IORef` from a supposedly pure context.
- jharger 11y ago
  C++ Assume you have a class Foo, and this: const Foo fooInst(1, 2, 3); if you try to call a method foo.bar() you can't, unless that method bar() is also marked const with this type of signature: int bar() const; Meaning that bar returns an int, but can't assign to any fields or call any other non-const methods. Although, it does have this hideous const_cast<> operator that anyone can use to break these rules.

adrusi 11y ago

`const` has this caveat that it's only about assignment bindings and not about values. Imagine a piece of code that has `const x = 2` that you later refactor to `const x = [2]`. The complexity is, you now have to contend with the `[2]` being a mutable value where `2` wasn't, and `const` sorta pretends to keep you safe but doesn't. If these semantics aren't instantly obvious to you, then that's emblematic of a serious gap in your understanding of programming. I say this not with the intent of shaming, but to recommend that you (and the very many other people with the same lapse) invest some time into developing intuition about reference semantics. The best way IMO is to get initmately familiar with a language that has first class pointers or otherwise explicit indirection. Learn C, get good at C, write something big in C. Focus on the pointer semantics and you'll come out a significantly better programmer in languages where pointers are slightly less immediately visible. Of course if you're making this recommendation because you work with other people who have a lapse in their understanding of references I can understand that. I would encourage you, however, to try to fix the problem rather than work around it by stunting the language. After all, it's an issue that will crop up everywhere, not just the semantics of `const'.

_getify 11y ago
Oh, I see. I just need to learn more. The problem is I just don't know JS (or other langs for that matter). http://YouDontKnowJS.com http://YouDontKnowJS.com
- abritinthebay 11y ago
  I agree that saying this issue is "emblematic of a serious gap in your understanding of programming" is.. well.. douchebaggery. However I feel a lot of the article and many of your posts about it in here come down to "it makes me feel uncomfortable" which.. I mean, ok. Sure. I hate spaces for indentation and think double quotes are better (and I have reasons for both)... but I don't say there's no use to the other options. I feel you're throwing the baby out with the bathwater here. Should const probably have been about value immutability too? Yes, I think so. I totally agree. That's a REALLY important topic to discuss. Maybe pitch it to the ES2016 committee as an iterative upgrade to const? But as it stands it does have value. Yes it mostly just codifies what programmers original did as a language construct but it does also stop redefinitions which was an annoyingly common issue. So it's progress. Small, incremental, and not as full-featured as we'd both like... but it's progress. Drawing attention to the issues with const is important... but there's no reason to rail so hard against its usage when it's understood to have those limitations... is there?

deleted 11y ago

[deleted]