>>> The first example is not “terrible”

There are several examples in the blog, and only one is the first. It does not include the "terrible" descriptor after it. So your comment is kind of odd because it doesn't connect to the article at all.

If you mean the first example that's described as "terrible", that's the second example and it's the one with the leaking loop variable. It kind of is terrible, Python has the same problem (and many others, Python scoping rules are not good). C used to have that problem but they at least had the good sense to fix it.

> the difference between lexical scope and block scope

There isn't a difference between lexical scope and "block" scope. What I think you are referring to as "block" scope, is a subset of lexical scope. The difference between var and let/const is where the boundaries of the lexical scope is.

Ah, fair, I didn't actually pay attention to which example you were referring to. That example is specifically about `var` being terrible, not `let/const`.

I was really using your comment as a jumping off point for my rant.

I wouldn't describe `var` declarations as lexical, though. Sure, they have a lexical scope that they get hoisted up to cover, but hoisting is not "just lexical scope". It's unusual.

Actually, let/const do the opposite of adding flexibility. Simple example: if you have a REPL, it has to cheat (as in, violate the rules of the language) in order to do something sensible for let/const. Once you do `let x;`, you can never declare `x` in the REPL again. In fact, simple typing `console.log(v)` is ambiguous: will you enter `let v` some time in the future or not?

You can't monkey patch lexicals, that is much of their point. Any reference to a lexical variable is a fixed binding.

In practice, this comes up most often for me when I have a script that I want to reload: if there are any toplevel `let/const`, you can't do it. Even worse, `class C { ... }` is also a lexical binding that cannot be replaced or overridden. Personally, I normally use `var` exclusively at the toplevel, and `let/const` exclusively in any other scope. But `class` is painful -- for scripts that I really want to be able to reload, I use `var C = class { ... };` which is fugly but mostly works. And yet, I like lexical scoping anyway, and think it's worth the price. The price didn't have to be quite so high, is all. I would happily take the benefit of avoiding TDZ for the price of disabling hoisting in the specific situations where it no longer makes sense.

I agree that hoisting is a backwards compatibility thing. I just think that the minute optional lexical scoping entered the picture, hoisting no longer made sense. Either one is great, the combination is awful, but it's possible for them to coexist peacefully in a language if you forbid the problematic intersection. TDZ is a hack, a workaround, not peaceful coexistence. (TDZ is basically the same fix as I'm proposing, just done dynamically instead of statically. Which means that JS's static semantics depend on dynamic behavior, when the whole point of lexical scoping is that it's lexical.)

None of the things you mentioned are clearly related to each other. “It basically means you can always override anything, which allows for monkey patching and proxying and adapter patterns and circular imports” is not true. “They’re the reason why JavaScript can have multiple versions of the same package while Python cannot” is definitely not true. (I’m not even sure if you’re referring to TDZ or hoisting or lexical scope or whatever other part of the context, but these things are unrelated to every option.)

The premise of “a language like Python that works as you describe” is wrong too, since Python doesn’t work like that (it has the same hoisting and TDZ concepts as JavaScript):

  def g():
      def f():
          return x
  
      x = 4
      return f()
  
  print(g())  # 4

Yes, because those don't capture any lexicals, so they're hoisted as usual.

My solution would only stop hoisting closures that capture lexicals, with the idea that capturing a lexical means that the closure's identity is now tied to that lexical environment anyway so it's kind of bizarre to hoist it out to where part of its identity is missing.

But you were giving a simplified example, so I want to be sure I'm not dismissing your concern unfairly. This would not work:

    function f() {
        return g(); // ReferenceError
    }
    let x = 4;
    function g() {
        return x + f();
    }

    let x = 4;
    function f() {
        return x + g(); // ReferenceError? Unfortunate if so...
    }
    function g() {
        return x - f();
    }

    let x = f(); // ReferenceError
    let y = 2;
    function f() {
        return y;
    }

    let x = 4;
    let function f() {
        return x + g();
    }
    let function g() {
        return x - f();
    }

It would work just like Lua then and require manually hoisting one of the declarations:

  local b
  local function a()
    return b()
  end
  b = function()
    return a()
  end

GCed languages often also have a mechanism for running code on scope exit. For example Lua's <close> attribute, which runs a metamethod when it goes out of scope rather than having to wait for GC:

  function readfile(name)
    local f <close> = assert(io.open(name))
    return assert(f:read"a")
  end