On Thu, 08 May 2014 14:50:08 -0700, Ethan Furman wrote: > I guess my point is, calling aliases variables wasn't the misleading > part, it was my lack of knowledge that there was more than one kind of > variable possible. Such ignorance is only solved by learning different > languages,
The *only* way? I'm feeling kind of ignored and unloved here... *wink* As I've said multiple times now, my personal experience is that "such ignorance" of different variable semantics can also be solved by explicitly rejecting the use of the term "variable". Let me put it this way: both horse-drawn carriages and cars are examples of the same general concept. "Horse-drawn carriage" is a back-formation from the time when people wished to distinguish carriages with horses from horseless carriages. Today we routinely call horseless carriages "cars", and nobody would blink if I pointed at a Prius or a Ford Explorer and said "that's not a carriage, it's a car" except to wonder why on earth I thought something so obvious needed to be said. And yet the majority view expressed on this thread is that somehow programmers are allegedly confused and distressed by the use of distinct terminology for different kinds of variable name-value bindings. Programmers tend to be more intelligent than average, they tend to know dozens or hundreds of very technical terms differing only in fine degrees of detail (I'm still not sure what the difference, if any, between *delegation* and *composition* is, or between the ever more specialist adaptor design patterns). We expect newbie programmers to learn all sorts of jargon: functions, factories, methods, class methods, static methods, types, decorators, descriptors, trampolines, threads, namespaces, mutable, immutable, properties... and yet distinguishing "variable" from "name binding" is supposed to cause more harm than good? I remain unconvinced. > and isn't aided if every language has their own unique terminology. Nobody is talking about giving every language their own unique terminology. There are, so far as I know, two general models of computational variables: the name binding in a dynamic namespace model and the static memory location model. Different languages may implement slight variations on these, for example CPython uses fixed memory locations for local variables of functions as an optimization, Java uses name binding except for unboxed native data types, traditionally Forth doesn't use fixed memory locations but a threaded list, but the basic dichotomy is very common. So to a first approximation, most languages fall fully or mostly within one of two categories: they have name bindings, or C-style variables. Name binding is even a standard computer science term: https://en.wikipedia.org/wiki/Name_binding The pedantic reader will notice that "name binding" equally applies to the C compiler associating a name with a fixed memory location at compile time ("early binding") as the Python virtual machine associating a value with a key in a namespace at run time ("late binding"). Nevertheless, for a generation of programmers raised on C, "variable" means what C does. The whole point is not that "name binding" somehow causes the reader to intuit the differences between early and late binding, or between boxes in fixed memory locations and name:value pairs in a namespace, but that it *opens their mind* to the possibility that they are using the wrong mental model. It is the start of the dialog, not the end. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
