In article ,   
   Hans Bezemer   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-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)