Re: Parsing timestamps?

Hans Bezemer <the.beez.speaks@gmail.com> writes:

And just before you're done you put your stuff on the stack and like a
tiny assembly line it is transported to the next thing. This means that
the function call overhead is MINIMAL - much less than C.

Oh, really?  Wasn't it you who wrote
<nnd$34fd6cd6$25a88dac@ac6bb1addf3a4136>:

|if you want speed, do your program in C -O3 so to say. It'll blow
|any Forth out of the water.

And if we look at the results for fib (a benchmark that performs lots
of calls) inf Figure 1 of
<https://www.complang.tuwien.ac.at/papers/ertl24-interpreter-speed.pdf>,
gcc -O3 outperforms the fastest Forth system, and gcc -O1 outperforms
the fastest Forth system by even more.

And that's not the solution - it's the PROBLEM. You can add loads of
complexity without much (immediate) penalty. You're not compelled to
study - or even *think* about your algorithm. You most probably will end
up with code that works - without you understanding why.
>
And that will either bite you later, or limit your capability to expend
on that code.

Yes, you can expend a lot of effort on code that's hard to write and
hard to understand, but that's not limited to Forth.

If you mean that, by making code hard to write, Forth without locals
makes it easier to extend the code, I very much doubt it.  In some
cases it may not be harder, but in others (where the extension
requires, e.g., dealing with additional data in existing colon
definitions) it is harder.

- anton
--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/