home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / forth / 2849 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  5.1 KB
  1. Path: sparky!uunet!gatech!destroyer!sol.ctr.columbia.edu!emory!uumind!overmind!ukulele.crd.ge.com.citadel!News
  2. From: ukulele.crd.ge.com!eaker@overmind.mind.org
  3. Newsgroups: comp.lang.forth
  4. Subject: Re: Down with free Forth systems.
  5. Message-ID: <2178699@overmind.citadel>
  6. Date: 23 Jul 92 03:39:00 GMT
  7. Organization: GE CR&D Computer Science Program
  8. Lines: 90
  9. X-mailer: Stadel 3.4a-227
  10. X-Spam-content: irrelevant
  11.  
  12. I think it is worthwhile to distinguish between systems that are free
  13. (or inexpensive) and systems that are professionally developed.
  14. C and Pascal were both of these. A large number of Forth systems are
  15. neither and I know of no other language for which popular implementations
  16. are free and were developed by people who were paid nothing to do it.
  17.  
  18. Both C and Pascal were both developed by teams of professionals whose
  19. jobs were to create such things. The circumstances of their development
  20. were such that both were widely distributed to academic institutions at
  21. very low cost. This was a unique window of opportunity which I doubt
  22. will ever be open again.
  23.  
  24. For the C compilers, support, of sorts, existed from the very beginning.
  25. This was rarely true for Pascal. I recall teaching with a Pascal
  26. compiler running on a Burroughs 6800 (for which there was no documented
  27. assembly language - Burroughs used Algol for their systems work) which
  28. had wandered to our campus from God only knows where and, along the way
  29. had picked up numerous idiosyncracies and exasperating bugs. This
  30. experience led many of us to develop very bad attitudes about free
  31. software: it was free to get in, but you paid the price over and over
  32. in lost productivity.
  33.  
  34. The answer, it seemed, was to be found in using software that was so
  35. open that we could maintain it ourselves, or getting rich and paying
  36. someone whose reputation and nourishment depending on our being
  37. happy with a programming environment.  So, some of us, not being rich,
  38. tried Forth, but we discovered a basic principle: the more time you spend
  39. maintaining your tools, the less time you have to actually use them.
  40.  
  41. The moral of all of this is that I believe the following:
  42. Every "successful" language was professionally developed
  43. and is commercially supported. Furthermore, the commercial
  44. support comes from at least one big player who is going to be maintaining
  45. the language and holding hands over the long haul.
  46. (By "successful", I mean something which is used by lots of people,
  47. a high percentage of which are trying to learn something or make money.)
  48.  
  49. Consequently, free Forth systems will (still) go nowhere. But, there
  50. is no commercial enterprise in the Forth arena big enough to generate 
  51. much momentum, so I don't think non-free Forth systems will ever
  52. serve more than a very small but very intense minority of users.
  53.  
  54. Unless....
  55.  
  56. Try this. Develop Forth++ which will operate in a Unix environment.
  57. Define Forth++ words which take the name of a (preferably C++) library
  58. (such as some of the X libraries) and links the library into the Forth++
  59. environment so that a user can interactively list the classes, functions,
  60. etc. provided by the library, create instances, execute methods, and
  61. generally perform reckless experiments quickly and cheaply in the manner
  62. that, for me, is the essence of Forth.
  63.  
  64. C++ will be around for a long time. Many companies have huge investments
  65. in infrastructure that enrich the C++ environment in ways that
  66. dramatically increase productivity. None of GE's software intensive
  67. components would use anything other than a language such as C++ that
  68. does early binding to generate production code. But that requirement
  69. means that, at present, we are trapped in the compile, link, load,
  70. run, swear, edit, compile, ... cycle, and the cycle is verrrrrrrrrrrry
  71. long.
  72.  
  73. Off the shelf class libraries provide incredible leverage, but they
  74. are stupifyingly complex and the documentation is enormous but still
  75. incomplete. It takes forevvvvvvvvvvver, to create and run a little
  76. program that will give you an answer to how this little widget
  77. behaves when you do this weird thing with it that isn't mentioned
  78. anywhere in the documentation. If I had Forth++ running in another
  79. window, I could significantly increase my productivity.
  80.  
  81. Devise a Forth++ vocabulary and syntax that I could use for interactive
  82. development and a tool that will translate Forth++ to C++ which
  83. I can then compile and link the object file into Forth++ so that I
  84. can continue development then translate ...
  85.  
  86. In my opinion the proposed standard has more than captured the essence
  87. of Forth. What Forth needs is a way to capture other standards.
  88. There are lots of common, well known, libraries out there that
  89. tens of thousands of professionals are familiar with. They are
  90. using them to leverage themselves into positions of power from
  91. which they can develop sophisticated software quickly and 
  92. cheaply. Forth can never hope to match this achievement on its own.
  93.  
  94. Beat your standards warfare swords into plowshares and figure out
  95. how to use them to break new ground by giving Forth the ability
  96. to swallow whole the work of others and make it available in the
  97. interactive way that we all know and love.
  98.  
  99. -- 
  100. Chuck Eaker / P.O. Box 8, K-1 3C12 / Schenectady, NY 12301 USA
  101. eaker@ukulele.crd.ge.com                        (518) 387-5964
  102.