6 ms·

"Now "let" is the new "var" – traditional "var" declarations are complemented with "let" and "const". Both are properly block-scoped bindings, eliminating a com

"Now "let" is the new "var" – traditional "var" declarations are complemented with "let" and "const". Both are properly block-scoped bindings, eliminating a common source of errors and weird behaviour." Somehow going from one keyword for variable declaration to three doesn't seem like a good way to reduce errors.

agscala 15y ago
The extra keywords aren't going to reduce the "errors and weird behavior", the fact that they will be block-scoped and not function-scoped is what will eliminate the confusion.
- ams6110 15y ago
  I agree with geuis above, JavaScript scope is simple to understand now. There is global scope, and there is function scope. That's it. And there's a certain elegance to that.
  - wingo 15y ago
    There are more scopes than that: free variables versus locals; eval-introduced bindings; "with"; the exception identifier in "catch"; the function name in named function expressions; argument names; etc. And the scoping rules are quite tricky in practice, to real programmers. To take an example from today: https://bugs.webkit.org/show_bug.cgi?id=27226#c4 https://bugs.webkit.org/show_bug.cgi?id=27226#c4
    - grannyg00se 15y ago
      Looking at that example, I would ask ....where exactly is that function definition getting defined? Why would you put a function definition inside a catch block? Do you think it's getting defined when the catch block is called? Are you programming in Javascript, or are you just writing javascript the way you would write code in some other language?
      - sirclueless 15y ago
        It's a pretty straightforward use-case: you have a function that returns a function, and in the case of an internal error, you want the returned function to have a reference to the error object. And the only reliable way to do that is to declare a variable with function scope, declare a function in function scope, and conditionally return this function? That's absurdly broken. As for variable scoping rules, if you have never been bitten by loop counters being used improperly, then I assert that you haven't programmed enough javascript. There are so many ways to mess this up: forget a var declaration and it leaks scope -- and since you can only declare it once, you can't just always use "for (var i = ...". If you want to defer access to a loop counter, then you have to remember to explicitly pass it by value to an inner closure. That last one in particular bites me all the time -- JSLint at least warns you about the first one.
- grannyg00se 15y ago
  It doesn't though. Because how are you ggoing to know that they operate that way? You will have to learn that somehow. And you couldve just as easily learned how var works instead. What's worse.... now you still need to learn how var works anyway! It isn't gone. I see 0 reduction in confusion and +3 increase in cognitive load.
  - agscala 15y ago
    I understand what you're saying, but I'm under the impression that once these new keywords are introduced, everyone will encouraged to use 'let' exclusively and 'var' will be suggested as an advanced feature for special cases.
elehack 15y ago
JavaScript's 'var' behavior is a bug codified in specification. It is counter to pretty much any other C-style language; the difference is particularly acute because it breaks closures. So while other languages (e.g. C) could optimize their variable implementation to be like JavaScript's and still make sense, the fact that JS has closures means this breakage becomes visible on a routine basis. However, they cannot change var's semantics and retain backwards compatibility. So they did the next best thing: introduce a new keyword for variables that work like they should. That keyword is 'let'. As far as I am concerned, if your JS is known to execute in an environment with 'let', 'var' might as well not exist. Too many subtle errors — “what do you mean, braces don't actually delimit scope?”
- grannyg00se 15y ago
  If var is counter to other C-style languages, that doesn't make it a bug. It just makes it unique. Is there some other reason you're saying it is a bug? How does it break closures? Javascript works with var today and closures are used all the time. Breakage free. "what do you mean, braces don't actually delimit scope?" I would answer, they don't. Because this is not <insert your favourite braces-delimit-scope language>. This is javascript. Nobody should have ever told you that braces delimit scope here. It's not like this is some extremely rare issue that you aren't going to find documentation for. A quick run through a basic tutorial would suffice. So how is it that 'let' works the way variables should? It works differently, that's all. So now you have to know how let is different from var, why it was introduced, when to use let, when to use var, etc. Then when you see code using let, you're going to have to determine whether the person used it because they know what they are doing, or because someone just told them "let is the new var" and they use it all the time. Same for var. There is an added level of uncertainty when reading code. And and added level of complexity in explaining the language. You haven't gotten away from explaining how var works. Because you're still going to see tons of code using it. Wouldn't it be easier to just learn how to use var properly?
  - silentOpen 15y ago
    I don't want leg braces! Wouldn't it be easier to just learn how to use a wheelchair properly?

agscala 15y ago

The extra keywords aren't going to reduce the "errors and weird behavior", the fact that they will be block-scoped and not function-scoped is what will eliminate the confusion.

ams6110 15y ago
I agree with geuis above, JavaScript scope is simple to understand now. There is global scope, and there is function scope. That's it. And there's a certain elegance to that.
- wingo 15y ago
  There are more scopes than that: free variables versus locals; eval-introduced bindings; "with"; the exception identifier in "catch"; the function name in named function expressions; argument names; etc. And the scoping rules are quite tricky in practice, to real programmers. To take an example from today: https://bugs.webkit.org/show_bug.cgi?id=27226#c4 https://bugs.webkit.org/show_bug.cgi?id=27226#c4
  - grannyg00se 15y ago
    Looking at that example, I would ask ....where exactly is that function definition getting defined? Why would you put a function definition inside a catch block? Do you think it's getting defined when the catch block is called? Are you programming in Javascript, or are you just writing javascript the way you would write code in some other language?
    - sirclueless 15y ago
      It's a pretty straightforward use-case: you have a function that returns a function, and in the case of an internal error, you want the returned function to have a reference to the error object. And the only reliable way to do that is to declare a variable with function scope, declare a function in function scope, and conditionally return this function? That's absurdly broken. As for variable scoping rules, if you have never been bitten by loop counters being used improperly, then I assert that you haven't programmed enough javascript. There are so many ways to mess this up: forget a var declaration and it leaks scope -- and since you can only declare it once, you can't just always use "for (var i = ...". If you want to defer access to a loop counter, then you have to remember to explicitly pass it by value to an inner closure. That last one in particular bites me all the time -- JSLint at least warns you about the first one.
grannyg00se 15y ago
It doesn't though. Because how are you ggoing to know that they operate that way? You will have to learn that somehow. And you couldve just as easily learned how var works instead. What's worse.... now you still need to learn how var works anyway! It isn't gone. I see 0 reduction in confusion and +3 increase in cognitive load.
- agscala 15y ago
  I understand what you're saying, but I'm under the impression that once these new keywords are introduced, everyone will encouraged to use 'let' exclusively and 'var' will be suggested as an advanced feature for special cases.

elehack 15y ago

JavaScript's 'var' behavior is a bug codified in specification. It is counter to pretty much any other C-style language; the difference is particularly acute because it breaks closures. So while other languages (e.g. C) could optimize their variable implementation to be like JavaScript's and still make sense, the fact that JS has closures means this breakage becomes visible on a routine basis. However, they cannot change var's semantics and retain backwards compatibility. So they did the next best thing: introduce a new keyword for variables that work like they should. That keyword is 'let'. As far as I am concerned, if your JS is known to execute in an environment with 'let', 'var' might as well not exist. Too many subtle errors — “what do you mean, braces don't actually delimit scope?”

grannyg00se 15y ago
If var is counter to other C-style languages, that doesn't make it a bug. It just makes it unique. Is there some other reason you're saying it is a bug? How does it break closures? Javascript works with var today and closures are used all the time. Breakage free. "what do you mean, braces don't actually delimit scope?" I would answer, they don't. Because this is not <insert your favourite braces-delimit-scope language>. This is javascript. Nobody should have ever told you that braces delimit scope here. It's not like this is some extremely rare issue that you aren't going to find documentation for. A quick run through a basic tutorial would suffice. So how is it that 'let' works the way variables should? It works differently, that's all. So now you have to know how let is different from var, why it was introduced, when to use let, when to use var, etc. Then when you see code using let, you're going to have to determine whether the person used it because they know what they are doing, or because someone just told them "let is the new var" and they use it all the time. Same for var. There is an added level of uncertainty when reading code. And and added level of complexity in explaining the language. You haven't gotten away from explaining how var works. Because you're still going to see tons of code using it. Wouldn't it be easier to just learn how to use var properly?
- silentOpen 15y ago
  I don't want leg braces! Wouldn't it be easier to just learn how to use a wheelchair properly?