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
