home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / forth / 3829 < prev    next >
Encoding:
Text File  |  1993-01-13  |  5.2 KB  |  136 lines
  1. Newsgroups: comp.lang.forth
  2. Path: sparky!uunet!starnine!mikeh
  3. From: mikeh@starnine.com (Mike Haas)
  4. Subject: Re: Documenting
  5. Message-ID: <C0ry23.8Dy@starnine.com>
  6. Sender: mikeh@starnine.com (Mike Haas)
  7. Date: Wed, 13 Jan 1993 04:06:02 GMT
  8. References: <C0EoE4.Go3@starnine.com> <1492@eouk9.eoe.co.uk>
  9. Organization: StarNine Technologies, Inc.
  10. Lines: 124
  11.  
  12. In article <1492@eouk9.eoe.co.uk> ahaley@eoe.co.uk (Andrew Haley) writes:
  13. >Mike Haas (mikeh@starnine.com) says that "screens" (by which I presume
  14. >he means blocks used for source code) are viewed by [users of other
  15. >languages] as evidence that Forth will never be a modern language.
  16. >
  17. >Some people may believe this, but it flies in the face of historical
  18. >fact; BLOCK was an innovation.  Every computer OS around at the time
  19. >(1970) supported text files, but Charles Moore invented a different
  20. >method of accessing source text and other data, not because he was
  21. >"old fashioned" but because he thought that he had a better system.
  22.  
  23. Forth uses blocks because it was almost always used in embedded
  24. controllers and on standalone computers which had little or no
  25. operating system.
  26.  
  27. It is nuts to suggest that blocks were implemented because they were
  28. thought superior to text files and to do so is rewriting history.
  29.  
  30. >
  31. >I don't think that people who do not use Forth will be drawn to it if
  32. >we change all our sources to use OS text files; they will carry on
  33. >happily using C or whatever.  The only difference will be that people
  34. >who like to use blocks will no longer have their sources in that
  35. >convenient form.  
  36.  
  37. There is no reason that that should occur.  There are many Forths,
  38. my own JForth included, that support both.
  39.  
  40. >
  41. >There is a great deal of work to be done in getting the interactive
  42. >development tools already used in Forth systems to work with text
  43. >files.  If Forth has any virtue, it is simplicity; rewriting existing
  44. >tools to use text files would greatly complicate things.
  45.  
  46. Not at all.  Simply change the interpreter such that it considers
  47. the end-of-line character or sequence to be another blank character.
  48. (y'know... the unconditional delimeter, most consider TAB, too).
  49.  
  50. That's 99% of what's needed to get a Forth to work with
  51. files.
  52.  
  53. >
  54. >There is too much emphasis in this group on rewriting tools that
  55. >already work very well in order to satisfy the expectations of people
  56. >who are never going to use them.
  57.  
  58. Not using text files will indeed insure that many folks will never use
  59. any Forth tools.
  60.  
  61. >
  62. >I've no idea where the notion that some of [Forth's] major features
  63. >are architected to work best only in embedded controller applications
  64. >comes from; that is contrary to what is known about Forth's history.
  65.  
  66. right.  next?
  67.  
  68. >Much early Forth use at Forth, Inc was in commercial/database
  69. >systems.  They found that blocks work extremely well in that
  70. >environment.
  71.  
  72. Gee, I bet you found that fixed-length records were better
  73. in databases, too.
  74.  
  75. >
  76. >On some platforms, interaction with host operating system files is
  77. >essential; fair enough.  You might even run Forth as a task under
  78. >another OS.  I've done this in many applications, and sometimes it's a
  79. >good solution, but Forth is not a programming language so much as an
  80. >operating system.
  81.  
  82. Forth is not an operating system.  It provides an execution
  83. environment on standalone computers, but it is no operating system.
  84. Nothing but Forth can operate under it's auspices.
  85.  
  86. >The Forth applications I've seen which impressed me
  87. >the most used Forth as the OS.  There are some wonderful multiuser
  88. >databases which use the Forth operating system.
  89.  
  90. Can you point me to one I can use on my Amiga or Mac?  One that
  91. uses some IPC to interface with popular applications?  One that
  92. provides a full GUI with resizeable windows, menus, graphics,
  93. photo-quality storage...
  94.  
  95. >
  96. >It depends on what your goal is.  If it's to get the maximum number of
  97. >Forth users, maybe Mike Haas's route is the best.  If your goal is to
  98. >develop efficient applications on computers (and yes, efficiency is
  99. >still important) then you might choose a different route.
  100.  
  101. Usre of blocks in no way increases one's efficiency.  In fact, it hinders it
  102. because you have to develop all your own print software, backup software,
  103. stuff that normal OS files live easy with.
  104.  
  105. It's a helluva lot easyier to insert a new function in the middle of
  106. your program with files.
  107.  
  108. >
  109. >If the "mainstream" expects a standard set of functions which allow
  110. >one to link with object files from other languages, then by all means
  111. >let's supply one.  But we shouldn't assume that they will use Forth if
  112. >we do.
  113.  
  114. Huh?
  115.  
  116. >
  117. >Those who stay with source blocks don't do so because they don't care
  118. >to "put the work in."  It's because we find that blocks are a good
  119. >solution to the problems we face when developing applications.  If
  120. >some others choose to use text files, that's fine.  I don't want to
  121. >convince others how great blocks are; I just want to explain why _I_
  122. >use them.  
  123. >
  124. >If others prefer text files, that's great, but I resent the
  125. >implication that I haven't moved to text files because of laziness.
  126. >It's because blocks work best for my uses.  If others use text files
  127. >that doesn't bother me at all.
  128. >
  129. >I am very disappointed to see the great "blocks versus files" flame
  130. >war resurrected in this conference.  I suppose this message will only
  131. >prolong the latest outbreak; ho hum.
  132. >
  133.  
  134. naw.
  135.  
  136.