home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / shell / 3780 < prev    next >
Encoding:
Internet Message Format  |  1992-09-02  |  6.7 KB
  1. Path: sparky!uunet!olivea!decwrl!sdd.hp.com!elroy.jpl.nasa.gov!usc!news!netlabs!lwall
  2. From: lwall@netlabs.com (Larry Wall)
  3. Newsgroups: comp.unix.shell
  4. Subject: Re: Shell Scripts vs. C programs
  5. Message-ID: <1992Sep2.191012.22859@netlabs.com>
  6. Date: 2 Sep 92 19:10:12 GMT
  7. References: <121@steiny.com> <1992Sep1.173604.15563@u.washington.edu> <FRIEDMAN.92Sep2045423@nutrimat.gnu.ai.mit.edu>
  8. Sender: news@netlabs.com
  9. Organization: NetLabs, Inc.
  10. Lines: 128
  11. Nntp-Posting-Host: scalpel.netlabs.com
  12.  
  13. In article <FRIEDMAN.92Sep2045423@nutrimat.gnu.ai.mit.edu> friedman@gnu.ai.mit.edu (Noah Friedman) writes:
  14. :    I've been thinking about this for awhile, especially since I started
  15. : using perl.  Having a tool like perl is the right idea for typical unix
  16. : applications, filters and so forth---fork is expensive and it's not going
  17. : to get better any time soon (vfork is *still* better than a plain COW fork
  18. : implementation), and exec is even worse---but perl's grammar and design is
  19. : totally broken (sorry, Larry).
  20.  
  21. Don't apologize.  Perl's grammar is totally broken on purpose.  It's
  22. just that it's slightly *less* totally broken than Unix's grammar.  :-)
  23.  
  24. Perl is nothing more or less than Pidgin Unix.
  25.  
  26. (That being said, you might be interested to know that Perl 5's yacc grammar
  27. is (at the moment) only 60% the size of Perl 4's.)
  28.  
  29. : The reason why people complain about perl
  30. : having the kitchen sink is that it has no uniform design; instead there is
  31. : a grab bag of features that look hastily adopted from other programs like
  32. : sed, awk, and grep, none of which are very orthogonal.
  33.  
  34. Yes, the features were adopted, but they weren't *hastily* adopted.
  35. An enormous amount of thought went into blending many things that
  36. people are familiar with, in such a way that they still generally do
  37. what people expect.  That was hard work!  Certainly there are some
  38. things that I'd do different if I had them to do over, but on the whole
  39. *I* like what I have so far.  If it makes other people happy, all the
  40. better.
  41.  
  42. Let me say a thing about orthogonality.  It's great for instruction
  43. sets.  It's not so good for human languages.  Many humans seem to
  44. prefer to learn a richer language that lets them be more expressive.
  45. They like it when there's already a word for what they're thinking.
  46. Would you rather write assembly language in VAX or in SPARC?
  47.  
  48. : There are various annoying context-dependent misfeatures in perl as well,
  49.  
  50. Give me a list, and I'll tell you which ones I'm fixing in Perl 5,
  51. and which ones aren't misfeatures.  :-)
  52.  
  53. : and multi-dimensional/nested arrays are cumbersome (the associate array
  54. : features in awk are much easier to deal with).
  55.  
  56. Huh?  Perl's associative arrays are almost exactly like awk associative
  57. arrays.  I don't see your point.  (But before you explain, I should
  58. point out that in Perl 5 (getting tired of that yet? :-) it will be easy
  59. to nest arrays.)
  60.  
  61. : Perl also suffers from
  62. : being too redundant---there are tons of gratuitous looping constructs that
  63.  
  64. Which "gratuitous" looping construct would you get rid of, and why?
  65. I can't think of one I could get rid of without making me immensely
  66. unpopular.  The weakest component is the continue block, and that's there
  67. so we can define the for (;;) loop rigorously.
  68.  
  69. : give programmers lots of different ways to write the same thing and
  70. : decrease readability without actually increasing the functionality of the
  71. : language (using "unless" and violating the general condition->consequent
  72. : order of expression is evil, especially since this is not a fundamental
  73. : paradigm of the language).
  74.  
  75. That's a base canard!  Having several ways to say things does NOT
  76. decrease readability.  It lets you say the important thing first.
  77. Tell me, would you rather read something written by a lawyer, or
  78. by an essayist?  It's the lawyers who must keep their "whereases" in
  79. order.  The essayists are free to speak their minds the way they think.
  80.  
  81. That's why people enjoy writing Perl.  It "lays under the fingers",
  82. as a musician would say.
  83.  
  84. Personally I think if/unless/while/until is an example of orthogonality
  85. that is MISSING from your typical computer language.  Didn't it ever
  86. bother you that Pascal had
  87.  
  88.     while CONDITON do STATEMENT
  89.     do STATEMENT until CONDITION
  90.  
  91. Why should the positioning of the exit condition invert the value of
  92. the test?  To C's credit it uses the same thing on both ends.  But many
  93. people don't think "if not CONDITON then STATEMENT" though.  They think
  94. "STATEMENT unless CONDITION", or they deMorganize the CONDITION to get
  95. rid of the "if not", or reverse the then and the else, or use an
  96. operator with a negative notion built in.  Inverting the logic based on
  97. the presence or absence of a single ! is borderlinedly unreadable in my
  98. book.  Forcing folks to say things like "if (!noglob)" is Bad Design.
  99. In English, "if not" is usually a synonym for "otherwise".
  100.  
  101. : The idea of function calls being lvalues I find to be unaesthetic as well.
  102.  
  103. They aren't in general.  I'm not sure what you're driving at here.
  104.  
  105. : Perl has lexical scoping, compilation, a package system for 
  106. : separating namespaces, and "modules" to its credit, however.
  107.  
  108. Lexical scoping isn't until Perl 5.  Currently Perl uses dynamic scoping.
  109.  
  110. : And it's actually powerful enough to do most of the things you
  111. : could ever want in a single process, avoiding the aforementioned fork+exec
  112. : overhead.  Perl as a general purpose interpreter is no worse than any other
  113. : language interpreter, so I think most of the objections made by "unix
  114. : purists" are off base.  They should not be complaining about perl's
  115. : functionality; they should be complaining about its design.
  116.  
  117. Well, they do complain about its design.  But as I said, I have different
  118. goals.  I wasn't trying to do what *they've* been taught a language designer
  119. should do.  But then, *they* keep trying to do that, so why should I?
  120.  
  121. There are some advantages to coming out of left field.  I don't claim
  122. to be perfect (I believe "far from it" is the technical term), but I do
  123. know what I like, and have the gumption to do something about it.  Most
  124. people don't realize they can change the world.  Most people don't
  125. realize they can change ME.  Sometimes even I forget.  :-)
  126.  
  127. : [Scheme musings omitted.]
  128. : 
  129. :    You'd also want to write a library of commonly used subroutines to do
  130. : various kinds of field splitting, pattern substitution, and so on.
  131. : Although the way you actually do it is bletcherous, one of perl's selling
  132. : points is that you can *quickly* write routines to get the job done.
  133. : Unless you can do the same sorts of things with relative ease in a Scheme
  134. : system, it won't be good enough to replace perl.
  135.  
  136. The question before the house is whether Perl's facility is intrinsically
  137. bound to its bletchery.  Incorrect answers include both "yes" and "no".
  138.  
  139. Larry Wall
  140. lwall@netlabs.com
  141.