[Bloomington-normal-pm] Perl for business

Phil Winans pawinan at ilstu.edu
Fri Feb 28 15:38:52 CST 2003


On Fri, 28 Feb 2003, Erik Costlow wrote:
> A non-technical question, but one that I'm interested in... How
> prevalant is it out in the industry? What kind of acceptance does it
> have?

I'm no expert on what looks hot on a resume', but you might want to check
out http://jobs.perl.org.  From what I've read and the people I've talked
to, a great deal of organizations depend on Perl, and not just for web
applications.  I can tell you that several computer services provided by
ISU are powered by Perl.  And regardless if Perl isn't the most widely
used language, I'm a lot happier using it than VB or COBOL.

> The reason I ask is that I've been having trouble using it lately (I've
> been coding perl for a few years now). It's a very useful language, and
> with CPAN, you can accomplish a lot in perl with little effort. However,
> when I try to demonstrate things for non-perl coders, they say it should
> have been written in something else.

I try to avoid arguments that are very general, such as "Should you always
use Python or should you always use C?  Discuss."  The language you use
really depends on the requirements of the problem you're trying to solve,
and what you and others in your organization are skilled in.

I have noticed a great deal of Perl ignorance, and perhaps the poor
quality of several perl scripts on the web and books like "Teach yourself
Perl in 2 minutes" have contributed to a negative perception of the
language.  People claim Perl is a write-only language.  I disagree with
this.  If you properly scope your variables, use appropriate data
structures, and utilize modules, your programs can be very readable.  A
Perl programmer who actually knows the language and is familiar with CPAN
can develop very *fast* and do the job right.  I also think the statement
"Perl is slow." is complete FUD.  Especially if you write the
time-critical sections in XS.  Check out Kernighan & Pike's "Practice of
Programming" for timings of programs doing the same thing written in
different languages (and also really good software engineering tips.)

> For example, our ACS club at
> Illinois State University just had a coding competition for C++ and
> Java. I wanted to enter the C++ competition and wrap perl into my C code
> via perl.h, but I was told that it wasn't allowed. (It was a fair call
> under their guidelines, but I still wanted to use perl)

Well, whether or not that should be done is debatable.  Is it worth the
extra overhead to write certain sections in Perl?  I suppose that depends
on the goals of the competition.  Is it more important to write the
program quickly, to have your program use less system resources, to have
fewer bugs, or a combination of several factors?

> Another one of
> my instructors wanted our class to write a network application, so I
> called IO::Socket and wrote both the client and server really quick. I
> was told that I couldn't use it because it didn't demonstrate what he
> wanted.

Your instructor may have been justified if the purpose of the assignment
if to teach you how to write a network application at a lower level (e.g.
writing it in C and using socket.h, or even Perl w/Socket.pm should have
been acceptable).  For real world problems where development time and the
application's robustness are actually important issues, I think a great
many problems can be solved IO::Socket, and there is absolutely no need to
re-invent the wheel.  Even using a higher level interface like IO::Socket,
network applications programming is no piece of cake.  I think a great
deal of concepts could be learned from a class that did have assignments
using IO::Socket and Lincoln Stein's "Network Programming with Perl." as
the textbook.

--
Phil Winans - pawinan at ilstu.edu
Network Engineer
Telecommunications and Network Support Services
Illinois State University



More information about the Bloomington-normal-pm mailing list