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
