• The future. (was Re: Parsing timestamps?)

    From albert@spenarnc.xs4all.nl@21:1/5 to the.beez.speaks@gmail.com on Wed Jun 25 11:54:44 2025
    In article <nnd$34fd6cd6$25a88dac@ac6bb1addf3a4136>,
    Hans Bezemer <the.beez.speaks@gmail.com> wrote:
    On 24-06-2025 13:50, minforth wrote:
    On Tue, 24 Jun 2025 9:30:35 +0000, Hans Bezemer wrote:
    'Look, Ma - I've solved Forth's biggest problem.' ;-)

    No really, I'm not kidding. When done properly Forth actually changes
    the way you work. Fundamentally. I explained the sensation at the end of >>> "Why Choose Forth". I've been able to tackle things I would never have
    been to tackle with a C mindset. ( https://youtu.be/MXKZPGzlx14 )

    Like I always wanted to do a real programming language - no matter how
    primitive. Now I've done at least a dozen - and that particular trick
    seems to get easier by the day.

    And IMHO a lot can be traced back to the very simple principles Forth is >>> based upon - like a stack. Or the triad "Execute-Number-Error". Or the
    dictionary. But also the lessons from ThinkForth.

    You'll also find it in my C work. There are a lot more "small functions" >>> than in your average C program. It works for me like an "inner API". Not >>> to mention uBasic/4tH - There are plenty of "one-liners" in my
    uBasic/4tH programs.

    But that train of thought needs to be maintained - and it can only be
    maintained by submitting to the very philosophy Forth was built upon. I
    feel like if I would give in to locals, I'd be back to being an average
    C programmer.

    I still do C from time to time - but it's not my prime language. For
    this reason - and because I'm often just plain faster when using Forth.
    It just results in a better program.

    The only thing I can say is, "it works for me". And when I sometimes
    view the works of others - especially when resorting to a C style - I
    feel like it could work for you as well.

    Nine times out of ten one doesn't need the amount of locals which are
    applied. One doesn't need a 16 line word - at least not when you
    actually want to maintain the darn thing. One could tackle the problem
    much more elegant.

    It's that feeling..

    Why make everything so complicated? An electrician's toolbox looks
    different from a horse smith's toolbox. You sound like a horse smith
    who frowns at the electrician's toolbox and the electrician's
    “philosophy”.

    Yes, that's why we have languages like Forth and C - each with its own >philosophy.

    The point is, I think there is not enough respect for the Forth
    philosophy. It's even publicly denied there is such a philosophy at all.
    Or that there are actual, measurable benefits to that philosophy.

    And that's the core of the issue, I think.

    I'm also puzzled why there is always so emphasis on the "speed" issue. I
    mean - if you want speed, do your program in C -O3 so to say. It'll blow
    any Forth out of the water. Now I know that there are people concerned
    with optimizing Python, but I frown on that as well.

    Me too. Many posts post a speed for a program or snippet that they
    don't care to explain what it is good for.

    If you want to optimize (misnomer for "speed up") the word ALLOCATE
    just do
    'ALLOCATE OPTIMISED
    (This is ciforth: write on essay about this is far superior to the phrase "OPTIMISE ALLOCATE" )

    I have been writing an optimiser for some time now.
    It is on the backburner, partly because intel 86 is insane, mainly
    because it is not really needed. It is more of an academic exercise.
    (The byte sieve was optimised to vfxforth level, but honestly not
    much else.)
    Now riscv is the future. I have succeeded in my experimental optimiser
    to get rid of return stack storage (like for loops), and nesting overhead.
    I should use the same technique for the data stack, instead of transforming sequences of Intel instructions to smaller once and trying to get rid
    of the endless pops and pushes that way.

    Now I going to optimise riscv, with much more uniform registers to play
    with. And ditch github (USA) in favour of gitee (Chinese).
    USA is circling the drain.


    I don't mean to say you should close every window to optimization, but
    at least admit to one another - it's a secondary problem with Forth.

    But to each his own - make love not war. :o)

    I'm all for a civil discussion, fully agreed! ;-)

    Hans Bezemer


    Groetjes Albert
    --
    The Chinese government is satisfied with its military superiority over USA.
    The next 5 year plan has as primary goal to advance life expectancy
    over 80 years, like Western Europe.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Rubin@21:1/5 to albert@spenarnc.xs4all.nl on Wed Jun 25 21:01:05 2025
    albert@spenarnc.xs4all.nl writes:
    with. And ditch github (USA) in favour of gitee (Chinese).
    USA is circling the drain.

    Try codeberg.org (Germany) maybe.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From albert@spenarnc.xs4all.nl@21:1/5 to no.email@nospam.invalid on Mon Jun 30 20:47:44 2025
    In article <878qlf179a.fsf@nightsong.com>,
    Paul Rubin <no.email@nospam.invalid> wrote:
    albert@spenarnc.xs4all.nl writes:
    with. And ditch github (USA) in favour of gitee (Chinese).
    USA is circling the drain.

    Try codeberg.org (Germany) maybe.

    USA is no more likely to survive in the near future (taking on
    China), than Germany that believes that they should defend Ukrain.
    They can't, and the result is economic collapse.
    In both cases commercial enterprises (that have "free software" for
    marketing purposes) I deem unreliable.

    OTOH gitee is supported by a government that has technical and
    scientific progress as a first priority. The harmony os (Huawei) is
    hosted there.

    Groetjes Albert
    --
    The Chinese government is satisfied with its military superiority over USA.
    The next 5 year plan has as primary goal to advance life expectancy
    over 80 years, like Western Europe.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)