Re: Parsing timestamps?

On Thu, 26 Jun 2025 5:20:13 +0000, Waldek Hebisch wrote:

My philosophy for developing programs is "follow the problem".
That is we a problem to solve (task to do).  We need to
understand it, introduce some data structures and specify
needed computation.  This is mostly independent from programming
language.  When problem is not well understood we need
to do some research.  In this experiments may help a lot
and having interactive programming language in useful
(so this is plus of Forth compared to C).  Once we have
data structures and know what computation is needed we
need to encode (represent) this in choosen language.
I would say that large scale structure of the program
will be mostly independent of programming language.
There will be differences at small scale, as different
languages have different idioms.  "Builtin" features of
language or "standard" libraries may do significant
part of work.  Effort of coding may vary widely,
depending how much is supported by the language and
surroundig ecosystem and how much must be newly
coded.  Also, debugging features of programming
system affect speed of coding.
>
Frankly, I do not see how missing language features
can improve design.  I mean, there are people who
try to use fancy features when thay are not needed.
But large scale structure of a program should not be
affected by this.  And at smaller scale with some
experience it is not hard to avoid unneeded features.
I would say that there are natural way to approach
given problem and usually best program is one that
follows natural way.  Now, if problem naturally needs
several interdependent attributes we need to represnt
them in some way.  If dependence is naturaly in stack
way, than stack is a good fit.  If dependence is not
naturaly in a stack way, using stack may be possible
after some reorganisation.  But may experience is
that if a given structure does not naturally appear
after some research, than reorganisation is not
very likely to lead to such structure.  And even if
one mananges to tweak program to such structure, it
is not clear if it is a gain.  Anyway, there is substantial
number of problem where stack is unlikely to work in
natural way.  So how to represnt attributes?  If they
are needed only inside a single function, than natural
way is using local variables.  One can use globals, but
for variables that are not needed outside a function
this in unnatural.  One can use stack juggling, this
works, but IMO is unnatural.  One can collect attributes
in a single structure dynamically allocated at
function entry and freed at exit.  This works, but
again is unnatural and needs extra code.
>
You have some point about length of functions.  While
pretty small functions using locals are possible, I
have a few longer functions where main reason for keeping
code in one function is because various parts need access
to the same local variables.  But I doubt that eliminating
locals and splitting such functions leads to better code:
we get a cluster of function which depend via common
attibutes.

These are my observations as well. It all depends on the problem
that you are facing. Now there are some guys who behave
like self-declared Forth mullahs who shout heresy against
those who don't DUP ROT enough.
Is theirs the Forth philosophy?? Really?? I thought the main
Forth principle was "keep it simple". When stack reordering
is the easier way, do it. When using locals is the easier way,
do it. If a few helper words make it easier, use them.
--