Grumpy-pants spoil-sport [was Re: [Tutor] beginning to code]

[Steve D'Aprano]

On Tue, 26 Sep 2017 02:54 am, Ned Batchelder wrote:
[...]

Heh, its hard to avoid getting sucked into the sinkhole of definitional debates,
isn't it? :-)

[...]
> But in this line:
> 
>  x = 2 + 2
> 
> You can say,
> 
>  the value of x is 4

If we're talking about the highest level abstraction level, namely the Python
code, that would be the right answer. Provided that we understand that as
short-hand for:

>  the value of x is an int object with a value of 4

However:

> or,
> 
>  the value of x is a reference to an int object with a value of 4,

while that's true from a certain perspective, it's not the high-level Python
perspective. Its that of the implementation.

It's a perfectly valid perspective, and its often not just useful but (almost)
necessary. Some behaviours of Python are difficult to understand unless we dip
down an abstraction level and look at the implementation.


> and in some ways, each of those is a correct statement. They are
> different perspectives on the same complicated abstract relationships
> inside your program.  Most of the disagreements in this thread stem from
> someone picking one of those three statements and insisting that it is
> *the* right statement, or from differing interpretations of words like
> value, reference, pointer, alias, etc.

This topic has been discussed a lot over the last few weeks/months, and that's
something I've  also said: it is useful if not necessary to discuss different
levels of abstractions, but one needs to be clear when you are doing so.

We all take verbal short-cuts from time to time, and I'll often use language
like

"evaluating the expression returns a reference (a pointer) to the object ..."

(language which Marko would, I think, agree with) if I feel it brings insight to
the question being discussed. From a purely pedantic point of view, I'll say
I'm slightly naughty to do so, because I'm crossing abstractions without being
explicit about it. "Explicit is better than implicit."

So we all do it. I have no problem with people taking short-cuts or crossing
abstractions and even mixing explanations from different levels, provided it
brings insight and clarity to the question rather than confusion.

Its better to be explicit about it when you do so ("under the hood, the
interpreter uses a pointer to the object...") but we're all only human and
sometimes we make implicit assumptions.

But I do have to wonder about people who insist on keeping an inflexible,
single-minded point of view even in the face of confusion. To use your analogy
from below, it is as if they were absolutely, categorically denying that
pressing the gas pedal (accelerator pedal) has anything to do with the car
moving, because its the engine that makes it move, and that's the only right
answer.

Its fine to discuss what happens in different abstraction layers, but be clear
about it when you do.


> Software gets complicated because it involves multiple levels of
> abstraction layered on top of each other.  We might as well be arguing
> like this:
> 
>      A: "The gas pedal makes the car go"
> 
>      B: "Nonsense! The gas pedal supplies fuel to the engine, it's the 
> engine that makes the car go"
[snip]

Indeed. 


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.