home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / forth / 3967 < prev    next >
Encoding:
Text File  |  1993-01-23  |  3.1 KB  |  68 lines
  1. Newsgroups: comp.lang.forth
  2. Path: sparky!uunet!starnine!mikeh
  3. From: mikeh@starnine.com (Mike Haas)
  4. Subject: Re: Forth's Adaptability
  5. Message-ID: <C1AFnC.Ls9@starnine.com>
  6. Sender: mikeh@starnine.com (Mike Haas)
  7. Date: Sat, 23 Jan 1993 03:42:47 GMT
  8. References: <1993Jan18.163733.19857@crd.ge.com> <1993Jan19.085827.18730@Informatik.TU-Muenchen.DE> <1993Jan19.202421.14156@crd.ge.com>
  9. Organization: StarNine Technologies, Inc.
  10. Lines: 56
  11.  
  12. In article <1993Jan19.202421.14156@crd.ge.com> eaker@ukulele.crd.ge.com (Chuck Eaker) writes:
  13. >In article <1993Jan19.085827.18730@Informatik.TU-Muenchen.DE>, pazsan@Informatik.TU-Muenchen.DE (Bernd Paysan) writes:
  14. >|> In article <1993Jan18.163733.19857@crd.ge.com>, eaker@ukulele.crd.ge.com (Chuck Eaker) writes:
  15. >|> |> ...                                        C is less
  16. >|> |> flexible? In what sense? ... Use a memory heap if you want.
  17. >|>
  18. >|> Show me the C library with a real dynamic memory management that
  19. >|> prevents splitting the available memory until you can't get any
  20. >|> more without paging. Don't tell me "I always include half of the
  21. >|> GNU emacs project to have this".
  22. >
  23. >The fact that there are implementations of C with inefficient
  24. >dynamic memory packages is not a reason to reject C in favor
  25. >of Forth. That fact that virtually every implementation of C
  26. >comes with a rather standard dynamic memory management package
  27. >and has for years whereas there is as yet no such Forth standard
  28. >is a good reason for rejecting Forth in favor of C.
  29.  
  30. Not to mention that one of the jobs of a good OS is to hide the
  31. details of dynamic memory management from the application, which
  32. fundamentally only needs to allocate & free memory.
  33.  
  34. An application should not have to worry about fragmenting, swap
  35. files, "splitting memory"...only whether it's memory request was
  36. completed successfully or not.
  37.  
  38.  
  39. >
  40. >Competitive pressures in the software industry are making it
  41. >more and more difficult for us to spend time climbing up
  42. >learning curves. And those pressures will be getting worse
  43. >very quickly. That's the main reason why a comprehensive
  44. >standard is so important.
  45. >
  46. >I would much rather use Forth in my work, but I can't afford
  47. >to take the time to implement all the missing pieces or search
  48. >for them in other people's work and port them into my environment.
  49.  
  50. Chuck, I think you have stated the needs of the average professional
  51. computer user well.   Many in the Forth community seemed satisfied
  52. with Forth as it was 15 years or more ago...and it hasn't substantially
  53. changed.  Perhaps their needs haven't changed much in that time, and that;s
  54. all well and good.  But there is so much resistance to introducing
  55. concepts that are now fairly standard in the rest of the computing
  56. universe that I have grown quite doubtful that Forth will succeed in
  57. the popular sense.
  58.  
  59. Forth believers, IMHO, are today looked at in the same way as
  60. those that exclusively use BASIC, Commodore 64's, CP/M, etc.
  61. It's viewed as old technology that has failed to adapt.
  62. >
  63. >-- 
  64. >Chuck Eaker / P.O. Box 8, K-1 3C12 / Schenectady, NY 12301 USA
  65. >eaker@crd.ge.com        eaker@crdgw1.UUCP       (518) 387-5964
  66.  
  67.  
  68.