Hacker News Reader

Comment by braythwayt | Hacker News Reader

  > It's easier to reason about a variable if you know it will always be one value—even
  > if the value may be mutated (which is unfortunate).

True, but because const, let, and var are lexically-scoped, it’s super-easy to reason about everything that happens to variables. (Excepting bad JS environments where you can declare global constants, of course).

If I see PI = 3.14159265 somewhere in a file, it’s not a hardship to assume it will not be rebound, and to notice if it is rebound.

The super-important thing to reason about is value mutability, because that escapes lexical scope. We pass mutable values to library functions containing code we have never read. We integrate with code written by a colleague who is in another time zone and may accidentally change a routine to mutate an array we pass with .push instead of .concat.

“Easier to reason about” is massively important with mutability. Not so much with lexical bindings.

View on HN

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.

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; }

???

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?

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.

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?)

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() {};

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.

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 = ...`.

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.

That's how I write my JS as well. It's like speaking

Actually, I believe arrow functions keep the name of the binding.

    const diameter = () => {};
    export const radius = () => {};

Could be wrong.

What you're thinking about in ES6 is called "function name inference" and only refers to certain forms, like this one, where the name -- PURELY FOR DEBUGGING -- can be inferred. Actually, it goes for all assignments, `var`, `let`, and `const`.

Otherwise, the arrow itself is anonymous and thus you don't have a name to make an inner self-reference with.

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; }

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.

Reply on news.ycombinator.com