Short-circuit Logic

[Chris Angelico]

On Fri, May 31, 2013 at 5:22 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Thu, 30 May 2013 16:40:52 +0000, Steven D'Aprano wrote:
>
>> On Fri, 31 May 2013 01:56:09 +1000, Chris Angelico wrote:
>
>>> You're assuming you can casually hit Ctrl-C to stop an infinite loop,
>>> meaning that it's trivial. It's not. Not everything lets you do that;
>>> or possibly halting the process will halt far more than you intended.
>>> What if you're editing live code in something that's had uninterrupted
>>> uptime for over a year?
>>
>> Then more fool you for editing live code.
>
> Ouch! That came out much harsher than it sounded in my head :(
>
> Sorry Chris, that wasn't intended as a personal attack against you, just
> as a comment on the general inadvisability of modifying code on the fly
> while it is being run.

Apology accepted :)

You're right that, in theory, a staging area is a Good Thing. But it's
not always feasible. At work, we have a lot of Pike code that really
does keep running indefinitely (okay, we have yet to get anywhere near
a year's uptime for administrative reasons, but it'll be plausible
once we go live; the >1year figure came from one of my personal
projects). While all's going well, code changes follow a sane
progression:

dev -> alpha -> beta -> live

with testing at every stage. What happens when we get a problem,
though? Maybe some process is leaking resources, maybe we come under
some kind of crazy DOS attack, whatever. We need a solution, and we
need to not break things for the currently-connected clients. That
means editing the live code. Of course, there are *some* protections;
the new code won't be switched in unless it passes the compilation
phase (think "except ImportError: keep_existing_code", kinda), and
hopefully I would at least spin it up on my dev box before pushing it
to live, but even so, there's every possibility that there'll be a
specific case that I didn't think of - remembering that we're not
talking about iteration from constant to constant, but from variable
to constant or constant to variable or variable to variable. That's
why I would prefer, in language design, for a 'failed loop' to result
in no iterations than an infinite number of them. The infinite loop
might be easily caught on my dev test - but only if I pass the code
through that exact code path.

But to go back to your point about editing live code: You backed down
from the implication that it's *foolish*, but I would maintain it at a
weaker level. Editing code in a running process is a *rare* thing to
do. MOST programming is not done that way. It's like the old joke
about the car mechanic and the heart surgeon (see eg
http://www.medindia.net/jokes/viewjokes.asp?hid=200 if you haven't
heard it, and I will be spoiling the punch line in the next line or
so); most programmers are mechanics, shutting down the system to do
any work on it, but very occasionally there are times when you need to
do it with the engine running. It's like C compilers. Most of us never
write them, but a few people (relatively) actually need to drop to the
uber-low-level coding and think about how it all works in assembly
language. For everyone else, thinking about machine code is an utter
waste of time/effort, but that doesn't mean that it's folly for a
compiler writer. Does that make sense?

ChrisA