"Goto" statement in Python

[Steve D'Aprano]

On Fri, 14 Apr 2017 12:52 am, bartc wrote:

> I know this isn't the Python need-for-speed thread, but this is a
> classic example where the lack of one simple feature leads to using
> slower, more cumbersome ones.

Dear gods, have I fallen back in time to 1975 again?

The Goto Wars are over, and the structured programming camp won the war
decisively.

Are functions/procedures *technically* slower than GOTOs? Yes. So what?
You're nano-optimizing the wrong thing: you're saving a microsecond of
runtime at the cost of a megasecond of development and maintenance time.

At the point that you say "Function calls ... are rather more heavyweight"
the whole argument becomes farcical. Function calls are so prevalent in
modern structured programming (whether you write in procedural, functional
or object-oriented style, or a combination of all three) that saving one or
two function calls isn't even a micro-optimization, especially not in a
high-level language.

To save any meaningful time, you would need to return to the bad-old-days of
unmaintainable unstructured spaghetti code.

This debate about the usefulness of GOTO in modern languages reminds me of
the sort of people who will drive around the city for an hour looking to
save 0.1 cent on the cost of petrol (gasoline for Americans).


> 'goto' would be one easy-to-execute byte-code; no variables, objects or
> types to worry about. If implemented properly (with the byte-code
> compiler using a dedicated name-space for labels) there would be no name
> lookups.

I don't care much about the implementation of GOTO. I care a lot about the
code written that includes GOTOs.

Are there reasonable uses for GOTO? Perhaps. There are semi-structured
restricted versions of GOTO, like exceptions, break and return, but an
unrestricted GOTO where you can jump anywhere in the program is a terrible
feature for anything but the smallest, most trivial programs. To be even
*close* to safe, you have to restrict GOTO considerably. At the very
minimum, you need two restrictions:

- cannot jump into the middle of a procedure or function;

- cannot jump immediately out of a procedure or function without 
  cleaning up the stack and other handling.


Even that's not enough for some. Donald Knuth, who supports the use of GOTO
under some circumstances, maintains that any program using GOTOs should
have the invariant that its flow chart can be drawn with all forward
branches on the left, all backward branches on the right, and no branches
crossing each other.

Features should not be judged solely on their usefulness to the best 1% of
programmers using the feature in the best possible way. You also need to
consider the lesser mortals, the below-average 50% of programmers who will
use the feature in sub-optimal if not outright terrible ways.

GOTOs are far to easy to abuse. The harm that they do is outweighed a
thousand times by the rare positive use. Most languages do well to avoid
GOTO, even if that means that there are one or two rare uses that have to
be written slightly sub-optimally for the lack.


> Function calls, returns and generators are rather more heavyweight in
> comparison.

And enormously better.




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