home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / forth / 3968 < prev    next >
Encoding:
Internet Message Format  |  1993-01-23  |  2.5 KB
  1. Path: sparky!uunet!usc!news.cerf.net!nic.cerf.net!duncan
  2. From: duncan@nic.cerf.net (Ray Duncan)
  3. Newsgroups: comp.lang.forth
  4. Subject: Re: Forth's Adaptability
  5. Date: 23 Jan 1993 03:29:25 GMT
  6. Organization: CERFnet Dial n' CERF Customer Group
  7. Lines: 41
  8. Message-ID: <1jqe2lINNiv8@news.cerf.net>
  9. References: <1993Jan20.150614.20069@crd.ge.com> <1jk69lINNhjo@news.cerf.net> <BEVAN.93Jan22131846@panda.cs.man.ac.uk>
  10. NNTP-Posting-Host: nic.cerf.net
  11.  
  12. In article <BEVAN.93Jan22131846@panda.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes:
  13. >In article <1jk69lINNhjo@news.cerf.net> duncan@nic.cerf.net (Ray Duncan) writes:
  14. >   It is a mistake to judge the "Forth community" by the public
  15. >   domain implementations of Forth.  People who insist on using
  16. >   public domain Forths and reinventing the wheel time after time
  17. >   get what they paid for.
  18. >
  19. >Agreed, but :-
  20. >
  21. >   [ LMI FORTH has files & blocks, floating point ... etc. ]
  22. >
  23. >   they've [LMI users] had access to these capabilities, if they
  24. >   needed them, for many years.    
  25. >
  26. >And I'm sure they are happy with them, but consider what happens if
  27. >they decide, for one reason or another, that they don't want to use
  28. >LMI FORTH anymore, but prefer to use a different vendor's system.
  29. >What are they to do with all the code they've developed using LMI
  30. >specific extensions?  Unless the "extensions" are either standard or
  31. >defacto standards then there may be significant effort involved in
  32. >changing the code, so much so you may have to stick with the system
  33. >you have even though you know you can get better/cheaper elsewhere
  34. >(I've suffered just this situation with large amounts of code written
  35. >using VAX FORTRAN + extensions).  This is good for vendors since it
  36. >keeps users locked into their system, but it is definitely not a good
  37. >deal for users.
  38.  
  39. I must admit I don't quite see your point.  At the time we added
  40. these capabilities to our systems, they were relatively novel in
  41. the Forth world.  Certainly, nothing in the standards of the time
  42. (polyForth, Forth-79, Forth-83, figForth) spoke to these issues.
  43. Does that mean our users should have gone without these capabilities
  44. until the Forth standards-body-du-jour got around to codifying
  45. these capabilities?  Forget it!  I could just as easily make the
  46. argument that the reason the ANSI committee is in a position to
  47. standardize file management, memory management, floating point,e tc.
  48. is that companies like LMI (and their customers) were willing to
  49. prove the usefulness of these capabilities in real-world
  50. applications.
  51.  
  52.  
  53.