Re: Parsing timestamps?

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