Objective Evidence Against Gotos Discussion Two
Objective Evidence Against Gotos Discussion TwoContinuation of ObjectiveEvidenceAgainstGotosDiscussion because it's TooBigToEdit
My gawd... another one? I'll reply just this once.
Ahhh, you know you can't resist.
Perhaps you'd find it clearer if you weren't closing your eyes. The logic failure is clear to me, and I've done my best to explain it to you (in many different ways, with many different analogies), but you're not even meeting me halfway. I have no 'power' to 'make' things clear to you when you don't want to hear them, and when you assume you know better, and when you automatically dismiss everything I say as 'suspicious' because your own education has either been forgotten or was never there in the first place.
Stop projecting your poor 5th-grade documentation skills onto my alleged faults.
Stop projecting your poor 5th-grade logic skills onto my documentation.
And this "mysterious superset": I have described the source of it - 'errors allowed by gotos' vs. 'errors allowed by braces' are very much inherent 'sets'; I guess I overestimated your intellect again in assuming you'd figure that much out. Sorry to assume too much competence from you. And the argument for it being a 'superset' was also straightforward, even if you can neither remember it nor find it in this threadmess: blocks themselves can be formed by creating restrictions on applied gotos (of the most generic sort) because they considerably more flexible than gotos.
Explain this "more flexible" claim of yours.
X is "More flexible" than Y if and only if X can take every shape Y can take (e.g. implement every code pattern) AND X can take at least one more shape. In this sense, gotos are more flexible than blocks.
I never described it further than that because you never asked (instead, you were too busy defending, with much hand-wavy irrelevant and illogical argument, against the claim).
Oh right, I never asked for clarifications of your obtuse writing before? Good one.
You've asked for clarifications, but not on that subject. You were too busy focusing on the utterly irrelevant.
To expand a bit more: one can restrict general gotos by limiting it to 'goto' a relative label in a scope and further restrict the use of 'goto' to exactly the same situations 'blocks' are allowed in the base language, and you end up with blocks.
I don't know if we could claim they "are" blocks without a more specific consensus definition. They can take on some features of blocks with additions. That I will agree to.
They take on "some" features of blocks with coupled (required) additions, and they take on the rest via restrictions, BOTH of which are specializations of gotos (i.e. a smaller subset of all gotos). However, you need to start with generic 'gotos'; if you start with 'gotos of a species restricted to going to unique labels', then you can only get by this path to 'labeled blocks' because there is no way to get rid of the need for unique labels on that path.
Trivially, since blocks can be formed of restricting gotos, blocks must have both a subset of goto capabilities AND of goto errors.
Again, the "are the same" issue needs to be settled.
If they have a "subset of goto capabilities", your own words, that implies blocks lack certain "capabilities" that goto's have.
Correct. Blocks lack many "capabilities" that gotos have.
One such capability is a reduced potential grammar (already discussed).
Incorrect. This is not a "capability" of gotos. But the issue is moot for the discussion; gotos do have capabilities that (common) blocks do not. Some even make sense to use, such as for error handling one can 'goto' the correct location for resource cleanup. [emph. added by me -top]
We're back to apples and oranges. Surprise surprise. (And you had to complicate your block's grammar even further when adding labels to get around the "middle mutate" test.)
You seem to have lost track of the argument, again. Noting that blocks only allow a subset of the capabilities of gotos is all fine and dandy, but doesn't counter that blocks only allow a subset of errors of gotos. The whole 'subset of errors' argument has always fundamentally been what you call 'micro'-rigor because it focused on a 'micro' issue: potential errors; I think you mistook it for something more.
You seem to be assuming that this is only about errors. But, errors are not the only metrics to consider. Unlike you, I am not obsessed with compile-time-checking at the expense of anything else. Even if I grant you an error-checking victory for the sake of argument, there's more to this Goto Olympics than the error-checking event. [Some context seems to be missing here, as if the order of the text was switched.] --top
I assumed this was about 'ObjectiveEvidenceAgainstGotos' and so my only intent with the example was to meet those conditions ('objective evidence' 'against gotos'); I certainly never thought it was the end of the "Goto Olympics". But, unlike you, I believe that macro-rigor doesn't exists in any science, and thus that its non-existence in ComputerScience is a complete non-issue. I think it's just hand-wavy mumbo-jumbo you invented to avoid reasonable debate. The only thing I know that matters is micro-rigor as applied to known and predicted micro-situations.
You seem to looking for an escape clause. This was about "macro-rigor", not the existence of isolated benefits. I never disputed that blocks may score better for certain specific metrics. Proponents of contentious topics such as heavy typing, heavy OOP, thin-tables, etc. generally word their convictions as more or less absolute or at least overwhelming, not spot-per-spot situational. If you are not one of those "overwhelmers", then this "test" of goto's may not apply to you.
I conclude this with the stamp of TooManyVariablesForScience. "Micro benefits" can be found for each side, as we both finally agreed here, but nobody has shown an overwhelming objective net avantage. Macro-rigor is still lacking to prove that blocks are "better".
--top
EditText of this page
(last edited January 10, 2014)
or FindPage with title or text search