Sujet : Re: docker, what could be the advantage?
De : dxforth (at) *nospam* gmail.com (dxf)
Groupes : comp.lang.forthDate : 19. Jun 2025, 03:36:56
Autres entêtes
Organisation : i2pn2 (i2pn.org)
Message-ID : <41803740602c3587b02f5e8b6ba7b90d279e431d@i2pn2.org>
References : 1 2 3 4 5 6 7
User-Agent : Mozilla Thunderbird
On 19/06/2025 3:00 am, mhx wrote:
On Mon, 16 Jun 2025 20:48:37 +0000, LIT wrote:
I see its use rather limited - and a whole thing
rather as a kind of novelty - because IMHO compatibility
of Forth code isn't as important as its efficiency.
If the code can be made more efficient by any
non-standard approach, then 'goodbye compatibility',
and the user of some other Forth system if free
to modify the code on his own.
Actually, your view is quite non-standard. I don't know
any Forth users that complain that their system is
inefficient, even if it is token-threaded Fig-Forth on
a ZX80 with cassette-tape. (But then I also do not know
many (>3) Forth users that demand compatibility.)
When I was just starting to use Forth, I found
many magazine articles that discussed squeezing out
the odd cycle by modifying the inner interpreter, and
remember being mighty impressed by that.
However, after some spying around in the sources for
a while I started to wonder if they couldn't see the
forest for the trees.
My current opinion is that these authors are/were
neither interested in efficiency nor in compatibility.
Even today one sees not an insignificant amount of 'micro-benchmarking'.
So I'd say that's still with us. In my case (then and now) value for
money was the criteria i.e. minimizing memory spent while respecting
primitives need to be fast. I've never regretted my choice of DTC for
a 16-bit forth. So it was with some surprise to discover you considered
my choice of timestamp parser 'a joke'. I was left to wonder by what
criteria.