Same idea in BASIC with your example of a catchall goto. That requires that you reach the catchall goto. That requires more details to have gone according to plan, that you only branched away in ways you intended, that you never branched away without having set some valid value, and only after failing all the conditions ypu thought of in the ways you intended then after the fact do some default thing.
Pre-loading a drfault before all that means even when something unplanned happens, it's one detail more likely to fail in a more graceful way. Many many times this doesn't matter much, and then one day it matters a lot, and only the fact that you simply already had a habit of doing things a certain way all the time by default, like mental boilerplate, only that saved you from a worse outcome. On Sat, Jan 25, 2020, 2:59 PM Brian White <[email protected]> wrote: > > > On Sat, Jan 25, 2020, 2:49 PM Peter Vollan <[email protected]> wrote: > >> The way one solves that is by having the CASE statements and then a >> GOTO catchall for whatever does not get caught. I think you know this. >> > > > I think I apparently know that and a few other things besides. You seem to > have missed the essence of my point about robustness of design and > procedure. > > The face that case statements have a default condition is particular to > case statements. But setting a default before doing anything else applies > to anything, even if later someone screws up the case statement and removes > the default condition, or replaces it with a ladder of ifs or whatever. > > One way allows for the possibility of something falling through the > cracks, one way removes the possibility from existing at all. > > -- > bkw > > > >> On Sat, 25 Jan 2020 at 07:49, Brian K. White <[email protected]> wrote: >> > >> > Sometimes another explanation for a seemingly no-op line is, given that >> > it's impossible for a human to avoid forming habits, doing things by >> > habit, one can choose consciously to adopt habits that will more-often >> > work. Like always initialize your variables, or always set them to the >> > most likely default value before having the decision code that may >> > overwrite it. Rather than say, having a case statement or some if's that >> > are supposed to cover all cases and just trusting that one way or >> > another it always gets set to something valid. >> > >> > Maybe one day in Foo implementation of language X, variables are >> > initialized for you, so, in that case, it's not necessary. But if you >> > had *that* habit of by default, never bothering to initialize things >> > explicitly except in the exception cases where you need to or when you >> > manage to actually notice a problem, then you will always be running >> > into the problem, or worse, not realizing that you have a problem >> > because in testing it seemed to work. >> > >> > But if you have the habit that you always initialize, then that always >> > works and never hurts. >> > >> > This particular program might indeed be inelegant, but some of the >> > example's you're highlighting are not automatically wrong or stupid. >> > They might be, but the exact same line of code could also be perfectly >> > valid and the result of more sophistication than you rather than less. >> > >> > -- >> > bkw >> > >> > On 1/24/20 9:37 PM, Peter Vollan wrote: >> > > Oh, come now, this is spaghetti BASIC, not pointers in c. >> > > >> > > Look at this: >> > > >> > > 15 T1 = 0: T2 = 0: T3 = 0 >> > > 17 IF A1$ = "S" THEN T1 = 6 E1SE 21 >> > > 19 SC = SC + T1: IF SC = 60 THEN SC = 0: TM = TM + 1 >> > > 21 IF A1$ = "R" THEN T2 = 1 E1SE 25 >> > > 23 MI = MI + T2 >> > > 25 IF A1$ = "T" THEN T3 = 10: TM = TM + T3 >> > > 27 IF (TM + MI) > = 60 THEN TM = TM - 60: HH = HH + 1 >> > > >> > > ISTR hearing that some early computers needed their variables set to 0 >> > > or else they will be full of random junk. Kinkd of like an undelete >> > > program. But even if that is the idea, you can see that this approach >> > > makes no sense, as the variables are not incremented, but set to >> > > something else. And when I ran the program, the updated time was only >> > > displayed when Turns (10 minutes) was updated and I do not think that >> > > was meant to happen. This is what they were publishing in magazines? >> > > >> > > On Fri, 24 Jan 2020 at 13:47, Brian K. White <[email protected]> >> wrote: >> > >> Frequently when I see something that makes no sense, I discover >> sometime >> > >> later that it did actually do something. >> > >> >> > >> A line of code can look non-sensical, or merely non-optimal, because >> of >> > >> all kinds of different reasons, like it's a way to write something >> that >> > >> works on multiple platforms even though by rights they should each be >> > >> different, or it causes some internal effect in the interpreter or >> > >> hardware like loading or clearing registers as a side-effect, or it >> > >> pushes the internal tokenized keywords in the program around into >> some >> > >> funky byte alignment or other structure that ends up executing >> faster, >> > >> or allows some other bit of the code to do some dirty math trick with >> > >> pointers to addresses that by rights it should have to do some much >> more >> > >> expensive but safer way. >> > >> >> > >> Or it could actually just be dumb. Or it could be corrupted like it >> was >> > >> originally typed in wrong manually from a book or OCR'd, or it worked >> > >> fine on some other machine and it's only a bug now because of an >> > >> incomplete port. >> > >> >> > >> There is at least one program where the bugs are actually the entire >> > >> point of the program. The program name is, shall we say, promising. >> You >> > >> run it. It fails but the error is obvious because you are smart! So >> you >> > >> fix that clod's mistake and wonder how this crap ever made it into >> the >> > >> archives without someone else fixing it before now. It runs a tiny >> bit >> > >> further and fails again. Again the new error is obvious so you fix >> it. >> > >> Man this programmer was a freaking buffoon. You fix a couple more >> > >> errors, and in the end all it says is something like "wasn't that a >> fun >> > >> game?" The promise of the filename never existed. ;) >> > >> >> > >> -- >> > >> bkw >> > >> >> > >> On 1/24/20 2:26 PM, Peter Vollan wrote: >> > >>> Well, it doesn't say that. And if it did, that would still be a dumb >> > >>> way to do it. Then the next line sets three variables to 0 which is >> > >>> totally unneccessary, so that's a line that does nothing. And that >> is >> > >>> only the tip of the iceberg of the problems with this program >> > >>> >> > >>> On Thu, 23 Jan 2020 at 09:55, Dan Higdon <[email protected]> >> wrote: >> > >>>> The final number on that line should be an 11, then it works. >> (That is, "ELSE 11", not "ELSE 13") >> > >>>> >> > >>>> On Sun, Jan 19, 2020 at 4:57 PM Peter Vollan <[email protected]> >> wrote: >> > >>>>> Check this out! Not only is it a dumb way to do things, but it >> does >> > >>>>> not even work the program just hangs! >> > >>>>> 13 IF AL$ = "S" OR AL$ = "R" OR AL$ = "T" THEN 15 ELSE 13 >> > >> >> > >> -- >> > >> bkw >> > >> >
