home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / forth / 3788 < prev    next >
Encoding:
Text File  |  1993-01-07  |  1.8 KB  |  34 lines
  1. Newsgroups: comp.lang.forth
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mksol!strohm
  3. From: strohm@mksol.dseg.ti.com (john r strohm)
  4. Subject: Re: Documenting
  5. Message-ID: <1993Jan7.190102.3517@mksol.dseg.ti.com>
  6. Organization: Texas Instruments, Inc
  7. References: <C0EoE4.Go3@starnine.com> <1492@eouk9.eoe.co.uk> <1993Jan7.142456.5519@titan.tsd.arlut.utexas.edu>
  8. Date: Thu, 7 Jan 1993 19:01:02 GMT
  9. Lines: 23
  10.  
  11. Larry Maturo asks for reasons why one user prefers blocks over files.
  12.  
  13. I offer the following for consideration.
  14.  
  15. Blocks forces every single chunk of code to fit in a very restricted window,
  16. and it makes it darned near impossible to "slide" the window.  In my
  17. personal opinion, based on the code that I have seen, this restriction
  18. TENDS to force a greater degree of modularization, conciseness, and
  19. coherence, as compared to code developed under programming support
  20. environments that allow and even encourage the programmer to ramble on for
  21. hundreds of lines.
  22.  
  23. FORTH is traditionally used in certain very specific domains of discourse.
  24. In those domains, it is very rare to encounter a routine which cannot be
  25. expressed elegantly and understandably in some number of small fragments,
  26. i.e., blocks.  In the larger domain of programming, I know of only one
  27. domain that routinely needs monstrously-long programs (scripts for automated
  28. test equipment test sequences).  Outside of that, I have seen exactly one
  29. FORTRAN subroutine that was more than one printed page of code, that really
  30. couldn't be broken up any farther, and that really needed to be three pages.
  31. (It was the Photon Torpedo handler from the classic Star Trek game of the
  32. mid-1970s.  That code was quite involved.  This is not exactly your common
  33. everyday run-of-the-mill checkbook balancer here.)
  34.