From: dxforth@gmail.com   
      
   On 24/09/2024 12:45 am, Anthony Howe wrote:   
   > On 2024-09-22 23:34, dxf wrote:   
   >> The only guidance a standard can give is on duplicating the past.  I see   
   >> no value in creating a new forth simply to do that.  As an individual one   
   >> has the opportunity to bring something new that's not merely repetition.   
   >> At the very least one can avoid repeating the same mistakes.   
   >   
   > A standard does provide guidance and knowledge of the past, but also   
   provides a jump off point for new work, new designs, new blood.   
   >   
   > In the 1980's there were a plethora C compilers (tiny c, small c, sozobon c,   
   bsd c, turbo c, watcom c, gnu c, sysv c, solaris, ...) just different enough   
   to make portability of source code a PITA.  Similarly all the *nix variants   
   drove a need for    
   POSIX and X/Open (now SUS) to improve portability of software (especially if   
   they wanted government contracts).   
   >   
   > Linux came about and aimed for standards compliance in most aspects and then   
   built new and/or improved tools that extend beyond the standards.  Now clang   
   has come on scene looking to dethrone the megalith gcc that is a bit of   
   portability nightmare    
   within itself as it tries to support numerous CPUs and OSes.   
   >   
   > Having an *agreed on* standard is a good thing, it helps new people learn   
   what is portable, see/hear of pitfalls, and _then_ improve (speed, size,   
   supported hardware) and extend.  A standard should not get in the way of   
   that, but help.   
      
   There's no comparison between C and Forth.  Good luck taking a credible   
   application   
   written in SwiftForth and compiling it on VFX.  Literally every app I write   
   involves   
   a command-tail and a way to save it as a turnkey.  There's not even a standard   
   way   
   to do these basic things.  So obviously lacking in pretentiousness has been the   
   standard one must ask whether there was ever a serious intent.  At best it's a   
   sparse   
   set of words that TC's have agreed you should have and even these have proven   
   divisive   
   spawning decades of argument.   
      
   Maybe - just maybe - one could write a library routine with them but would   
   one?  Not   
   me.  Why would I use anything as restricted as CASE or as broken as REPRESENT ?   
   There's a myriad of tiny useful tools lurking in every forth no standards   
   committee   
   appears to have considered: /CHAR >DIGIT >CHAR MU* MU/MOD (.) /SIGN +STRING   
   etc on the   
   grounds these can be defined portably.  Sorry, I've no intention of going   
   through the   
   nonsense of defining words I already have simply to give others the impression   
   the   
   standard is useful.   
      
   If there's anything the standard has helped me learn is that I don't need it   
   and   
   indeed better off without it.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)