home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / forth / 3780 < prev    next >
Encoding:
Text File  |  1993-01-07  |  3.6 KB  |  79 lines
  1. Path: sparky!uunet!mcsun!uknet!acorn!eoe!ahaley
  2. From: ahaley@eoe.co.uk (Andrew Haley)
  3. Newsgroups: comp.lang.forth
  4. Subject: Re: Documenting
  5. Message-ID: <1492@eouk9.eoe.co.uk>
  6. Date: 7 Jan 93 10:27:04 GMT
  7. References: <C0EoE4.Go3@starnine.com>
  8. Organization: EO Europe Limited, Cambridge, UK
  9. Lines: 67
  10. X-Newsreader: TIN [version 1.1 PL6]
  11.  
  12. Mike Haas (mikeh@starnine.com) says that "screens" (by which I presume
  13. he means blocks used for source code) are viewed by [users of other
  14. languages] as evidence that Forth will never be a modern language.
  15.  
  16. Some people may believe this, but it flies in the face of historical
  17. fact; BLOCK was an innovation.  Every computer OS around at the time
  18. (1970) supported text files, but Charles Moore invented a different
  19. method of accessing source text and other data, not because he was
  20. "old fashioned" but because he thought that he had a better system.
  21.  
  22. I don't think that people who do not use Forth will be drawn to it if
  23. we change all our sources to use OS text files; they will carry on
  24. happily using C or whatever.  The only difference will be that people
  25. who like to use blocks will no longer have their sources in that
  26. convenient form.  
  27.  
  28. There is a great deal of work to be done in getting the interactive
  29. development tools already used in Forth systems to work with text
  30. files.  If Forth has any virtue, it is simplicity; rewriting existing
  31. tools to use text files would greatly complicate things.
  32.  
  33. There is too much emphasis in this group on rewriting tools that
  34. already work very well in order to satisfy the expectations of people
  35. who are never going to use them.
  36.  
  37. I've no idea where the notion that some of [Forth's] major features
  38. are architected to work best only in embedded controller applications
  39. comes from; that is contrary to what is known about Forth's history.
  40. Much early Forth use at Forth, Inc was in commercial/database
  41. systems.  They found that blocks work extremely well in that
  42. environment.
  43.  
  44. On some platforms, interaction with host operating system files is
  45. essential; fair enough.  You might even run Forth as a task under
  46. another OS.  I've done this in many applications, and sometimes it's a
  47. good solution, but Forth is not a programming language so much as an
  48. operating system.  The Forth applications I've seen which impressed me
  49. the most used Forth as the OS.  There are some wonderful multiuser
  50. databases which use the Forth operating system.
  51.  
  52. It depends on what your goal is.  If it's to get the maximum number of
  53. Forth users, maybe Mike Haas's route is the best.  If your goal is to
  54. develop efficient applications on computers (and yes, efficiency is
  55. still important) then you might choose a different route.
  56.  
  57. If the "mainstream" expects a standard set of functions which allow
  58. one to link with object files from other languages, then by all means
  59. let's supply one.  But we shouldn't assume that they will use Forth if
  60. we do.
  61.  
  62. Those who stay with source blocks don't do so because they don't care
  63. to "put the work in."  It's because we find that blocks are a good
  64. solution to the problems we face when developing applications.  If
  65. some others choose to use text files, that's fine.  I don't want to
  66. convince others how great blocks are; I just want to explain why _I_
  67. use them.  
  68.  
  69. If others prefer text files, that's great, but I resent the
  70. implication that I haven't moved to text files because of laziness.
  71. It's because blocks work best for my uses.  If others use text files
  72. that doesn't bother me at all.
  73.  
  74. I am very disappointed to see the great "blocks versus files" flame
  75. war resurrected in this conference.  I suppose this message will only
  76. prolong the latest outbreak; ho hum.
  77.  
  78. Andrew.
  79.