home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / forth / 3119 < prev    next >
Encoding:
Internet Message Format  |  1992-09-14  |  7.2 KB
  1. Path: sparky!uunet!gatech!pitt!willett!ForthNet
  2. From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
  3. Newsgroups: comp.lang.forth
  4. Subject: Forth in the Marketplace
  5. Message-ID: <4055.UUL1.3#5129@willett.pgh.pa.us>
  6. Date: 14 Sep 92 11:46:01 GMT
  7. Organization: EIEI-U
  8. Lines: 142
  9.  
  10. Category 2,  Topic 11
  11. Message 128       Sun Sep 13, 1992
  12. S.BAKER41 [S.E.Baker]        at 18:04 EDT
  13.  
  14. Bob,
  15.  
  16. Hello.  I'm not new to the forum but I have been in "lurker" mode most of the
  17. time.  :-)  Your post struck a nerve with me; hence this reply.
  18.  
  19. > Trying to persuade people to try Forth is psychological stuff.
  20.  
  21.         Well.  Maybe.  I first acquired a copy of F-PC about 3 years ago. 
  22. I've looked at it extensively and gone thru both "Thinking Forth" and "Forth:
  23. A Text and Reference".  Then I bought a copy of HS-Forth and tried working
  24. with it.  To date I have been unable to produce a single useful program with
  25. either one.  The learning curve is far too steep and the file handling
  26. abilities are worse than useless.  No wonder Forth is thought of as useful
  27. ONLY for imbedded systems!  Until this is dealt with there will be NO
  28. acceptance in the programming comunity, at large.  Some months ago I purchased
  29. an upgrade of HS-Forth as I was promised a set of "comprehensive" examples. 
  30. What I received was nothing of the kind!  To make matters worse, that product
  31. came with a couple of editors which are both simply awful.  IMO, there is
  32. simply no excuse for this whatever. Mr. Zimmer's editor in F-PC is greatly
  33. superior and I didn't pay several hundred dollars for it either.  It is,
  34. however, a sequential file system which seems to be hard for many Forthers to
  35. accept.
  36.  
  37. > Most of us are too involved in Forth and haven't backed off
  38.  > and looked at Forth through non Forth eyes.
  39.  
  40.         That is about the most true statement that I have ever read. If anyone
  41. in this conference is serious about a generally accepted Forth then they had
  42. better start listening to those of us who have attempted to (and seriously
  43. want to) move into Forth with little or no success.
  44.  
  45. > FLOATING POINT default with a toggle words called FLO and INT.
  46.  
  47.         That would be ok but I would suggest a simpler answer.  For the
  48. beginner it would be great to simply have floating point words; "ADD", "SUB",
  49. MUL", "DIV" and maybe "SQUARE", "SQROOT", etc.  Yes, I know that this is very
  50. "COBOL-like" -- deliberately so.  If you can make a COBOL programmer
  51. comfortable with a transition into Forth then you will see the language gain
  52. acceptance.  Converting him to more brief words can be accomplished later.
  53.  
  54. >                    RPN is controversial
  55.  
  56.         Why?  I see no reason for this to be a problem.  It is easily learned
  57. and the value becomes obvious to anyone who learns the use of stacks.
  58.  
  59. > and then compile it.  Type RPN and you simply go back to usual
  60.  > RPN entry.
  61.  
  62.         Please don't waste time worrying about this!  There are far bigger
  63. holes in Forth that simply MUST be plugged before it is a "language".  Right
  64. now, IMO, Forth is a piece of a language.  I won't be able to make use of it
  65. until it becomes whole.
  66.  
  67. > Sequential files with a toggle between .SEQ and .BLK files.
  68.  
  69.         So what!  The vast majority of languages use sequential source files. 
  70. This attachment to block files is pointless and amounts to separatism - a need
  71. to be different for the sake of difference.  It also makes source code occupy
  72. far too much disk space / memory.
  73.  
  74. > Error resistance and compiler security.
  75.  
  76.         ABSOLUTELY!  It is far more important that the compiler trap errors
  77. than it is that the editor use blocks.  Any good compiler starts with a scan
  78. for syntactical errors and refuses to continue until they are dealt with.  In
  79. COBOL a missing "," causes havoc.  In Forth a missing ";" does also.  The more
  80. effective this scan can be made, the better.
  81.  
  82. > Lots of Examples.  Three examples per concept at a minimum.
  83.  
  84.         Yes.  Better yet - complete programs which demonstrate the language
  85. and provide tutorial assistance.  If a tutorial can be written which actually
  86. produces a useful result - say a General Ledger or some such thing - that
  87. would be even better.
  88.  
  89. > Sound and color.
  90.  
  91.         Certainly color is important in a PC environment.  Sound is a nice to
  92. have (beyond "beep") but not critical to a basic Forth.
  93.  
  94. > DOCUMENTATION; Use the resources of the machine!  The compiler
  95.  > doesn't do anything with numbers above 127, so use control-C to
  96.  
  97.         NO!  I want to be able to write software for use throughout the world.
  98. If you shut down access to special characters you make translation to other
  99. languages impossible.  Program documentation is an editor function.  Simply
  100. run two parallel files or use the characters from 80 thru 159 on each line for
  101. documentation.  ^-Tab could be used to switch between the areas.  Better yet,
  102. a split screen which has the documentation lines in the upper half and the
  103. source code in the lower.
  104.  
  105.         Now, to the missing elements.  Before I, or any other "real world"
  106. programmer can use Forth it MUST have useful file handling. (Pun intended)  I
  107. need to be able to quickly and accurately create ISAM or similar multiply
  108. indexed data files on a PC.  This would be very easy for an experienced
  109. Forther to write - for me it has been a nightmare!  The problem is so bad that
  110. I have abandoned FORTH in favor of C.  There is no way that I am going to use
  111. Forth if file handling for real world applications is not addressed in the
  112. standard.  How the words are implemented on each machine is not an issue. 
  113. But, the standard words must be defined so that I can depend on stability for
  114. future products.  I will not waste the resources training my programmers to
  115. use a language which is shifting under their feet.  Nor will I use a language
  116. which I must complete first. All I am asking for is the defined ability to use
  117. something akin to the following:
  118.  
  119. : MYFILE
  120.  nnn   FILE  myfile        ( where nnn is the record length and
  121.                           ( "myfile" is the file name. )
  122.  nn t  FIELD first-field   ( where nn is the field length, "t" is the
  123.                           ( field type and
  124.                           ( "first-field" is the field name )
  125.  ....
  126.  
  127. nn t  FIELD last-field    ;
  128.  
  129.         The defined fields should then be available as variables under their
  130. own names.  An index can be indicated with a special word to replace FIELD.  A-
  131. INDEX for the primary and B-INDEX, C-INDEX for additionals, maybe. Or, PR-
  132. INDEX for primary, AU-INDEX for alt- unique and AD-INDEX for alt-duplcates.  I
  133. really don't care.  I then want to be able to OPEN-FILE myfile, READ myfile,
  134. WRITE myfile, etc. The alied word PATH is needed on the PC and many other
  135. systems as well.  I realize that these exist in one form or another in various
  136. Forths.  However, this is not adequate.  Standardization is critical.  Without
  137. it I WILL NOT INVEST RESOURCES IN FORTH.  I strongly suspect that this has
  138. something to do with the rapid abandonment of Forth by defense and space
  139. agencies and contractors.
  140.  
  141. Best regards,
  142.  Stephen E. Baker
  143.  President
  144.  Baker Software Products Corp.
  145.  Indianapolis
  146.  
  147. -----
  148. This message came from GEnie via willett.  You *cannot* reply to the author
  149. using e-mail.  Please post a follow-up article, or use any instructions
  150. the author may have included (USMail addresses, telephone #, etc.).
  151. Report problems to: dwp@willett.pgh.pa.us
  152.