4 ms·

Totally agree, it is much more important to be able to reason about mutability. I would disagree that it's super-easy to reason about var, despite being lexica

Totally agree, it is much more important to be able to reason about mutability. I would disagree that it's super-easy to reason about var, despite being lexically scoped. It still causes an enormous amount of confusion when loops and callbacks are used together. The PI example only really works because we all know what PI should look like. If you were using someone else's constant value and it accidentally got rebound it would be much harder to know.

braythwayt 11y ago
Fair enough about var, it is annoying in ways that are orthogonal to rebindability (is that a word?) Also, here’s my question: If I can write: const PI = 3.14159265; Why can’t I write: const function diameter (r) { return 2 * PI * r; } ???
- megaman22 11y ago
  What is the goal of marking that function const? Is it to prevent redefining the function, or as a hint that it is a pure function and it's outputs can be memoized?
  - _getify 11y ago
    Yeah, see, this is exactly the problem. I think most developers assume the latter, when the former is all that's meant according to JS. I don't think the former is all that useful, and the latter is super useful but `const` doesn't do anything to help with that.
  - jdeisenberg 11y ago
    The fact that you can redefine a function gives me a terribly unsettled feeling, probably because I remember the assembly language days when we were told not to write self-modifying code, as it's not re-entrant. (If JS were ever in a concurrent environment, would re-defining functions lead to problems?)
- codecurve 11y ago
  Probably for the same reasons you can't write var function diameter() {} It's definitely a shame that the only way to achieve consistent behaviour between variables and named functions requires you to write the name twice. const diameter = function diameter() {}; If it wasn't for the usefulness of named functions for debugging and hoisting, I would just use: const diameter = function() {};
  - _getify 11y ago
    Except that any variation of these doesn't produce the same thing as a declaration, since function declarations hoist and function expression assignments do not. Most people don't like hoisting -- and I agree that variable hoisting is crazy. I'd never advocate this: a = 2; var a; But function hoisting I find super useful. I always prefer to write my files like this: foo(); bar(); // .... function foo() { .. } function bar() { .. } ...because when I open a file, I don't want to go hunting for any executable code, I just want to look at the very top. Function declaration hoisting lets me put those definitions at the bottom and the code that uses them at the top. I've found this to be much more useful in code maintenance.
    - clessg 11y ago
      I agree on function declarations even though I avoid hoisting in other situations. I don't see any serious downsides to using function declarations (unless within a function, perhaps), and I find it easier to read, especially in ES6: `export function diameter` vs. `export const diameter = ...`.
    - mquander 11y ago
      If you just write everything in order of usage, the executable code still winds up in a very easy-to-find place -- the very bottom, rather than the top.
    - pixel67 11y ago
      That's how I write my JS as well. It's like speaking
  - 11y ago
- throwaway3453 11y ago
  What you have written is a function statement rather than a function expression. This is possible, but has no utility beyond the original. const diameter = function diameter (r) { return 2 * PI * r; }
  - braythwayt 11y ago
    As other comments have noted, I a speaking to the fact that you can’t make a function declaration while also specifying that the name is not to be re-bound within its scope. A function expression bound to a constant block-scoped variable does not have the exact same semantics.

braythwayt 11y ago

Fair enough about var, it is annoying in ways that are orthogonal to rebindability (is that a word?) Also, here’s my question: If I can write: const PI = 3.14159265; Why can’t I write: const function diameter (r) { return 2 * PI * r; } ???

megaman22 11y ago
What is the goal of marking that function const? Is it to prevent redefining the function, or as a hint that it is a pure function and it's outputs can be memoized?
- _getify 11y ago
  Yeah, see, this is exactly the problem. I think most developers assume the latter, when the former is all that's meant according to JS. I don't think the former is all that useful, and the latter is super useful but `const` doesn't do anything to help with that.
- jdeisenberg 11y ago
  The fact that you can redefine a function gives me a terribly unsettled feeling, probably because I remember the assembly language days when we were told not to write self-modifying code, as it's not re-entrant. (If JS were ever in a concurrent environment, would re-defining functions lead to problems?)
codecurve 11y ago
Probably for the same reasons you can't write var function diameter() {} It's definitely a shame that the only way to achieve consistent behaviour between variables and named functions requires you to write the name twice. const diameter = function diameter() {}; If it wasn't for the usefulness of named functions for debugging and hoisting, I would just use: const diameter = function() {};
- _getify 11y ago
  Except that any variation of these doesn't produce the same thing as a declaration, since function declarations hoist and function expression assignments do not. Most people don't like hoisting -- and I agree that variable hoisting is crazy. I'd never advocate this: a = 2; var a; But function hoisting I find super useful. I always prefer to write my files like this: foo(); bar(); // .... function foo() { .. } function bar() { .. } ...because when I open a file, I don't want to go hunting for any executable code, I just want to look at the very top. Function declaration hoisting lets me put those definitions at the bottom and the code that uses them at the top. I've found this to be much more useful in code maintenance.
  - clessg 11y ago
    I agree on function declarations even though I avoid hoisting in other situations. I don't see any serious downsides to using function declarations (unless within a function, perhaps), and I find it easier to read, especially in ES6: `export function diameter` vs. `export const diameter = ...`.
  - mquander 11y ago
    If you just write everything in order of usage, the executable code still winds up in a very easy-to-find place -- the very bottom, rather than the top.
  - pixel67 11y ago
    That's how I write my JS as well. It's like speaking
- 11y ago
throwaway3453 11y ago
What you have written is a function statement rather than a function expression. This is possible, but has no utility beyond the original. const diameter = function diameter (r) { return 2 * PI * r; }
- braythwayt 11y ago
  As other comments have noted, I a speaking to the fact that you can’t make a function declaration while also specifying that the name is not to be re-bound within its scope. A function expression bound to a constant block-scoped variable does not have the exact same semantics.