From: folta@cs.umd.edu (Wayne Folta)
Newsgroups: comp.lang.perl
Subject: Re: How to convice awk/sed users to use Perl ?
Keywords: na
Date: 9 Sep 92 23:08:42 GMT
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742

>   I  use ksh/awk/sed very well, why bother to spend a lot of time to learn Perl ?
>   What's the real advantages of perl over ksh/awk/sed ?
>
>I will appreciate any help.

I am making the same sale so far myself. I have already sold the major awk
guru in my organization on perl. My reasoning is:

   1. Using [ck]?sh/n?awk/sed is precisely that: using several programs in
      conjunction. Most often, a shell script with multiple assists by awk
      and sed. This results in either several separate files or else shell
      scripts with crazy numbers and combinations of \'s.

      Often, awk/sed is nearly enough, by itself, but you are forced to add
      a shell script wrapper to tie things together, introducing an extra
      level of complexity.

      And don't forget that you don't just use a shell+awk+sed. You also have
      to throw in all of the programs that the shell has to call because it
      is wimpy: find, grep, tr, ls, ... All it takes is a user with a funny
      path and things go broke. Or port your shell script to another system
      that has something nonstandard, and broke.

   2. Shells do not compile their scripts at runtime, but instead run through
      them repeatedly. This makes shell scripts slower and also creates the
      possibility of run-time syntax errors. You don't find these errors until
      your logic flow takes you through the erroneous path. Since perl compiles
      its scripts, if you get it to run at all, you won't encounter a syntax
      error later. And perl is *fast*.

      Speaking of speed, remember that shell+awk+sed+find+tr+ls... scripts
      involve a boatload of fork/execs to run. Slow.
   
   3. Shells do not have debuggers, only verbose modes. Perl has a debugger
      much like you'd use for debugging C. (Same arg against awk, sed.)

   4. If you use a shell+awk+sed, you need to learn three different syntaxes
      (for example, loops in awk versus loops in shell) on top of any other
      programming language you might use (say, C). Perl has a unified syntax
      and hence avoids this problem.
   
   5. If you use shell+awk+sed, you are using three different tools that are
      not tightly coupled. Thus, you may run an awk script and take advantage
      of its spiffy associative arrays, but there is no way to get that info
      back to a shell script or into a sed script. You are forced to do things
      multiple times, to store intermediate information in files, or to lose
      information anyhow. (Most often, you settle for sending less information
      than you could, in order to keep things simple.)

   6. Perl allows you to do things you always wished you could. How many times
      have you had a nifty sed script and wished that you could throw just one
      awk/shell/C construct into it? The same goes for awk and even C.

   7. Format. It is *much* easier to generate a report that looks like you want
      it to and aligns columns/titles with perl's format output ability. Trying
      to align things with %s is frustrating and tedious.
   
   8. Message Queues, Shared Memory, Semaphores, Sockets. Perl does them and the
      others don't. Makes interfacing with programs much easier.
   
   9. Security. Perl has security checking for setuid scripts that shells cannot
      match (if they can even honor setuid scripts). Perl also has many more
      built-in commands, so it doesn't depend on external programs and
      utilities that may or may not be trustworthy.
   
  10. Shells, sed, and awk are dead. You will no longer see any improvements in
      them, no matter how glaring the need. Perl is alive and kicking.
-- 


Wayne Folta          (folta@cs.umd.edu  128.8.128.8)