I did not do the E1SE thing, I assume it is an artifact of scanning
On Sat, 25 Jan 2020 at 10:26, Mike Stein <mhs.st...@gmail.com> wrote: > > What Brian said! > > Also, like many things, context matters; perhaps those variables are used > elsewhere and they do need to be initialized. Even if not, 'habits' like > explicitly initializing variables are often considered and taught as 'good > programming practice'. > > Personally I wouldn't write it quite this way but to some extent programming > is an individual art form, especially in a hobby context; it's also good to > remember that depending on where, when and by whom it was published the fact > that it appears in a magazine doesn't necessarily mean it's good style or > practice, as seen by the regular corrections in subsequent issues. > > If you want help fixing a problem then publish the whole program; if you need > to criticize someone's style why not do it in a less condescending way. Note > that that also leaves you open to the same criticism; I note that you don't > show how you would do it instead ;-) > > I don't know whether it was that way originally or whether you introduced > that typo, but the 'E1SE' instead of 'ELSE' in lines 17 and 21 will certainly > cause a problem. > > m > > ----- Original Message ----- > From: "Brian K. White" <bw.al...@gmail.com> > To: <m...@bitchin100.com> > Sent: Saturday, January 25, 2020 10:49 AM > Subject: Re: [M100] another program > > > > 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 <b.kenyo...@gmail.com> 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 <therealh...@gmail.com> 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 <dprogra...@gmail.com> > >>>>> 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 > >
