Feedback wanted on programming introduction (Python in Windows)

[Alf P. Steinbach]

* Mensanator:
> On Oct 30, 2:07 pm, "Alf P. Steinbach" <al... at start.no> wrote:
>> * bartc:
>>
>>
>>
>>> Python has a lot of baggage which is OK if that's what's going to be
>>> used, but otherwise is unnecessary confusion: where to put the program
>>> code (typed in live or in a file, or some combination); whether to call
>>> the file .py or .pyw; the difference between console and graphical
>>> programs and so on.
>> Hi.
>>
>> I forgot or decided not to really answer this part earlier, so...
>>
>> First of all, note that nothing of this is specific to Python.
>>
>> (1)
>> "Where to put the program (typed in live or in a file)".
>>
>> This is common to all languages that offer interpreted execution.
>>
>> It is a feature, not a problem: in *addition* to putting your statements in a
>> file for later execution, i.e. in addition to creating ordinary programs, you
>> can explore the effects of statements by typing them at the interpreter.
>>
>> Storing the statements in a file is to create a "program" in the usual sense.
>>
>> Typing statements at the interpreter is just interactive use of the interpreter.
>> Depending on the phase of the moon, one's shoe size and other factors <g>,
>> what's typed may be called a "program". But it's not a program in the usual
>> sense, it's not a stored program: it's just interactive use of the interpreter.
> 
> Unless you type something like:
> 
>>>> def Collatz(n):
> 	while n>1:
> 		if n%2 == 0:
> 			n //= 2
> 		else:
> 			n = 3*n + 1
> 		print(n)
> 
> which *IS* a stored program. It's just stored in RAM and will
> be lost on shutdown if not specifically saved.
> 
> Even a single line is a "stored" program in the sense that you
> can put your cursor on the line and hit return to repeat the
> execution, so obviously, it's stored somewhere.

Yes.

As you quoted me on:

Depending on the phase of the moon, one's shoe size and other factors <g>, 
what's typed may be called a "program". But it's not a program in the usual 
sense, it's not a stored program: it's just interactive use of the interpreter.

However, at least for [comp.programming] the term "stored program" has a 
different often used meaning, the one that you employ above (which, by the way, 
was not von Neumann's invention, he was falsely credited with that idea).

And perhaps that needs to be pointed out when or if I discuss stored programs, 
like some kind of Wikipedia disambiguation page, so, thanks! :-)

But geneally getting into that kind of terminological fine distinction, such as 
here, what can be regarded as "stored", isn't really useful, though. It assumes 
an adversarial reading, which is not a useful assumption. And the only possible 
way out with that assumption is to define all relevant terms in a very technical 
way, which (1) leads to qualifications that end up being umpteen times longer 
than a simple statement of whatever one attempts to communicate (like, 
replicating all thousand+ pages of a technical language standard just to define 
the concept of "variable", which is silly), (2) leads to ungrokkable lawyereese 
language, absolutely not suitable for novices, and (3) in practice never 
actually accomplishes the purpose of ironclad definitions, as evidenced by e.g. 
"variable" in C++ still being subject to some disagreement over what it is...

I'm very very happy that most comments about perceived defects in the text and 
in my responses here, have only disagreements over terminology. I had expected a 
slew of errors being pointed out, since I'm new to Python. <g> Still, I'm fairly 
sure that there actually *is* such a slew of errors, because there is in any 
text of more than ten pages or so; any good book has a volumious errata list...


Cheers, & thanks,

- Alf