Path: utzoo!attcan!uunet!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!uw-beaver!fluke!inc
From: inc@tc.fluke.COM (Gary Benson)
Newsgroups: comp.lang.perl
Subject: Re: Looking for balanced critique of Perl
Message-ID: <1990Jul2.221231.15950@tc.fluke.COM>
Date: 2 Jul 90 22:12:31 GMT
References: <4811@muffin.cme.nist.gov> <103428@convex.convex.com>
Organization: John Fluke Mfg. Co., Inc., Everett, WA
Lines: 125

The person who originally posted the request for pros and cons about perl
asked for things that had been published, but this forum seems to be the
major place where perl topics are published!

My experiences and observations may be of interest, since I am not a
programmer, but I have had to learn a little about sed and awk and shell
programming, and now perl, out of necessity to support our group, a
Technical Publications department. I have written a number of filters that
clean up common problems in text files. For example, our current typesetting
equipment requires one space to separate sentences, not two, as most people
learned in typing class. So sed was the logical choice. I did a bit of that
kind of thing on and off -- it is not really my job, but the need was there,
and we did not have regular access to programming expertise. Occasionally we
have had to extract and rearrange some information from a database, and so
I've learned a little bit about awk. Then, we developed a system to
"centralize" our department archives of manuals in print, and so I learned
enough about shell programming to automate that process somewhat.

Then one day we decided that we had enough information to ask a "real
programmer" to attack a problem we had been facing for a long time. The work
of inserting typesetting codes into a document is tedious, boring, and
error-prone. When the people who had been doing typesetting were no longer
in the group, or were doing other work, we decided to write a software
requirement for a program that would scan a text file and based on
structural clues (like the word CAUTION centered on a line by itself), would
insert the appropriate typesetting codes for font changes, bolding,
centering, and so on.

Our original hope was that perhaps 90% of a document could be auto-coded by
such clues, leaving the remaining 10% for hand work, which we thought could
be done by someone without typesetting expertise. A programmer here at Fluke
by the name of Corey Satten had wanted to tackle this problem for some time,
but we had never organized the boring, tedious requirements. When we did,
back in April of 1988, Corey had been looking at perl and was itching to try
it out. Seeing our requirements, he determined that perl would be a good
language choice, and in less than a week, his perl script easily met our 90%
target.

When he left the company, it fell to me to maintain the script he left us;
I have been able to permute it into over a dozen variations, covering all
the differing formats we use for publishing our manuals. Along the way, I
have managed to add a bit more functionality, and only one hurdle keeps us
from 99% automatic coding of "clear text files". We are in the process of
purchasing an electronic page-makeup package and our perl script will become
the front end, interfacing on the input side with the files Technical Writers
provide, and it will generate SGML coding for the page makeup program.

We have come much further than we ever anticipated we would back in the
spring of 1988. I am certain that our success is in large measure due to
the many tools that perl brings under the same umbrella. Our only
alternative would be a shell script calling an awk script, a few lines of
sed, multiple intermediate temporary files, and all-in-all, a generally
ugly, hard-to-maintain, twistingly interactive group of programs.

From my perspective, perl is much easier to understand and learn than sed,
awk, grep, and shell programming. Because it is one program, there are no
syntax discontinuities that used to drive me up a wall (Hmmm, that sounds
odd for some reason). Sure, as others have pointed out, the syntax may be
wierd and difficult at times, but at least it is cohesive. In fact, I have
even translated my old sed filters into perl, a painless process using s2p.
Last year, we were preparing to publish a manual that required a new feature
in the typesetting program, so we asked for help from an engineering group
who we knew would be needing the feature in one fo their upcoming manuals.
They wrote an awk script, then used a2p to translate it to perl. It fit into
the larger perl script as a module in need of only minor tweaking. It worked
like a charm.

Our programs are 200 to 400 lines long; not daunting by any means; but
substantial, at least to me, whose shell scripts were usually about
one-tenth that length. It may be true that there are too many ways to do
things in perl, but for me, that is a decided plus, since I know that all I
really have to do is find ONE of them, and it is going to fly. Too often it
has seemed that there is only one way to accomplish a task, and that way was
hidden in some tricky corner.

The problem I have is simply in seeing an analog between what I am trying to
accomplish and any particular feature of the language. But this is a failing
in me, not the language. For example, I totally ignored the "system" command
for a long time because its name didn't seem to apply to anything I needed
to do ... after all, I wasn't concerned with system tasks, setuid and
password files and all that... Having heard that perl is quite well suited
to system administration kinds of jobs, I always just passed over "system",
assuming it applied only to that kind of programming. How wrong I was! After
I learned about the power of the system call, the world opened for me,
literally. I finally saw that this command made my entire repertoire of
system commands available, just as if I was popping out to the shell for a
while.

The major drawback that non-programmers like myself face is that the manual
is written at a pretty high level; the descriptions and examples assume you
already know, for example, what a system call is. All indications are that
the book will be written at the same level, but will have many more examples
and will guide the reader up a less steep learning curve. I'm all for that -
I have read the entire manual 7 times, and there are still great gaping
areas that I read and remain clueless. Again, this may not be a failing of
the manual, but of this reader.

Occasionally, the discussion in this group turns to "perl as a job
requirement". Today was the first day of work for a contract programmer whom
we hired specifically to program in perl. I have more studying to do before
I will be up to the task we have set him, but I know for certain that the
language will bend flexibly to his will. We interviewed over a dozen
programmers for this position, and the number one requirement was a
familiarity with perl.

I am also pleased to note that last week, our corporate Software Technology
Group announced that perl would become "officially supported software"
effective immediately. Of course, I am all for official support, because as
I tell my boss, I need all the gurus I can get! Perl now takes its place
here at Fluke in /usr/local, alongside awk and sed and grep; it is no longer
"user supported" in /usr/public. The significance of this comes through
clearly in a remark I heard only a few weeks ago, to the effect that
"software is not given corporate support just because it's cool". It is good
to learn that support is not withheld BECAUSE of coolness, either!

I realize that most of what I have written here is anecdotal and may not
provide much insight. Then again, all perspectives have merit and everything
I am learning is proving that Tom Christiansen is correct in characterizing
perl as a significant and important contribution.

-- 
Gary Benson    -=[ S M I L E R ]=-   -_-_-_-inc@fluke.tc.com_-_-_-_-_-_-_-_-_-

Those who mourn for "USENET like it was" should remember the original design
estimates of maximum traffic volume: 2 articles/day.   -Steven Bellovin