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.
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 >
