home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / perl / 5816 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  4.0 KB
  1. Path: sparky!uunet!dtix!mimsy!folta
  2. From: folta@cs.umd.edu (Wayne Folta)
  3. Newsgroups: comp.lang.perl
  4. Subject: Re: How to convice awk/sed users to use Perl ?
  5. Keywords: na
  6. Message-ID: <60213@mimsy.umd.edu>
  7. Date: 9 Sep 92 23:08:42 GMT
  8. References: <1992Sep9.143629.13571@cbfsb.cb.att.com>
  9. Sender: news@mimsy.umd.edu
  10. Distribution: na
  11. Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
  12. Lines: 71
  13.  
  14. >   I  use ksh/awk/sed very well, why bother to spend a lot of time to learn Perl ?
  15. >   What's the real advantages of perl over ksh/awk/sed ?
  16. >
  17. >I will appreciate any help.
  18.  
  19. I am making the same sale so far myself. I have already sold the major awk
  20. guru in my organization on perl. My reasoning is:
  21.  
  22.    1. Using [ck]?sh/n?awk/sed is precisely that: using several programs in
  23.       conjunction. Most often, a shell script with multiple assists by awk
  24.       and sed. This results in either several separate files or else shell
  25.       scripts with crazy numbers and combinations of \'s.
  26.  
  27.       Often, awk/sed is nearly enough, by itself, but you are forced to add
  28.       a shell script wrapper to tie things together, introducing an extra
  29.       level of complexity.
  30.  
  31.       And don't forget that you don't just use a shell+awk+sed. You also have
  32.       to throw in all of the programs that the shell has to call because it
  33.       is wimpy: find, grep, tr, ls, ... All it takes is a user with a funny
  34.       path and things go broke. Or port your shell script to another system
  35.       that has something nonstandard, and broke.
  36.  
  37.    2. Shells do not compile their scripts at runtime, but instead run through
  38.       them repeatedly. This makes shell scripts slower and also creates the
  39.       possibility of run-time syntax errors. You don't find these errors until
  40.       your logic flow takes you through the erroneous path. Since perl compiles
  41.       its scripts, if you get it to run at all, you won't encounter a syntax
  42.       error later. And perl is *fast*.
  43.  
  44.       Speaking of speed, remember that shell+awk+sed+find+tr+ls... scripts
  45.       involve a boatload of fork/execs to run. Slow.
  46.    
  47.    3. Shells do not have debuggers, only verbose modes. Perl has a debugger
  48.       much like you'd use for debugging C. (Same arg against awk, sed.)
  49.  
  50.    4. If you use a shell+awk+sed, you need to learn three different syntaxes
  51.       (for example, loops in awk versus loops in shell) on top of any other
  52.       programming language you might use (say, C). Perl has a unified syntax
  53.       and hence avoids this problem.
  54.    
  55.    5. If you use shell+awk+sed, you are using three different tools that are
  56.       not tightly coupled. Thus, you may run an awk script and take advantage
  57.       of its spiffy associative arrays, but there is no way to get that info
  58.       back to a shell script or into a sed script. You are forced to do things
  59.       multiple times, to store intermediate information in files, or to lose
  60.       information anyhow. (Most often, you settle for sending less information
  61.       than you could, in order to keep things simple.)
  62.  
  63.    6. Perl allows you to do things you always wished you could. How many times
  64.       have you had a nifty sed script and wished that you could throw just one
  65.       awk/shell/C construct into it? The same goes for awk and even C.
  66.  
  67.    7. Format. It is *much* easier to generate a report that looks like you want
  68.       it to and aligns columns/titles with perl's format output ability. Trying
  69.       to align things with %s is frustrating and tedious.
  70.    
  71.    8. Message Queues, Shared Memory, Semaphores, Sockets. Perl does them and the
  72.       others don't. Makes interfacing with programs much easier.
  73.    
  74.    9. Security. Perl has security checking for setuid scripts that shells cannot
  75.       match (if they can even honor setuid scripts). Perl also has many more
  76.       built-in commands, so it doesn't depend on external programs and
  77.       utilities that may or may not be trustworthy.
  78.    
  79.   10. Shells, sed, and awk are dead. You will no longer see any improvements in
  80.       them, no matter how glaring the need. Perl is alive and kicking.
  81. -- 
  82.  
  83.  
  84. Wayne Folta          (folta@cs.umd.edu  128.8.128.8)
  85.