Sujet : Re: docker, what could be the advantage?
De : zbigniew2011 (at) *nospam* gmail.com (LIT)
Groupes : comp.lang.forthDate : 18. Jun 2025, 20:28:03
Autres entêtes
Organisation : novaBBS
Message-ID : <44492bf8dffc6b061ced17c4004768c2@www.novabbs.com>
References : 1 2 3 4 5 6 7
User-Agent : Rocksolid Light
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.)
Non-complaining (or no trace of such complaining)
isn't any rationale for assumption "everyone are
quite pleased with what they presently use (amd
how they use that)". Optimalization wouldn't had
any sense whatsoever if everyone were that pleased.
I'm recently since longer time tinkering with that
fig-Forth I already mentioned, I learned its
limits, I'm pretty aware it's not particularly fast
"per se" and I don't complain. :) Just from time
to time trying some less standard approach.
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.
Could you, please, give any example of such
article (if it's available on any WWW page)?
--