If you are comparing to C in a web environment be absolutely
sure to nail some collection of the following points:
- CGI is an environment where security matters. In
software today the single largest source of security
holes is still the lowly buffer overflow. If you use
Perl this is completely eliminated. This is before
the wins you can get from things like taint checking.
- The single most common bug in C is off by one
fencepost errors. If you consistently loop over lists
in Perl using foreach you virtually eliminate this
error. (The number one security hole and the number one
bug both gone!) Perl also frees you from the effort and
the common mistakes in memory allocation.
- CPAN is the single largest repository of freely
available code for any language. While quality varies,
there is a very long list (CGI, DBI,
Template::Toolkit...) of extremely good
software to build on.
- Perl has an exceptional amount of built-in
functionality for direct string manipulation. Considering
that web programming is largely concerned with string
manipulation, this is a big win.
- Perl has a large and friendly community. For instance
you can find plenty of good examples, get questions
answered online, find discussions of best practices, and
many other resources that help programmers improve.
- Perl is portable. Sure, C is portable in theory. But
in practice sizeable C projects tend to take work to port
between platforms. By contrast people in the Perl world
frequently just throw their code on a networked
file-server and just expect that it will run
unchanged on different machines running different
operating systems.
- Perl is portable, again. The standard libraries on
CPAN often make the same internal API available when
interfacing with multiple external resources. For
instance with DBI it is trivial to write a
program which will not only run unchanged against the
most popular half-dozen relational databses out there,
but it will even allow you to store the information in
a collection of CSV files. Which database you connect
to and work against can come down to a configuration
variable.
- Perl can be faster. Straight CGI programs tend to
be slow because of the overhead of starting programs,
opening database connections, etc. However it is not
hard to develop a site in Perl using CGI and then move
the execution into the webserver, for instance by using
mod_perl on Apache. This eliminates startup times,
allows you to cache connections, etc. Doing the same
in C would involve writing a custom webserver?
- Perl can be faster, again. With native data types
like hashes Perl makes it easy to come up with
algorithmically efficient answers to problems.
- Perl can be faster, again. Perl's RE engine
has some breathtaking optimizations. For instance
if you wanted to check for whether the string "this is
amazing" appeared in another string, in Perl you would write:
if ($string =~ /this is amazing/) { # etc
You could write that in C, it would be more work, but
you can. However the naive C implementation will not
succeed in searching the string faster than you
can walk the string. Perl's naive implementation both
can and does. Matching that in C is possible
(if Perl does it it has to be, after all Perl is written
in C) but takes a lot of work to do.
- Perl is faster, again. As noted by several
people, Perl is a master of the school of being
maintainable by virtue of being short and sweet both
in terms of lines of code and (more importantly)
conceptually. Shortness correlates directly to speed
and ease of writing, ease of testing, and ease of
debugging.
Now before you stand up and cheer, you will face several
complaints that you should be ready for.
- Perl is untyped! A type system may be regarded
as a test of an official spec for an API. The extent to
which things you would want to be tested in the spec
cannot be said and checked in the type system is the
extent to which the type system failed to do you any
good. For instance in C the type system is unable to
document important limitations like the maximum length
of string that will fit in a buffer. Perl's dynamic
data types generally keep these from being errors in the
first place. Also you can point out that in practice
many typed languages, aren't. For background on this I
recommend the following
amusing
Java example and Dominus has a wonderful article on
Typing
that is very informative.
- Perl is line noise! Perl's syntax is actually
fairly easy to get the hang of. While it is possible to
write very obtuse Perl code, as perlstyle says,
Perl is designed to give you several ways to do
anything, so consider choosing the most readable one.
With a little attention, Perl is quite good on the
readability front without requiring verboseness.
- Who uses Perl? Perl tends to be a great stealth
tool. While officially virtually nobody uses it, in
reality Perl books sell very well, and they sell to
working programmers. Perl may not be "respectable", but
it is effective. There are some who are willing to admit
to their
success
stories, but there are also a lot of cases like the
unnamed but large (very large I assure you) Wall St
company that hired Damian
Conway in mid-Febuary to teach several internal seminars
but who wrote into their contract that he would not say who
they were! (I heard the story minus the name from the
horse's mouth, and the story with the name from several
other people.)
- Perl is not scalable! Real life success rates in
software don't say good things about the scalability of
any software language. Perl scales a lot farther
than most people realize. Of course if you write a single
straight script, you will fall over. But if you use
strict, private namespaces with package, etc people
routinely manage to write and maintain systems in the tens
of thousands of lines without problems. More importantly
given the expressiveness of Perl, many of those would be
in the hundreds of thousands of lines in another language.
Given the quadratic development inefficiencies as you add
bodies, the difference between 30,000 lines and 150,000
for the same task is not insignificant.
- Perl programmers are hard to find. With Perl
good programmers can be more productive. The history of
software engineering does not have encouraging successes
for the popular model of throwing many bodies at
problems. Perl aims to make existing bodies more
effective instead.
- Perl uses too many magic variables You don't
have to use them. I didn't.
- Perl isn't multi-threaded At Threads vs Forking (Java vs Perl) you
will find a discussion of my opinions on that. Suffice
it to say that IMNSHO anyone who is unable to give an
impromptu lecture on problems with threading (for
instance a talk about why reversing multi-threading onto
code that is not thread-safe is intrinsically hard) has
no business trying to deal with it.
Does that help? :-)
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|
|