Well, since we’re already talking about CS, we might ask whether computer scientists—who, as I mention above, must confront similar problems—have come up with any solutions. And it turns out that they have: namespaces.

For example:

int foo::bar = 5;

function baz() {
    int bar = 10;
    print(bar);
    print(foo::bar);
}

That’s a lot more clear. But it might get cumbersome to type out foo:: every time, yes? And so:

using namespace foo;

int bar = 5;

function baz() {
    int not_foo::bar = 10;
    print(bar);
    // The above line is equivalent to this one:
    print(foo::bar);

    // And this is something else, of course:
    print(not_foo::bar);
}

Not bad!

Of course, it might also occur to us to wonder whether this “namespace” idea has any analogues outside of computer science—has anyone else, by chance, happened to stumble on this solution? And it turns out that the answer is “yes”, and that said solution is all around us: jargon.

After all, a word like—oh, let’s say… “function”—means something different, and much more specific, in computer science, than it does in everyday parlance. The way we deal with this is simple enough: we make it clear, in any given conversational context, that we’re defaulting to some namespace—that is, using some body of jargon—and all ambiguous terms are then interpreted, by default, as having the meanings that they have in that body of jargon. (For example, in this conversation, we’ve established—implicitly, but no less clearly despite that—that we’re talking computer science; we’ve done the equivalent of a statement like using namespace ComputerScience. Thus when I say “scope”, you know that I mean this, and not this—unless, of course, I specify otherwise, in any given sentence.)

It is no coincidence that namespaces do not generate nearly as much confusion, for programmers, as variable scope does.

Of course, namespaces are less flexible than scoping. But I ask again whether anyone here thinks that it’s a good idea to make all of our conversations, on any topic as complex, and as cognitively demanding, as computer programming. Consider the price of the flexibility you wish for.

Do you really want to introduce this sort of complexity into every topic we discuss? Will this really make our discussions more comprehensible?

Well, yes, definitely yes!

To me, it is obvious that increasing the cognitive complexity of our conversations is something which ought to be done with only the greatest of consideration and necessity, and at each moment we should take the utmost care to add only the necessary amount of complexity, and no more. What you propose would seem to add a lot of cognitive complexity, for questionable benefit.

Hardly any programmer today would argue that we should use only global variables to escape the confusion of scope. Far sooner would a programmer tell you to never declare globals at all, and stick to local scope. Scope is just so convenient. We should avoid practices which make understanding scope difficult, like the examples you mention, but that is a matter of good style. Scope itself is invaluable.

Well, making the “argument from current programming practices”, as it were, is perilous, because many current programming practices are deeply misguided and have fundamental and far-ranging problematic effects.

You might guess, from the above line, that I’m making a fairly trivial point about passing fads in technology (to be followed up, perhaps, by a jab at Scrum). I’m not. The issue at hand is this: programming is extremely complex. It is growing more so, by the year and by the month. To say that not every person possesses the cognitive capacity to hold such vastly complex abstract structures in their mind, and to comprehend their workings, is to vastly understate the matter.

Scope helps, yes. But scope is more confusing than namespaces, and namespaces are more confusing than simple globals (i.e., a single global namespace). These things are necessary because our code is so complex. They are not themselves an improvement in terms of comprehensibility. A much simpler code base, in a much simpler language, can and should use globals. It’s easier.

You propose to greatly increase the complexity of our conversations, and then, to manage that complexity, to introduce all the vagaries of variable scope. I say: take two steps back. Curb the complexity, and relieve yourself of the need for lexical scope.

my straw man of you is that you’re suggesting that any word which is in common usage should stick to meaning what it means in common usage, unless there is an already defined technical usage, in which case it is acceptable to reference that.

That’s pretty close to my actual position. I would add that it is also acceptable to, essentially, create a new namespace—in other words, to formulate a new set of jargon, and then use it in all discussions of the topic. (This, for example, is more or less what Eliezer did, when writing the Sequences.)

This seems a bit absurd to me because it ignores where common usage comes from: people using words in the most useful ways they can, based in part on their expectations of what other people will understand them as meaning, but accounting for the needs and constraints of the conversational context.

Yes, except that in practice, this is very close to “use words as they are already known to be defined” (i.e., following existing common usage / accepted meaning), and very far from “make up entirely new definitions in each conversational context”.

The straw-man position imagines that language is defined by dictionaries and perhaps by phd’ed scientists writing peer reviewed papers, and everyone else has to do what those people say.

Well, this is wrong even in terms of the straw-man view (much less my actual view). I think you might’ve gone too far in your strawmanning, here. Again, “common usage” doesn’t mean “anyone defines anything however they like, in ‘local scope’”.

Further, and most importantly (since I am not advocating truly arbitrary redefinitions of words in contexts, but rather, sensible redefinitions), I’m taking you to be thinking that it is bad to use “x” for something that is sort of like a horizontal axis, but not quite. (IE, using traditional variable names outside of the traditional context because the new context reminds you of the traditional one.)

As clone of saturn points out, this is indeed problematic. Have you any idea how many people, in the rationalist community, even on LessWrong, at this very moment hold confused ideas about utilitarianism, the VNM theorem, and the ways in which they are related (i.e.: not at all), merely because the word “utility” is involved in both?

But however bad it is to redefine some existing word (especially if the meaning of that word is in any way subtle, complex, or poorly-understood), it is ten—nay, a hundred—times worse to redefine said word in one way today, and in a different way tomorrow! And if your definition of today is different but similar to your definition of tomorrow, and if any part of your points hinge on the difference, or are materially affected by the difference, then may Bayes have mercy on your soul, because you are an unrepentant sinner against clarity of thought and word.