How necessary are var, let, and const?

http://raganwald.com/2015/05/30/de-stijl.html

by tbassetto • 11 years ago

89 82 11 years ago

bmeck3• 11 years ago

const can be used to denote that a reference to the variable is being passed around and should not change for the lifetime of a scope.

    function f() {
      const queue = [];
      consumer(queue);
      return queue;
    }

It could be important to note that removing const has benign effect, but that it is there to ensure a programmer does not change the value of queue between `consumer(queue)` and `return queue`. Easily reasoned about, but extra safeguards from introducing bugs is always nice.

digi_owl• 11 years ago

I guess you can say that they are there to allow the compiler to check the intent of the programmer.

EugeneOZ2• 11 years ago

Ironically enough, but your example shows where const is shouldn't be used as guarantee of immutability: https://t.co/JIQozGe7Md

agumonkey2• 11 years ago

Isn't that a typical "corner case" in the understanding of dynamic languages bindings ? I think I've seen the same question pop about python. The array binding is constant, its content isn't.

bmeck3• 11 years ago

const is not about immutability in JS.

thomasfoster962• 11 years ago

I'm not sure I quite understand your point - while it's true that the variable called queue won't be reassigned, const would still allow elements and properties to be added to queue.

bmeck3• 11 years ago

const is not about immutability in JS.

rbalicki• 11 years ago

If we use the approach of converting var's to named parameters, we also have to give up on passing variable numbers of arguments to functions. That is, unless we do something silly like:

    function silly(x, y, z, args) {
      args = Array.prototype.slice.call(arguments);
      args.shift();
      args.shift();
      args.shift();
      args.shift();
      x = y = z = undefined;

      // regular function goes here
    }

shawndumas2• 11 years ago

The replacement of var or let was a thought experiment to show the actual value--in code--of using them.

shawndumas2• 11 years ago

To be fair; getting the benefit of const would require code too though:

  function constUseful () {
    var guarded = 1;

    (function loop (orgGuarded) {
      setTimeout(function () {
        if (guarded !== orgGuarded) {
          throw 'guarded reassigned!';
        }
        loop(orgGuarded);
      }, 0);
    })(guarded);

    guarded = 2;
  }

  constUseful();

That's an approximation of const's value as delineated in code.

bshimmin• 11 years ago

OK, I'll bite: what does De Stijl (http://en.wikipedia.org/wiki/De_Stijl) have to do with any of this?

braythwayt7• 11 years ago

Perhaps the question of whether `const` in a language that doesn't do much static type checking/analysis is a question of style, and not a clear across-the-board win.

gjm11• 11 years ago

It was a movement that attempted to achieve clarity and elegance by omitting the unnecessary -- and the article discusses whether omitting formally-unnecessary features like var or const makes for more clarity and elegance, or less.

(Having said which, I notice that there's a reply from the person who actually wrote the article, and it doesn't say that. But that's why he should have made the reference :-).)

braythwayt7• 11 years ago

I might have said that, but then I would be omitting the fact that not everyone finds my reproduction of the red-=blue chair comfortable.

Scheme vs. Common Lisp, and all that.

pm246017• 11 years ago

const IS valuable and necessary.

1) It means that every place the const appears it can be replaced with the const's value. Type checking can be streamlined, less indirection.

2) It communicates the developer's INTENT in an enforced manner. No later code change can accidentally make the const suddenly non-const.

3) const + deep Object.freeze() makes for a complete const.

Sure a human could hypothetically scan the code to see that the value has not been reassigned. This falls apart in practice. As soon as the company has a few dozen developers the code is constantly changing and such manual analysis would have to be constantly done.

titzer2• 11 years ago

1.) is simply wrong. Const variables have a live-range hole where access to the variable either throws or returns undefined, depending on the language mode (and the VM!). In either case it not legal to just smash in the constant.

2.) That's nice but JS semantics do not actually hold up. The intent is for a constant, the reality is there is a small window where the wrong results can be observed. Engines don't actually do any more optimizations than for var or let; in fact, your code may actually be slower due to the live-range hole checks.

pm246017• 11 years ago

So you are saying that there are race conditions currently? Are any of this race conditions actually required by the language spec? If not, I suspect that those race conditions will be eliminated.

rescendent• 11 years ago

Consts have other purposes: Speeding up global constants using fixed field optimization https://blogs.windows.com/msedgedev/2015/05/20/delivering-fa...

braythwayt7• 11 years ago

3) const + deep Object.freeze() makes for a complete const.

The trouble with this approach is that runtime checks are only a guarantee that the code you've _exercised_ does not break the contract.

In that respect, `const` is deeply different than `.freeze`, in the same way that runtime assertions are deeply different than type checking.

pm246017• 11 years ago

Huh? That's why I pointed out the joint usage. And either way, a instant failure is better than a silent change.

catshirt2• 11 years ago

isn't 2 kind of a misdirected optimization for an untyped language?

pm246017• 11 years ago

How is INTENT of immutability ( and with const - now an enforced immutability ) misdirected optimization in any language.

Javascript is dynamically weakly typed but it is still typed, typeof/instanceof exist for a reason.

jonny_eh• 11 years ago

Aren't points 1 and 2 just arguments for a stricly typed language?

pm246017• 11 years ago

Not at all. Simple things like instanceof / typeof checks can be resolved without a static type system. Because with a const everything is known about the const in question. Obviously the const prototype may change but then again if the const has a frozen prototype - that too can have static analysis applied to it.

I am simply repeating the well-known benefits to immutables which is completely orthogonal to a type system, static or otherwise.

ylg• 11 years ago

Interesting and well written; if it were me, I might only change the ending a bit:

"Whereas, const […]. It is not nearly as useful as immutable data, because the problem it solves is easy, not hard."

To something like:

"const may be more useful than adding something like immutable data to an imperative language with mutability deep in its DNA might be because it helps with one of the hardest problems; long-term, correct re-reading by humans doing maintenance or extension."

But, the OP covers that well earlier in, so I'm not sure a third take on it would add much. Thanks for doing the exploration!

protonfish2• 11 years ago

A better question is how useful is let at all? Having two different variable scoping rules with no way to know which one a variable is using without backtracing sounds like a maintenance nightmare. I understand what is it good for, but it seems like we are replacing a small problem with a bigger problem.

An even better question is why not get rid of var and make every variable local to its parent function? To alter globals, use the window object explicitly.

serve_yay5• 11 years ago

better question is how useful is let at all? Having two different variable scoping rules with no way to know which one a variable is using with backtracing sounds like a maintenance nightmare.

I agree, but I think the solution is to stop using `var`, the question is how useful `var` really is. `let`'s scoping is what it appears to be, `var`'s is not. So `let` is the better choice.

protonfish2• 11 years ago

I disagree. Maybe you think this because you are used to another language, but once you get how var works, it's quite clear. Just because some other language does it, does not mean it is unquestionably good.

hrjet• 11 years ago

To alter globals, use the window object explicitly.

JS is used in non-DOM contexts as well. Though, of course, if that big a change is being made, a generic substitute for `window` could also be specified.

reubenmorais• 11 years ago

a generic substitute for `window` could also be specified

Isn't that just |this| at the top level?

untog• 11 years ago

I think the answer is to just use let. In an ideal world they'd just change the behaviour of var to something sensible, but they (wisely) wanted to retain backwards compatibility.

const is a different case, but IMO there's no need to use var when let exists.

serve_yay5• 11 years ago

Can you eliminate `var` by introducing an unnecessary function, declaring the `var`s as parameters, and then invoking? Yes you can.

Why you would ever do that, however...

tperson• 11 years ago

This was my thoughts exactly. I stopped reading after that section. I don't understand what the author is trying to do.

moogly• 11 years ago

I found this article's premises and findings rather pointless, and kept on wanting the author to instead verify the premise "are there actually valid uses of 'var' now that 'let' exists?" (I haven't found any yet, and I'd like to know if I'm wrong). But maybe I'm too much of a pragmatist rather than an academic, so I suppose it wasn't written for me.

serve_yay5• 11 years ago

Yes! Thank you. I agree the question is as you pose it -- why use `var`, ever?

Animats• 11 years ago

"let", of course, is a retrofit to Javascript. So was "var". In the early days of Javascript, before "strict mode", few people declared anything and most variables had global scope.

It's really hard to get a declaration-free language right. Python was the biggest success to date.

jsnoble• 11 years ago

Before ES6 im curious did you always need blocked scoped variables? Of course we used iife's when we needed to but how often did we need to do that compared to the times we used regular variables. Is it always worth the extra overhead to enforce everything being blocked scoped? What about times that we needed to alter something outside the scope? whether or not thats always a good idea is another discussion but there are valid uses. I remember people were getting all worked up over functional expressions vs declarations saying expressions were 'the one true way' since it more closely resemebles how the compiler reads it. As babel shows let and const are just var's with extra overhead. Dont get me wrong let and const are in the right direction but they are not 'the one true way'

aikah• 11 years ago

let is obviously needed(devs like lexical scoping) but I found the whole var + let in the same language thing a bit confusing. The temptation to introduce yet another strict mode(to forbid var,and a few other constructs) is strong on this one.

braythwayt7• 11 years ago

var vs. let in the same language is a consequence of designing the language by committee, requiring 100% backwards-compatibility, and forbidding the addition of new modes (which is a back-door way to introduce breaking changes, while requiring browser vendors to essentially support multiple versions).

sebleblanc• 11 years ago

That behaviour is not exclusive to standards committees. The government and private companies do it all the time.

sesutton• 11 years ago

The temptation to introduce yet another strict mode(to forbid var,and a few other constructs) is strong on this one.

There is a proposal for that, coincidentally called "strong mode".

https://docs.google.com/document/d/1Qk0qC4s_XNCLemj42FqfsRLp...

seasoup• 11 years ago

That is not at all obvious to many long time JavaScript engineers. Having a variable scoped by block or by function works for me, having both in the language is a pain. I have seen some neat tricks that you can do with let in for loops, but nothing that has convinced me it's worth the cognitive overhead of figuring out is this variable a var or a let.

My opinion is that if you use let, don't use var, and if you use var, don't use let. Either one on its own is fine, together they are just a mess.

rashkov• 11 years ago

Could anyone please explain to me why the author chose those functions for his examples? I got as far as callFirst() and repeat() and found it hard enough to wrap my mind around the functional / meta programming within. Are those actually good examples? It seems like there are simpler ways to illustrate the point.

fenomas• 11 years ago

If you check out Javascript Allonge (linked on the page, web version is free) you'll find out. The author has written a lot about functional programming, combinators and so on in JS.

I think his point was simply that examining how to emulate let/var with closures, it shows you explicitly what is different/similar about them. He's not suggesting anyone use those transforms.

pc2g4d• 11 years ago

Does anyone else out there think Javascript `const` should really be called `final`? It more closely mimics Java's `final` keyword by preventing reassignment ("rebinding") of the variable, whereas `const` makes me think of full immutability as in C++.

btbuildem• 11 years ago

That disclaimer is a bit of a cop-out, given the subject matter..

magice• 11 years ago

Hmm, posts like this make me want to make Lisp mandatory for all programmers. Given that LISPers have argued for "lambda the ultimate kitchen utensil/sinks/cooks" for the last few decades, it's slightly annoying that people from other languages repeat the point now. That said, congratulation for learning value of syntactical sugar. I hope you like it.

That said, can somebody implement hygienic macros in JavaScript. They will probably help will people having to explain basics knowledge over and over.

braythwayt7• 11 years ago

FWIW, I learned Scheme in the mid 1980s, loooooong before I'd ever heard of JavaScript.

Aloisius• 11 years ago

Given that LISPers have argued for "lambda the ultimate kitchen utensil/sinks/cooks" for the last few decades, it's slightly annoying that people from other languages repeat the point now.

Personally I find excessive use of lamdas create unmaintainable and incredibly difficult to debug spaghetti code. The idea that JS developers should make their code even more LISP-like is enough to give me nightmares.

braythwayt7• 11 years ago

"I used to brag that I could 'write Lisp in any language.' But Lispers doubted that I could, and everyone else feared that I would."

JadeNB2• 11 years ago

Given that LISPers have argued for "lambda the ultimate kitchen utensil/sinks/cooks" for the last few decades, it's slightly annoying that people from other languages repeat the point now.

Why? Are you also annoyed by calculus students who learn ideas today that have been known for hundreds of years?

That said, congratulation for learning value of syntactical sugar. I hope you like it.

Maybe I am misreading this (it could mean simply what it literally says), but I read it as unconstructive snark.

kbenson• 11 years ago

I suspect that if mathematicians who were creating alternate number systems without calculus were continually learning the usefulness of calculus and telling the world, then yes, those who advised its inclusion for years would be annoyed, if only because it took so damn long and so much time was wasted.

davexunit• 11 years ago

Agreed. If JavaScript only had a hygienic macro system I could have written 'let' (and a whole bunch of other forms) for myself a long time ago.

rayiner2• 11 years ago

What gets me is that there are languages in 2015 that don't get lexical scoping right. It has been a solved problem for 40 years now.

pcwalton• 11 years ago

Saying that it's 2015 is a bit misleading. In JS's case, it's mostly a question of backwards compatibility and interactions with those backwards-compatible features.

The designers of let are largely a bunch of Schemers; they knew what they were doing.

greghendershott• 11 years ago

That said, can somebody implement hygienic macros in JavaScript.

Although I haven't used it hands-on, http://sweetjs.org/ looks impressive.

For example recently sweet.js apparently implemented some cutting-edge Racket macro developments before Racket officially did. :) https://github.com/mozilla/sweet.js/pull/461

riffraff2• 11 years ago

You can see every single rebinding of a variable within the lexical scope of the function,

I do not think that is true, a called function can side effect the caller environment via `arguments` if that is passed around.

braythwayt7• 11 years ago

My understanding is that arguments caller has been removed, and Function.prototype.caller is non-standard:

  > The obsolete `arguments.caller` property used to provide the
  > function that invoked the currently executing function. This
  > property has been removed and no longer works.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Can you provide an example of modifying a declared variable in a calling environment? I'm very interested!

riffraff2• 11 years ago

I meant this:

    function sidEffecting(ary) {
      ary[0] = ary[2];
    }
    function bar(a,b,c) {
      c = 10
      sidEffecting(arguments);
      return a + b + c;
    }
    bar(1,1,1) // I expect 12, but is 21

I now realize this could actually be not allowed anymore in recent ES, I am not sure, but copy & paste in chrome console still prints 21.

How necessary are var, let, and const?

Related Stories