About This: "We have to bind all over the place lest this change out from under us".
I wonder if there are other languages with similar peculiar behaviour of this.
It's dynamic scoping, as appose to lexical scoping. With the dynamic scoping, the environment of invocation becomes the caller's environment, while with the lexical scoping the environment was tied to the scope or original definition.
JavaScript is kinda weird because it uses lexical scoping for most of the part, but uses dynamic scoping for 'this'.
Lexical scoping looks sane, and it's adopted by most programming languages nowadays. Because it's much easier to reason about - it just worked as how the code was written, in the same file. While dynamic scoping would leak variables everywhere - when you need it it's not there, when you don't want it, it just sneakily replace many variables that you expect to be other things.
But there are still quite some mostly dynamically scoped languages in use like Emacs Lisp, or shell languages like Bash and Powershell. Other than dynamically is debatable faster and easier to implement, it's also handy when you override the environment variables for short shell scripts. But for large codebases it's a nightmare, so traditionally Emacs Lisp scripts have super-long-variable-names-in-order-to-avoid-collisions just like writing CSS, and people had enough now so in newest version people can have a syntax that can enable lexical scoping.
Common Lisp is interesting because it has both lexical and dynamic scoping. This is a quite useful feature as functions can override config variables. The only other language that provides this kind of configuration that I know of is Scala. Scala accomplishes this through implicits, instead of dynamic variables. Implicits are more flexible, but I think there's some good arguments to be made about careful use of dynamic scoping.
Dynamic scoping doesn't require long variable names. Having one namespace is what requires global variables to have reasonably long names.
Under dynamic scope you have the additional problem that a global name can be be overridden by accident by local names that clash with it.
Rather than trusting mere identifier length to address that problem, there is a namespacing convention to deal with it: putting "earmuff" asterisks on the names of global variables.
Namespace and lexical scoping can both solve the long variable name issue. If a language have none like Emacs Lisp or CSS, the issue happens.
For example, when there was no namespace for JavaScript, people can easily simulate modules/namespaces with lexical closures. For a lot (not all of course) of bundling systems, modules/namespaces are just syntactic sugars on top of lexical closure.
> so traditionally Emacs Lisp scripts have super-long-variable-names-in-order-to-avoid-collisions
I don't think dynamic scoping is the only reason for this. Scheme has lexical scoping yet long-identifier-names are popular with scheme as well.
Personally I prefer lexical scoping with long-identifier-names. I find it more pleasant to read. And with modern auto-completion systems, it's no longer inconvenient to write code like that.
Yes but for dynamically scoped languages you have to name it even longer.
Because in Scheme there are safe variables in closures so it can just named as <already-very-long-function-name>, while in Emacs Lisp it's literally leaking everywhere so it need to be <plugin-name>-<feature-name>-<sub-feature-name>-<repeat-the-feature-name-game-for-a-while>-<and-eventually-the-already-very-long-function-name> instead.
