3 ms·
Almost everything is a "rebranded goto". Functions, conditions, iteration, break/continue. Doesn't mean that Dijkstra was wrong, or that they are the same as g
by whstl 3y ago
Almost everything is a "rebranded goto". Functions, conditions, iteration, break/continue.
Doesn't mean that Dijkstra was wrong, or that they are the same as goto.
Also, throw/catch do quite more than a goto, though. It's not only about stack unwinding, it's about the ergonomics of not needing code that uses throw to have any information about where catch is located.
Sure you can simulate some use cases of try/catch with goto, but implementing the general case is much harder.
throw/catch is exactly the kind of good goto-replacement provided by "higher level" programming languages that Dijkstra is talking about in his paper.
- gjvc 3y ago> Almost everything is a "rebranded goto". Functions, conditions, iteration, break/continue. That's like saying all maths is just the application of addition.
- ubercore 3y agoI think that's the point -- it's nearly as useless to call throw/catch a rebranded goto as it is anything else.
- whstl 3y agoYeah. It’s a useless pedantism that serves no purpose in most discussions. That’s what I have “rebranded goto” in quotes. And that’s what I address in the second paragraph.
- gjvc 3y agoit failed to satisfy me
- randomdata 3y ago> Almost everything is a "rebranded goto". Functions, conditions, iteration, break/continue. Not within the context of discussion, where goto refers to the harmful kind. Throw/catch exhibits the very problem Dijkstra was talking about, with execution jumping all over the place haphazardly. Functions, conditions, iteration, break/continue, even (C-style) goto does not exhibit the same problem. They are strictly bridled in the execution scope. There is good reason why modern languages are moving away from throw/catch. However, there is little question that it is still widely used at this time.