Lies in education [was Re: The "loop and a half"]

Steve D'Aprano steve+python at pearwood.info
Sat Oct 14 07:12:07 EDT 2017


On Sat, 14 Oct 2017 08:26 pm, Peter J. Holzer wrote:

> On 2017-10-14 01:05, Steve D'Aprano <steve+python at pearwood.info> wrote:

>> In context, we are talking about a computer program (the compiler) writing
>> data to memory.
> 
> No, I don't think so. You keep talking about that, even though Gregory
> hasn't used those exact words and has since clarfified that he didn't
> mean it that way.

But without clarifying what he meant. I've had to piece that together from
bits and pieces of random comments from other people. I still don't know
exactly what Greg intended to say, only what I have inferred.

Initially Greg said:

    "If the compiler can tell where p is initially pointing, it 
    could put the pointer in read-only memory."

and when I asked:

    "If it's read-only, how can the compiler write to it?"

instead of clarifying what he meant, Greg defended his misleading choice of
words with:

    "So, the factory is allowed to write to it. Possibly it's writing
    data that came from... a compiler?"

So Greg himself has used the term "write" to describe the scenario he
describes, it is not just me.

It has taken, what, I guess something like a dozen or more back and forward
posts before Chris happened to casually mention that the *program loader*
(not compiler!) writes the data to *write-protected memory* (not ROM).

If only people had said that in the first place, instead of reinforcing my
misunderstanding by arguing whether or not the act of etching paths into a
silicon chip at a factory counts as the compiler writing.

We're all human and we all sometimes use sloppy phrasing. I know I do. But the
least we can do is try to be more aware of when we're causing more confusion
than insight, and instead of doubling down and defending the sloppy phrasing,
try to explain what we mean.


> Y'know, I'm all for writing as carefully und 
> unambiguously as possible and for discussing questionable wording
> (especially in a large forum where many (including me) will have a
> different native language), but we all are sloppy in our writing every
> now and then and insisting that somebody must have meant X' because they
> wrote X doesn't really help and gets boring pretty soon.

The problem is not the initial miscommunication. The problem is the insistence
on defending that miscommunication even in the face of confusion.

Right from my first comment on this topic, I said:

    "I come from the days when ROM was actual ROM, burned in at
    the factory."

because I already suspected that Greg was using "read-only" to mean something
other than read-only, but what I did not know.

Now maybe I could have been more explicit by asking "What the hell do you mean
by read-only memory, if you're not talking about actual ROM?" and the fact
that I didn't is *my* failure. (Mea culpa.)

But be reasonable, I had just asked almost exactly the same question not one
line earlier:

    "If it's read-only, how can the compiler write to it?"

and (as far as I can see) *nobody* thought to actually answer my question
until perhaps a dozen posts later, when Chris more-or-less said:

- the compiler doesn't, but the program loader does;

- its not so much read-only memory as write-protected memory: 
  privileged code can still write to it.


(Have I got the details right? Or at least close enough?)


[...]
> Therefore I consider the phrasing "the
> compiler puts it into read-only memory", while certainly sloppy and not
> technically correct, perfectly comprehensible.

And here we go again. Instead of holding the author responsible for the poor
phrasing, the reader is blamed for not somehow inferring the author's
intended meaning.

"Somebody misunderstood Greg's sloppy and incorrect words to mean something
Greg didn't intend? And when given the opportunity to clarify, Greg failed to
do so and continued using the sloppy and incorrect phrasing? Oh, that's not
Greg's fault, it is the fault of the reader for not reading Greg's mind and
knowing what he really meant. I shall continue to defend the choice of words
which are LITERALLY WRONG rather than accept that somebody might have
legitimately misunderstood them."



> And I can't find anything 
> wrong with his revised phrasing "arrange for it to be in a location that
> is read-only at run time". That's exactly what the compiler does.

Except *read-only* is a misleading and poor way to describe it and it too is
LITERALLY WRONG. The program loader can write to it, and does so every single
time a program is run. Why is it called read-only when it isn't read-only or
even Write Once Read Many?

I am sure that nobody, including Greg and yourself, would describe /root on a
standard Linux/Unix system as "a read only directory" just because non-root
processes can't write to it. You'd probably describe it as write-protected,
or similar terminology.

And if somebody asked "How is it read-only, root can write to it?" I surely
hope you wouldn't double-down and insist that, no, it really, truly is
read-only even though root can write to it.

I don't know, maybe calling this chunk of memory "read-only" is the accepted
term of art for those who know about program loaders and the gory details of
how C compilers arrange memory and how code is run on x86 hardware. It
wouldn't be the first time that the terminology to describe some technology
was misleading to those who don't know the jargon, and I'm sure that it won't
be the last time.

But I'm not one of those people, and I'm sure that was obvious from my
questions. Is it really so hard to expect that somebody who did understand
what was going on to explain my misapprehension rather than argue over the
precise details of what counts as writing and whether or not a compiler can
be said to write to a silicon chip being manufactured in a factory half a
world away?

(By the way, thanks Chris.)


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




More information about the Python-list mailing list