From: antispam@fricas.org   
      
   Hans Bezemer  wrote:   
   >   
   > 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 )   
      
   I do not look at videos (mostly because they are extremally wasteful   
   way of transmiting concepts, with words once can do this faster).   
   So I will comment mostly on what you wrote.   
      
   > 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.   
      
   I am not sure what you mean "do a real programming language".   
   I have written compilers.  The ones where I did all the work   
   I consider to be toys.  But I am pretty confident that if   
   I wanted I could extend them to a practical language.  I also   
   work on real compilers, but here majority of work was done by   
   other people and I only worked on parts.  Still, while in   
   a single compiler "my" part (or parts) are minority, they   
   together cover all stages of practical compiler.   
      
   I did not write a serious interpreter or even a part of it   
   but I looked at code in several interpreters and I think that   
   I understand subject well enough to write on if needed.   
      
   > 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.   
      
   Traditional way to implement Forth is just one way.  It is   
   relatively simple, so this may be attractive.  But I would   
   say not the simplest one: bytecode interpreters are less   
   clever, so in a sense simpler (at cost of slower execution).   
   Compilers generating native code can be simple too, and   
   one can argue that they also need less cleverness than Forth   
   (but probably more object code).   
      
   > 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.   
      
   My philosophy for developing programs is "follow the problem".   
   That is we a problem to solve (task to do).  We need to   
   understand it, introduce some data structures and specify   
   needed computation.  This is mostly independent from programming   
   language.  When problem is not well understood we need   
   to do some research.  In this experiments may help a lot   
   and having interactive programming language in useful   
   (so this is plus of Forth compared to C).  Once we have   
   data structures and know what computation is needed we   
   need to encode (represent) this in choosen language.   
   I would say that large scale structure of the program   
   will be mostly independent of programming language.   
   There will be differences at small scale, as different   
   languages have different idioms.  "Builtin" features of   
   language or "standard" libraries may do significant   
   part of work.  Effort of coding may vary widely,   
   depending how much is supported by the language and   
   surroundig ecosystem and how much must be newly   
   coded.  Also, debugging features of programming   
   system affect speed of coding.   
      
   Frankly, I do not see how missing language features   
   can improve design.  I mean, there are people who   
   try to use fancy features when thay are not needed.   
   But large scale structure of a program should not be   
   affected by this.  And at smaller scale with some   
   experience it is not hard to avoid unneeded features.   
   I would say that there are natural way to approach   
   given problem and usually best program is one that   
   follows natural way.  Now, if problem naturally needs   
   several interdependent attributes we need to represnt   
   them in some way.  If dependence is naturaly in stack   
   way, than stack is a good fit.  If dependence is not   
   naturaly in a stack way, using stack may be possible   
   after some reorganisation.  But may experience is   
   that if a given structure does not naturally appear   
   after some research, than reorganisation is not   
   very likely to lead to such structure.  And even if   
   one mananges to tweak program to such structure, it   
   is not clear if it is a gain.  Anyway, there is substantial   
   number of problem where stack is unlikely to work in   
   natural way.  So how to represnt attributes?  If they   
   are needed only inside a single function, than natural   
   way is using local variables.  One can use globals, but   
   for variables that are not needed outside a function   
   this in unnatural.  One can use stack juggling, this   
   works, but IMO is unnatural.  One can collect attributes   
   in a single structure dynamically allocated at   
   function entry and freed at exit.  This works, but   
   again is unnatural and needs extra code.   
      
   Of course, sometimes other solutions are possible.  Maybe   
   instead of separate variables one can recompute attributes   
   from something more basic.  Maybe some group of attributes   
   is needed in several functions, then keeping them as part   
   of single structure is natural.  But assuming that you   
   write program in natural way, you would choose alternative   
   what it is natural and choose locals only when thay   
   are a good fit.   
      
   You have some point about length of functions.  While   
   pretty small functions using locals are possible, I   
   have a few longer functions where main reason for keeping   
   code in one function is because various parts need access   
   to the same local variables.  But I doubt that eliminating   
   locals and splitting such functions leads to better code:   
   we get a cluster of function which depend via common   
   attibutes.  This dependence is there regardless of having   
   single bigger function or several smaller ones (and   
   regardless how one represents attributes).  But with a   
   single function dependence is explict, and for me easier   
   to manage.   
      
   Avoiding dependence helps, but above I mean unavoidable   
   dependence.  And in fact, I find locals useful to avoid   
   false dependencies (where a buch of functons look like   
   they depend on something but in fact they do not).   
      
   > 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   
      
   [continued in next message]   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)