home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / shell / 3740 < prev    next >
Encoding:
Internet Message Format  |  1992-09-01  |  3.2 KB
  1. Xref: sparky comp.unix.shell:3740 comp.unix.questions:10616
  2. Path: sparky!uunet!olivea!decwrl!sdd.hp.com!caen!sol.ctr.columbia.edu!eff!news.oc.com!convex!tchrist
  3. From: tchrist@convex.COM (Tom Christiansen)
  4. Newsgroups: comp.unix.shell,comp.unix.questions
  5. Subject: Re: Shell Scripts vs. C programs
  6. Keywords: shell script, C
  7. Message-ID: <1992Sep1.193533.26251@news.eng.convex.com>
  8. Date: 1 Sep 92 19:35:33 GMT
  9. References: <1992Sep1.044434.7193@news.acns.nwu.edu> <121@steiny.com> <1992Sep1.173604.15563@u.washington.edu>
  10. Sender: usenet@news.eng.convex.com (news access account)
  11. Reply-To: tchrist@convex.COM (Tom Christiansen)
  12. Organization: Convex Computer Corporation, Colorado Springs, CO
  13. Lines: 46
  14. Originator: tchrist@pixel.convex.com
  15. Nntp-Posting-Host: pixel.convex.com
  16. X-Disclaimer: This message was written by a user at CONVEX Computer
  17.               Corp. The opinions expressed are those of the user and
  18.               not necessarily those of CONVEX.
  19.  
  20. From the keyboard of donn@carson.u.washington.edu (Donn Cave):
  21. :I have wondered if it would be possible to develop a reasonably usable shell
  22. :language that would have "software engineering" features for writing large
  23. :systems.  For me, that would mean some level of typing, structured types,
  24. :functional scoping, and some way to deal with code in separate modules,
  25. :but I'm sure there's more to it if one were to consult some standard texts
  26. :on this issue.  Would be nice to be able to create somewhat complex data
  27. :types, e.g., trees, and store "pointers" to functions, but not necessarily
  28. :the way C does it, maybe more like Lisp.  It would of course need to be
  29. :able to run fairly efficient code.  Seriously, it would also want to have
  30. :a little style, rather than being a grab-bag amalgam of every known
  31. :programming language, which can impair readability.  (Tom, I'm not hostile
  32. :to perl, so don't be bashful about saying perl has all of these things and
  33. :more, but jeez it looks messy.)  My rather simplistic attitude is that good
  34. :code can be fiddled with in one place, without unanticipatable side effects
  35. :in other places.
  36. :
  37. :If there's any advantage to such a thing, over C, it would be the sort of
  38. :padded environment that allows programs to be written fairly quickly without
  39. :worrying about dereferencing null pointers and things like that.  Ideally,
  40. :it would also be possible to convert straight to C without much re-design,
  41. :so it could be used for prototyping.
  42.  
  43. Who me, bashful?  :-) Your criteria do describe perl rather well.  
  44.  
  45. Of the things you mention, perl is not big on types, structured or
  46. otherwise.  You can do it, but it's not much fun.  I believe this will 
  47. be ameliorated in perl5.  Of the things you mentioned, what perl does 
  48. do well is:
  49.  
  50.     shell-style language w/ software engineering features for writing
  51.     large programs, as follows...
  52.     functional scoping (i think -- what does functional mean here?) 
  53.     code in separate modules (protected namespaces, module init code) 
  54.     pointers to functions 
  55.     fairly efficient code 
  56.     quick protoyping 
  57.     no worries on null pointers
  58.  
  59. --tom
  60.  
  61. -- 
  62.     Tom Christiansen      tchrist@convex.com      convex!tchrist
  63.  
  64.  "Unix is simple, but it takes a genius to understand the simplicity."
  65.                 --Dennis Ritchie
  66.