Re: Parsing timestamps?

On 10-06-2025 19:34, LIT wrote:

So now you see: one can either use variable to
make the solution cleaner - or one can create new word(s).
Either way - some new names are added to the vocabulary.
Why the use of variable, instead of new words,
should be perceived of 'inferior'? Variable is a word too.

>
Unlike variables, factors (subroutines) don't contradict effective
stack-based programming.

  From "Thinking Forth":
 "TIP: Simplify code by using the stack. But don’t stack too
deeply within any single definition. Redesign, or, as a last resort,
use a named variable.
 Some newcomers to Forth view the stack the way a gymnast views
a trampoline: as a fun place to bounce around on. But the stack
is meant for data-passing, not acrobatics.
 [..]
 (not going to paste (almost) whole chapter, but you may want
to read the section "Redesign" that follows the above)
 I’ve been guilty many times of playing hotshot, trying to do
as much as possible on the stack rather than define a local
variable. There are three reasons to avoid this cockiness.
 First, it’s a pain to code that way. Second, the result
is unreadable. Third, all your work becomes useless when
a design change becomes necessary, and the order of two
arguments changes on the stack. The DUPs, OVERs and ROTs
weren’t really solving the problem, just jockeying things
into position. With this third reason in mind, I recommend
the following:
 TIP: Especially in the design phase, keep on the stack only
the arguments you’re using immediately. Create local
variables for any others. (If necessary, eliminate the variables
during the optimization phase.)
 Fourth, if the definition is extremely time-critical, those
tricky stack manipulators, (e.g., ROT ROT) can really eat up
clock cycles. Direct access to variables is faster."

You're mixing quotes with your own statements - and frankly, I'm not gonna clean that mess up.
First of all, Brodie tries to cover as wide a field as possible - and as usual, there is an exception to every (heuristic) rule. So - yeah, I used the occasional variable as well. Like when keeping track of the position on a screen. I'm not going to drag that s*cker all over the data flow, just because Brodie said so.
It also doesn't work very well for arrays in general. You may pass an address to an array to a word, but you're not setting those up in the beginning to surf on the data flow throughout the program.
But you know very well that's not what I'm addressing..
You know you're fighting a losing battle when you go into a chapter called "The stylish stack" and seek for cherries to pick. That's not gonna work.
And although there is a very funny cartoon in that chapter, all you need to know is: "I have a friend who has the sign “Help stamp out variables” above his desk."
So if you want to find some straw to hold on to, you're not gonna find it here:
"TIP: Unless it involves cluttering up the stack to the point of unreadability, try to pass arguments via the stack rather than pulling them out of variables."
There is much for you to learn here. If your stack clutters up, it doesn't automatically mean it can't be done. It just means *you* can't do it. I've been humbled by these grumpy old men here numerous times - and I thank them for that, because it made me a better programmer.
 > Yes, Brodie warns us next "but careful with variables' use
 > too" - and I still think my use of variables in two examples
 > I recently pasted wasn't "legit" in any way. It was just
 > applying the tips you see above.
It wasn't legit, because I proved it could be done *without global variables.* And note every variable access takes two or three words. It's *not* automatically faster. If you think a programming language always behaves the same - in all situations, on all platforms, in every iteration - it's time for you to read "Advanced C" by the Andersons. Gee, you got a long way ahead of you!
Hans Bezemer