the python name

[DL Neil]

On 7/01/19 9:09 AM, Avi Gross wrote:
> [Can we ever change the subject line?]
> {REAL SUBJECT: degrees of compilation.}
> Peter wrote:
> 
> "...
> Hoever, this is the Python list and one of the advantages of Python is that we don't have to compile our code. So we need a different excuse for fencing on office chairs ;-).
> ..."

You had time for that? We had to move to working on program-B whilst 
awaiting the compile-print-return of program-A - sometimes even 
system/application-B!

In some respects I think the imposed compartmentalisation of one's work 
was a positive aspect. We concentrated on ensuring that solid progress 
was made, run by run - whereas the ease and simplicity of making small 
changes (one after the other) can easily consume tracts of time. (at 
some risk) We would try to foresee problems, and ensure that the code 
would 'continue to work' rather than falling at the first hurdle. On the 
other hand, once the batch was "submitted", we could completely drop 
that program's concerns from our minds. At times a massive stress 
reduction (hence the sword play?), and a good way to approach the next 
task with a constructive (?and less-cluttered) mind.

YMMV!


> I won't share my own war stories of how to compile in what now seem primitive environments on overloaded machines where you often figured out your mistakes on paper before the compiler quit and showed you officially 😊

Ah yes, the ?good, old days when computers were powered by dinosaurs 
running in treadmills...

It wasn't that the machine was overloaded so much, more that the Ops 
staff were charged with 'making efficient use of the machine' - that is 
to say, the 40~45% of CPU time that IBM didn't take to run the OpSys. 
Accordingly, our batch-compile jobs went into a long queue, just so that 
the machine could attend to them when it had some 'spare' capacity.

Since then, Moore's law etc, the economics have changed and the cost of 
programmer time is prioritised over computing costs. This became a 
paradigm-shift for me, because my (?junior) colleagues enacted a 
philosophy of 'throw it at the machine and let the 
real-time/time-sharing mini-computer/PC test it for you' (if only). 
Initially this seemed a scandalous waste of resources, but was also 'the 
way of the future'.

However, with large programs and poor test methods, using the above 
'machine as tester' idea, the costs of running a series of 'long' tests 
with only minor changes between soon exposes economic limits! So, I've 
never quite lost that habit of <<<figured out your mistakes on paper 
before the compiler quit and showed you officially>>>. That said, the 
tenets of Test-driven development continue to erode my 
conservatism/appeal to my inherent laziness...

Conversely, I have been (admittedly, rather quickly) auditing a Coursera 
MOOC series (Python 3 Programming Specialisation = five courses, out of 
U.Mich). Without commenting on their pedagogical success or otherwise, I 
was struck by their presenting the idea of a 'paper computer'* - even 
having an 'intelligent text book' tool to demonstrate step-wise 
execution of code. (without having to introduce the complexities of a 
debugger) It is a good way to help new-comers understand the 
relationships between a variable's name, its value, its type, its 
mutability, etc, etc - which (IIRC) is where they introduced the idea. 
However, later lessons have included exhortations to review that new 
work, using the 'paper computer' technique.

* apologies: this is the term I learned (all those years ago, mumble, 
mumble) and I'm quite sure they have a different name. The essence is 
the same.

I'm only about 40% through the courses, and will be interested to see if 
they continue to refer to the technique as code-complexity builds...


-- 
Regards =dn