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