Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Re (tilly) 1: Why Use Perl?

by tilly (Archbishop)
on Mar 25, 2001 at 23:04 UTC ( [id://67047] : note . print w/replies, xml ) Need Help??

in reply to Why Use Perl?

If you are comparing to C in a web environment be absolutely sure to nail some collection of the following points:
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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?
  9. Perl can be faster, again. With native data types like hashes Perl makes it easy to come up with algorithmically efficient answers to problems.
  10. 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.
  11. 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.
  1. 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.
  2. 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.
  3. 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.)
  4. 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.
  5. 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.
  6. Perl uses too many magic variables You don't have to use them. I didn't.
  7. 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? :-)