The “does Python have variables?” debate

[Steven D'Aprano]

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/