home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / forth / 3030 < prev    next >
Encoding:
Text File  |  1992-08-25  |  2.9 KB  |  71 lines
  1. Newsgroups: comp.lang.forth
  2. Path: sparky!uunet!starnine!mikeh
  3. From: mikeh@starnine.com (Mike Haas)
  4. Subject: Re: Free Forth
  5. Message-ID: <BtKI2F.LA3@starnine.com>
  6. Sender: mikeh@starnine.com (Mike Haas)
  7. Date: Wed, 26 Aug 1992 01:42:14 GMT
  8. References: <14487@mindlink.bc.ca>
  9. Organization: StarNine Technologies, Inc.
  10. Lines: 59
  11.  
  12. In article <14487@mindlink.bc.ca> Nick_Janow@mindlink.bc.ca (Nick Janow) writes:
  13. >mikeh@starnine.com (Mike Haas) writes:
  14. >
  15. >> I would propose that "platform-oriented" Forths (which I take to mean a Forth
  16. >> that is designed to mate particularly well with a particular operating
  17. >> system) should not care at all about their size.
  18. >
  19. >I think that's going a bit too far.  Having no regard for size usually leads to
  20. >sloppiness, and all the problems that go with it: slow, buggy, difficult to
  21. >read, maintain or understand...
  22.  
  23. Agreed.  I suppose "not care at all about their size" can have some
  24. pretty negative conotations.
  25.  
  26. In the 'ole' days, when every personal machine was almost an imbedded
  27. system unto itself :), i.e. max 64K, no file system, or one that
  28. didn't raise any eyebrows if you lived without (via SCREENS), there
  29. was much emphasis on cramming stuff in small places.
  30.  
  31. In this day & age, where 640K seems like a little, I think this
  32. attitude is wasted effort.
  33.  
  34. Of course, for true imbedded controller work (where Forth is very
  35. happy), the old postulates still apply.  Lean & mean & worth every
  36. drop of sweat to get there.
  37.  
  38. But I was addressing "platform-oriented" Forths.
  39.  
  40. >
  41. >I agree that 4K kernels are going too far in the other direction; minimal size
  42. >shouldn't be a major priority, though I think it should be a concern.  A
  43. >word--or program--that is no larger than it needs to be is elegant, and it
  44. >carries with it many benefits: robustness, ease of understanding and
  45. >applying...
  46.  
  47. Yes, but I didn't say "larger than necessary".  I meant that
  48. for a powerful platform development system, not increasing the size 
  49. of the Forth should never take precedence over adding useful, powerful tools.
  50.  
  51. No one should be ashamed if their platform-Forth is over 200K in size,
  52. if it's an amazing piece of work.
  53. >
  54. >> As long as larger size resultss from increased functionality (a more powerful
  55. >> Forth) I'll gladly make that trade.
  56. >
  57. >Yes, if the development system is considered a workshop, adding fine tools is a
  58. >worthwhile trade-off for size.  Power tools, such as a power planer, can also
  59. >be worth the extra size, handling the "grunt work" of software development.
  60. >However, simply offering lots of tools of low quality is not a worthy
  61. >trade-off.  I've encountered cheap tools before, and I don't want them.
  62.  
  63. I'm not talking about  low-quality tools... it goes without saying that
  64. they are of no value, small or not.
  65.  
  66. I WAS addressing the philosophical differences between developing for
  67. a platform and developing a standalone, imbedded product.  
  68.  
  69. For me, Inferior tools are never a component in the equation.
  70.  
  71.