Re: Parsing timestamps?

Mr. Fifo - self-proclaimed "Mark Twain of Forth"
- has no idea, that writing Forth code doesn't
mean to move bytes around "Back and Forth"
(where did I see that? Let's see... :D ).
>
Stack jugglery means wasting CPU cycles for
moving the bytes around - it's contrproductive.
Variables have been invented to be used. They're
useful, if you didn't notice, or if they didn't
tell you that in your college, or wherever.

>
First, a stack has been invented to be used as well.

..which doesn't deny use of variables where it's useful.

And a canonical
Forth program uses the stack. Tut mir Leid.

You're sorry that you 'have' (IYO) to use the stack
not quite senseful way? They force you to do so?
Poor you.

If you want to use local variables, there are plenty
of languages that use that stuff. Like Python, the
language of champions.

Contact me with your "recommendation" again when you
become appointed of some kind of 'authority' who'll
decide, who should use what. Until then - I'll use
whatever language I'll decide to use at the moment.

Second, there are CPUs that are stack oriented - and using variables
should be wasteful in that case. There are also plenty of CPUs that have
a stack, like Z80, 8080 and friends. Sorry to say, but using ANY
instruction burns CPU cycles. There is no way around that.

Yes, indeed - these CPUs have a stack, and what you've
presented is pointless stack jugglery. We may 'burn CPU
cycles' to do something useful - or, following you (if
anyone would be keen, which I doubt) we could use that
stack for pointless moving the bytes "Back and Forth".

Third, any statement must come with proof. And in this case that means
extended benchmarking. I can tell you beforehand that I've never seen
significant differences between locals and stack. I'm sorry to say that
- but it's true.

Oh, really? That speaks in favor of the most clean solution.

Finally, you have to know that good software comes with MANY qualities,
speed being only one of them. If I have to choose between correct and
fast, there has to be a very convincing argument for the speed
requirement. They didn't tell you that in your college? Oh dear. I'm so
sorry for you! You must have had a miserable life.

Yes, software comes with many qualities - and one of them,
which you didn't mention (maybe you have no clue), is
clarity of the code. The code filled with strings of that
DUPs, SWAPs and ROTs not only works inefficiently, but also
rather quickly becomes unreadable. And then serves as
another example of 'typical write-only Forth code'.
--