the python name
DL Neil
PythonList at DancesWithMice.info
Mon Jan 7 15:07:18 EST 2019
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
More information about the Python-list
mailing list