From: the.beez.speaks@gmail.com   
      
   On 05-03-2024 00:03, Tristan Wibberley wrote:   
   > On 01/03/2024 18:02, Anton Ertl wrote:   
   >> mhx@iae.nl (mhx) writes:   
   >>> What if the program writes a float to a byte location?   
   >>   
   >> That's not a safety problem (as long as the location is big enough for   
   >> the float), so one can design a Safe Forth variant that allows that.   
   >   
   > I'm not very familiar with forth yet, does this refer to writing to a   
   > machine addressed location? If so, plenty of computers have alignment   
   > requirements, a DoS can be introduced by the above action.   
   >   
   > Also, if you write a byte to a float location, a variety of problems can   
   > be introduced including running trap callbacks that were insufficiently   
   > tested for the new program state, etc, killing the process and running   
   > restart sequences where less volatile state can now be in an unusual   
   > condition and new side-effects induced, and so on.   
   >   
   > memory safety means maintaining invariant relations wrt. each memory   
   > location.   
      
   This entire discussion really made me laugh. How sentiments change..   
   I can remember when I wrote 4tH people were dismissing it, because of   
   its safety features: "This is not Forth".   
      
   But 4tH addresses most of the issues at hand. You cannot write a float   
   on a character, because those reside in different segments. You cannot   
   overwrite execution code - because that not only resides in a different   
   segment, but it's also "read only".   
      
   If your execution pointer goes outside the code segment, the program   
   simply stops. If you do a MOVE - any MOVE - it will check the bounds   
   before going at it at C speed.   
      
   Now - I won't say you can't do any damage. It doesn't do any array   
   bounds checking, so a string can spill into another string. But it will   
   not spill outside its segment. If you use a random integer value as a   
   pointer, it will be okay to corrupt anything inside that segment, but   
   not *OUTSIDE* that segment. And frankly, that's all the safety I need.   
      
   If you think you will revive Forth by jumping on that Rust bandwagon, I   
   think you're wrong. You won't attract a new audience and you won't get   
   the acceptance you crave for. First and foremost, because I think Rust   
   is the wrong idea. It's been tried before - Ada, Pascal, Java - in some   
   sense: BASIC.   
      
   Good programmers exist because they are good programmers. Bad programs   
   exist because of bad programmers. Let me quote one of the foremost CS   
   scientists who ever lived:   
      
   "Ada will not meet its major objective, viz. that of reducing software   
   costs by standardization, and it will not be the vehicle for programs we   
   can rely upon, for it is so complicated that it defies the unambiguous   
   definition that is essential for these purposes. Long before the design   
   was frozen, computing scientists from all over the world have given   
   plenty of warning but the political body in question preferred to ignore   
   these warnings and to decide on a design that cannot be salvaged. From a   
   scientific point of view all further attention paid to Ada is a waste of   
   effort. But the sheer buying-power of the DoD makes Ada an undeniable   
   reality, which in combination with DARPA's policies for the funding of   
   software research can only increase the pressure to spend research   
   effort on the wrong problems.   
      
   Another series of stones in the form of "programming tools" is produced   
   under the banner of "software engineering", which, as time went by, has   
   sought to replace intellectual discipline by management discipline to   
   the extent that it has now accepted as its charter "How to program if   
   you cannot."   
      
   Let that sink in: "It will not be the vehicle for programs we can rely   
   upon, for it is so complicated that it defies the unambiguous definition   
   that is essential for these purposes". That is the very definition of Rust.   
      
   All the time you're spending getting your code to compile, you're not   
   creating programs. I'd say that's the reverse of productivity. The   
   higher the abstraction, the more difficult it is to understand - let   
   alone to teach.   
      
   Compare "pointer" to "a variable containing an address", the beauty of   
   "an object" to "a structure with a few function pointer fields" and a   
   bunch of syntactic sugar (i.e. object.method vs. method(object)).   
      
   Lifetimes? Borrowing? Are you kidding me? After programming in Forth for   
   over 30 years now, I'm slowly getting why I get things done in Forth   
   that I would never have imagined to tackle in C. Forth has some   
   remarkable principles. The stack is one of them. The principle "execute,   
   throw on the stack or throw an error" is another one. The dictionary,   
   consisting of a function pointer and a string is another one.   
      
   Simple principles, simple to grasp, but very powerful - especially when   
   combined. ColorForth added a few more, BTW.   
      
   I tend to trust my Forth programs a lot more than my C ones, for the   
   simple reason that there were a million (stack) errors I could have made   
   along the way - every single one of them capable of turning my beautiful   
   program into a steaming pile of dung.   
      
   So, safety, yes. I like that very much. I ventured into that very early   
   and I never regretted it. But apart from some basic checks it should   
   stop at the point where I have to convince a compiler that I know what   
   I'm doing.   
      
   Hans Bezemer   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)