home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / forth / 3784 < prev    next >
Encoding:
Internet Message Format  |  1993-01-07  |  3.0 KB
  1. Path: sparky!uunet!munnari.oz.au!spool.mu.edu!olivea!mintaka.lcs.mit.edu!ai-lab!hal.gnu.ai.mit.edu!mikc
  2. From: mikc@hal.gnu.ai.mit.edu (Mike Coughlin)
  3. Newsgroups: comp.lang.forth
  4. Subject: Re: Forth Standard Debate
  5. Message-ID: <1ihho9INNor5@life.ai.mit.edu>
  6. Date: 7 Jan 93 15:20:41 GMT
  7. References: <1i7flnINN9or@life.ai.mit.edu> <jax.726119739@well.sf.ca.us>
  8. Organization: /etc/organization
  9. Lines: 52
  10. NNTP-Posting-Host: hal.gnu.ai.mit.edu
  11.  
  12. In article <jax.726119739@well.sf.ca.us> jax@well.sf.ca.us (Jack J. Woehr) writes:
  13. >
  14. >    mike ..
  15. >
  16. >    your posting is so massive i fear we will weary the backbone
  17. >servers if we go on like this!
  18. >
  19.    It certainly is easy to write reams about Forth and the Forth standard.
  20. I try to make my messages smaller, but that takes a lot of time and rewrites.
  21.  
  22. >    let me apologize for scolding you. you sounded so negative,
  23. >like you were saying, "Forth really has problems, and this ANS Standard
  24. >is *really* going to *** it up."
  25. >
  26.    Actually the whole computer industry has problems. What makes me so 
  27. negative is that I don't think publishing the proposed ANSI standard will 
  28. make the industry mend its ways and use Forth where it would work so well.
  29.  
  30. >    secondly, you say that standards don't matter in embedded
  31. >control. in my practice, this is utterly false. 83-Standard is
  32. >currently the most maintainable (i.e., fire your programmer and hire
  33. >one a year later) dialect of Forth.
  34.   
  35.    I can't see the reason for this. Why would a properly documented Forth
  36. program written to the 1983 standard be more manageable than a properly
  37. documented Forth written with a system that did not follow a formal 
  38. standard, like Pygmy or even (gasp) fig-Forth? Perhaps there would be
  39. an advantage with a badly documented Forth program, but its better to
  40. throw out badly documented code (in any langauge) and start all over from
  41. the written specs (if there are any) than to try to salvage the wreckage.
  42. Is a formal standard an attempt to avoid writing commented code?
  43.    Once a Forth program is started it changes the language so it sets
  44. its own standard. The key is to document the variations of common Forth
  45. words that are used as well as explaining what each part of the program
  46. does so the next programmer can understand it. I've been told that there
  47. does exist Forth source that is clearly documented, but I've never seen
  48. it. The code I have seen published would be greatly improved by better
  49. commenting. It would not be improved by following a different Forth
  50. standard.
  51. >
  52. >    taste and see for yourself how sweet it is. program in
  53. >dpANS Forth and see how neat it is!
  54. > 
  55.    I have heard of three versions of Forth that try to follow the X3J14
  56. proposal. One of them runs on the Amiga, and I don't have an Amiga.
  57. (But I do want to get a copy and read it). The others run on PC clones,
  58. and my PC/AT clone has very uncooperative disk drives. I do have a
  59. copy of e-Forth; I'll understand it better when I get it running. So 
  60. I'll have to put off trying dpANS Forth for a while.
  61.  
  62. -- 
  63.    Michael Coughlin             mikc@gnu.ai.mit.edu  
  64.