home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / shell / 3828 < prev    next >
Encoding:
Internet Message Format  |  1992-09-07  |  2.0 KB
  1. Path: sparky!uunet!olivea!mintaka.lcs.mit.edu!ai-lab!life.ai.mit.edu!friedman
  2. From: friedman@gnu.ai.mit.edu (Noah Friedman)
  3. Newsgroups: comp.unix.shell
  4. Subject: Re: Shell Scripts vs. C programs
  5. Message-ID: <FRIEDMAN.92Sep5050108@nutrimat.gnu.ai.mit.edu>
  6. Date: 5 Sep 92 09:01:08 GMT
  7. References: <121@steiny.com> <1992Sep1.173604.15563@u.washington.edu>
  8.     <FRIEDMAN.92Sep2045423@nutrimat.gnu.ai.mit.edu>
  9.     <1992Sep2.142212.29524@osf.org>
  10. Sender: news@ai.mit.edu
  11. Organization: Free Software Foundation, 675 Mass Ave. Cambridge, MA 02139
  12. Lines: 24
  13. In-reply-to: rsalz@osf.org's message of 2 Sep 92 14:22:12 GMT
  14.  
  15. In article <1992Sep2.142212.29524@osf.org> rsalz@osf.org (Rich Salz) writes:
  16. >In <FRIEDMAN.92Sep2045423@nutrimat.gnu.ai.mit.edu> friedman@gnu.ai.mit.edu (Noah Friedman) writes:
  17. >>fork is expensive and it's not going to get better any time soon ...
  18. >> and exec is even worse
  19. >
  20. >I am totally dismayed and depressed by this attitude:  "The OS isn't fast
  21. >enough so I will glom all the features I might ever need into my program."
  22. >Is it not totally obvious to you that this mindset is BROKEN!?
  23.  
  24.    It's not a matter of broken mindsets.  It's the truth: there is no
  25. incentive for all the unix vendors out there to do anything about it.  Most
  26. of them are just using the Evil One's code anyway.  Besides, how would you
  27. go about making fork faster?  Even with COW pages you have to go mark them
  28. all to get write faults.  In a large process, going through all those pages
  29. still takes time.  Exec is not particularly fast in *any* OS I've ever
  30. used, and my (admittedly limited so far) experience suggests it's a
  31. difficult problem.
  32.  
  33.    And, for the record, I don't think having a lot of functionality in one
  34. program is a bad thing, any more than I think interpreters in general are
  35. bad.  A careful, modular and orthogonal design would make large programs
  36. perfectly reasonable.  Perl is a bad example (and so is GNU Emacs).  Yes,
  37. I'm aware of the problems of program size and complexity.  No one said
  38. careful planning was easy either.
  39.