ExecutorService - goto in disguise?

[Arkadiusz Gasiński]

So I came across the "The Power and Practicality of Immutability
<https://www.youtube.com/watch?v=FQERMVABRrQ&t=620s>" presentation by
Venkat - I just wanted to find one of his talks where he says how shared
mutability is pure evil, and, surprise, surprise, there's also an analogy
to goto in that presentation (what a coincidence!). The analogy is:

"goto is to structured programming as assignment is to functional
> programming"


Besides now feeling sorry for goto and how it became the whipping boy for
all to punch left and right (yeah, some of the punches are justified, but
still), the point that Venkat makes is pretty much what you wrote,
Brian, which is "*goto is ok at some level*".

I'm now leaning towards rephrasing the subject of my mail to follow
Venkat's analogy, i.e. "ExecutorService/Future is to structured concurrency
as goto is to structured programming" meaning they are ok, but not
necessarily at the SC level. Do you think it changes the "sheds more heat
than light" proportions?

Thanks,
Arek

On Mon, May 23, 2022 at 6:57 PM Brian Goetz <brian.goetz at oracle.com> wrote:

>
> > I'd like to know your opinion on the question from the subject - do you
> > think it's justified even to make the comparison between the
> > ExecutorService and goto?
>
> I would not argue with the analogy, but I probably wouldn't be so quick
> to make it, either.  And the reason is: it probably sheds more heat than
> light.  After all, we all "know" that goto is intrinsically terrible,
> right?  So comparing something to goto is dramatic, but doesn't really
> help you understand why it is wrong, or how to do better.  (And,
> instruction sets all include goto, so it's clearly OK at some level.)
>
> I prefer to explain this in terms of the kinds of problems that just
> never happen when you follow the structured discipline.  The reason for
> "goto considered harmful" is the effect it has on the reasoning about
> code.  If any line can jump to any other line (and this isn't even goto
> any more, it's goto plus line numbers), then we cannot reason about the
> state of a program at any given line except by analyzing every line of
> the program.  Similarly, structure concurrency enables you to reason
> confidently about "when I get here, this has happened", without
> analyzing the whole program.
>
> Turning global analyses into local ones is at the core of many
> programming disciplines; this is why encapsulation and modularity
> works.  Local reasoning is both more reliable and scales better.
>
>