home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.forth      Forth programmers eat a lot of Bratwurst      117,927 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 117,411 of 117,927   
   dxf to Stephen Pelc   
   Re: Parsing timestamps?   
   04 Jul 25 13:16:31   
   
   From: dxforth@gmail.com   
      
   On 2/07/2025 7:33 pm, Stephen Pelc wrote:   
   > On 2 Jul 2025 at 05:39:52 CEST, "dxf"  wrote:   
   >   
   >> On 1/07/2025 10:22 pm, Hans Bezemer wrote:   
   >>> On 27-06-2025 03:39, dxf wrote:   
   >>>> Yet forthers have no problem with this.  Take the SwiftForth source code.   
   >>>> At best you'll get a general comment as to what a function does.  How do   
   >>>> they maintain it - the same way anyone proficient in C maintains C code.   
   >>>> Albert is correct.  Familiarity is key to readability.  That's not to say   
   >>>> code deserving documentation shouldn't have it.  OTOH one shouldn't be   
   >>>> expecting documentation (including stack commentary) for what's an   
   everyday   
   >>>> affair in Forth.   
   >>>   
   >>> I think you and Albert are on the right track here. Familiarity is a large   
   >>> part of this "readability" thingy. There are a few notes I want to add,   
   >>> though:   
   >>>   
   >>> 1. "Infix notation" is part of this familiarity. I know I've commented   
   every   
   >>> single expression in TEONW, since I understand those "infix" expressions   
   much   
   >>> better than all those RPN thingies - and you got something to check your   
   code   
   >>> against;   
   >>>   
   >>> 2. Intentionality. I do this a LOT. E.g. if you find OVER OVER in my code,   
   >>> you may be certain those two items have nothing to do with each other. If   
   you   
   >>> find 2DUP it's a string, a double number or another "addr/count" array.   
   CHOP   
   >>> replaces 1 /STRING. Also: stack patterns can be codified like SPIN or STOW;   
   >>>   
   >>> 3. Brevity. Short definitions are easier to understand. If you can abstract   
   >>> it, put a name of it can spare the performance - split it up.   
   >>>   
   >>> 4. Naming. I give this a LOT of thought. I prefer reading a name and   
   having a   
   >>> pretty good idea of what that code does (especially in the context of a   
   >>> library or a program). See:   
   >>> https://sourceforge.net/p/forth-4th/wiki/What%27s%20in%20a%20name%3F/   
   >>>   
   >>> Feel free to disagree. It may not work for you, but at least it works for   
   me.   
   >>   
   >> Recently someone told me about Christianity - how it wasn't meant to be   
   easy -   
   >> supposed to be, among other things, a denial of the senses.  I'm hearing   
   much   
   >> the same in Forth.  That it's a celibate practice in which one denies   
   everyday   
   >> sensory pleasures including readability and maintainability in order to   
   achieve   
   >> programming nirvana.  Heck, if that's how folks see Forth then perhaps they   
   >> should stop before the cognitive dissonance sends them crazy or they pop a   
   >> cork.   
   >   
   > IMHO religious belief is not a denial of the senses but a retraining. That   
   > does not mean that the retraining leads to anything valuable, but it can   
   > do depending very much on the trainer and trainee.   
      
   Yet every historical character claimed as enlightened (the Buddha etc) were   
   themselves never taught.  It puts into question the whole teacher/pupil/   
   methodological system that organized religion and various gurus employ.  If   
   several thousand years has shown anything, it is the utter failure of the   
   approach.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca