I was recently having to defend Perl in a bar discussion with some techie friends. I was hearing everything from "the syntax is horrible - all those %@$~/" to "Perl is slow and clunky for doing web stuff, look at CGI".

Most of the arguments I was using can be found here with a search. Some of my responses were admittedly vague - "Don't worry, that will be fixed in Perl 6".

I was wondering whether anybody has put together a list of Perl advocacy arguments, either on Perlmonks or elsewhere. If this is missing, maybe this thread could form the basis. I did find this node, but it is a year old, and probably out of date.

Also, the discussion homed in on websites. I was having to explain how ModPerl is streets ahead of the competition in terms of performance, and does not need rocket scientists to program it (just careful programmers who are prepared to follow rules).

I also contend that CGI is perfectly adequate for single user development (i.e. unit test), and IMO is superior to ASP and JSP as its very clear what is happening server side. However, the technologies are not interchangeable.

The discussion moved to security and Perl was in the firing line. I was pleased to be able to give an update on Matt's Scripts and NMS. I also started to explain about taint mode checking, but was faced with guys insisting that no special mode is needed if you program in Java as everything is secure anyway...

At this point, I realised that my seeds were falling on parched earth, and I managed to shift discussion away from technical subjects. I could have done with a few Perl Mongers or Monks backing me up, then I would probably have continued the discussion.

Still, I'm looking for advocacy arguments for Perl, and for CGI and ModPerl versus the rest.

Replies are listed 'Best First'.
Re: Perl advocacy, CGI/ModPerl vs ASP/JSP
by demerphq (Chancellor) on Jun 17, 2002 at 13:26 UTC
    no special mode is needed if you program in Java as everything is secure anyway...

    From the security books ive been reading this is a totally crap argument. Java's security model was tacked on after much of the Java development had been completed (and has been changed several times). There have been a number of instances of Java being compromised because programmers blindly relied on the security model to protect them.

    Perls security model is simple and designed to prevent this type of false security. Distrust everything. Always be aware of potential holes. And since Java has no taint'ing mechanism it is thus more susecptable to programmer oversight. Which as we all know happens a lot.

    "the syntax is horrible - all those %@$~/"

    Those sigils are intended very specifically to seperate things that are different. Damian Conway co-write a paper on how languages that avoid such differentiation have higher error rates and are less suitable for teaching.

    And frankly I hate the try/catchiness of java. :-)

    Yves / DeMerphq
    Writing a good benchmark isnt as easy as it might look.

Re: Perl advocacy, CGI/ModPerl vs ASP/JSP
by Matts (Deacon) on Jun 17, 2002 at 14:47 UTC
    1. The sigils are ugly in my opinion (arguments that they help you figure out the type of a variable fall down with references and slices). So I'd avoid arguing against that one if I were you.
    2. Perl has warts. The whole $self as first argument thing is one, but there are many others.
    3. But, despite the warts, Perl has CPAN. I'm afraid CPAN kills arguments about other languages stone dead. I've tried really hard to move to other languages (C, Java, Ruby) because I don't like Perl's warts, but none of those languages have the simple elegance of CPAN.
    4. Speed issues tend to evaporate when put under real tests. Slashdot gets a lot of hits and runs perl. Other sites get a lot of hits and run JSP, others ASP. In the end it all comes down to good design and network architectures.
    5. Did I mention perl has CPAN?
    6. Java is fundamentally not immune to security problems. That's the most naive thing I've ever heard a developer say. What about cross site scripting bugs? What about SQL injection bugs? No matter what language you're programming in, when you're working on the web you always *always* check your user input. Perl's taint mode makes it hard to avoid doing that, but it still doesn't alleviate security issues.

    That's probably not exactly everything you wanted to hear. It's not so much an advocacy argument - the best thing about Perl is CPAN (and sometimes the worst thing about Perl is CPAN, but that's a whole other node).

    Update: wedman reminded me of perldoc. That's such an awesome tool I can't rave enough. Show me another language that has as good and as easy to find docs as perl when you're working on the command line.

    • Slashdot gets a lot of hits and runs perl. <...> In the end it all comes down to good design and network architectures.
    • Doesn't Slashdot have a big fat load balancing system in place? The speed issue was dealt with by throwing more hardware at the problem. So, like you said, it comes down to design and achitecture. I suppose somebody could code a website using Q-BASIC on several heavy duty machines behind a load balancing system, but that's probably not good design.

      To me, I find Perl very fast and easy to develop with. Not only is CPAN sweet, but PerlDoc rocks as well. I use references constantly when I code, and PerlDoc is always there when I need a hint.

        They describe the machines that power the site here. I wouldn't call 10 Intel boxes a big fat system. They probably cost less than one Sun box.
        Slashdot actually used to be fast, and back then it ran out of Malda's appartment. (I have a userid in the 2000's). It requires a big fat pipe because it uses it. It requires load balancing because it gets enough traffic to need a big fat pipe.
      Sigils are *not* ugly! They are useful to show the type of values. Your contention that they "fall down with references" is mildly 'true', but not for the most part. Even if its a reference to a hash, you still know its one value, a scalar value, thus fufilling the point of the sigil. And more over, if you see "%$foo" then you know $foo is hash reference. And you can easily determine what type it is, merely by using the 'ref' function. I love sigils, they also help to make the code visually distinctive, you can always tell what is a variable and what is a keyword, and allowing interpolation is just a ++
        I'm afraid I can't agree. There are just so many cases where the sigils aren't enough to disambiguate clearly in people's brains. And references are the main cause of this. But also look at slices. Here's a hash slice:
        @foo{ qw(a b c) } = qw(x y z);
        Now what does the @ have to do with the variable? The correct answer is absolutely nothing. The sigils in perl are used to denote the type of the operation, NOT the type of the variable. Because the slice above operates on a list it uses the @ to denote a list. But damn, is it ever confusing.

        To take it further, you say ref($var) is enough, but how do you do that while coding? You can't - you can only run ref() at runtime. So sigils aren't serving their purpose there. Also now let's suppose ref($var) returns nothing, so what does $var->(); do? It possibly executes a function! But ref() told you nothing, and the $ told you nothing. (yes, I'm aware strict will catch that, but what if the purpose is to run a function? Then you have to have strict refs off for that section of code).

        Now take it a step further. What about $var->{entry}. Most people these days are doing OO (aren't they?) so what does the $ tell us this time? Nothing, because the type of $var->{entry} is totally and utterly opaque to the naked eye.

        Extreme example time. How do you do a hash slice of a hashref belonging to an object implemented as a blessed hashref? (did you parse that? It's hard to read, but it's even harder to figure out without severe experimentation how to do it). The solution is the totally inelegant:

        @{$var->{entry}}{qw(a b c)} = qw(x y z);
        So now what part of the above defines the fact that it's a hashref? The answer is the openning curly bracket just before the first qw. Nope, sigils were pretty useless once again.

        OK, rant over. Sigils really aren't all they're worked up to be. They have a purpose, which was fine for perl 4, but I think when perl 5 came along it all but made them useless.

        A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Perl advocacy, CGI/ModPerl vs ASP/JSP
by simon.proctor (Vicar) on Jun 17, 2002 at 20:45 UTC
    When I first read this I was going to reply with my comments on all the technologies (as I have to use them at work) and then, hopefully, give some good reasons for using Perl. Or at least help win some (but not all, lets be honest) arguments.

    However, lets face it, no-one ever got sacked recommending Java. Its in the press, big named companies are pushing it etc etc. Faced with this push from the press and the academic community no IT director is going to face his peers without being anywhere near buzzword compliant. Lets face it, its very rare for those who make strategy to actually understand what they are advocating. So when they turn to their subordinates for advice, very few will make a reasoned argument for the right technology or even evaluate it in a language agnostic fashion because they don't want to get caught making the wrong choice.

    I was recently in a meeting with the senior technology services people to find out about their technology strategy. And guess what? As soon as they found out I was a Perl guy they tried to spend most of the meeting pulling it down (till I put my foot down). The basis for this? Well someone installed a Mats Script formmail on the main webserver that is used by most of the revenue generating sites (over 25M) and wonders why they get hacked all the time.

    I didn't know whether to laugh or cry.

    Of course servlets are fast, you've embedded the run time into a server environment, loaded the app and stuck it in memory and started a new thread for each new hit. Sound like mod_perl?

    Of course JSPs make the designers life easy. But they just do not compare to the Template Toolkit. In fact the only thing that I have seen that comes close is Velocity from the Apache project. But if you also consider that a JSP page gets converted to a servlet by the container before running and you tend to wonder how much of a bolt on it really is.

    Frankly, ASP and JSP just don't cut it IMHO. My reasons for ASP are numerous (and I do have to use it :/). Most of which are here: 143745. Don't get me even started on IIS recycle, white pages and how, allegedly, Microsoft have mucked up IIS 5 and left their community in the rain (so to speak).

    Of course, we mustn't forget Python (no really). Servlet technology lacks the rapid prototyping that a scripting language allows. I've spent 3 weeks developing a prototype that would hav taken days in Perl. However, I've managed to speed this up using Jython in a servlet environment. So how flawed is that? Running one language inside another just to get the speed of development you need?

    And of course this raises the issue of speed. Most people who read that CGI is slow have only ever seen that in a magazine and gone with the author. Yes of course CGI is slow but its not the same environment as a servlet so doesn't compare. But if you consider that most sites never have the number of hits required to show and truly marked difference. Because if you were building a massive site with thousands of hits - you wouldn't use CGI or ASP. It would be mod_perl or a servlet system, a cluster of servers and lots of tiers, replication etc. Most sites run badly because of poor system design and then a magic consultant comes along and says - Java is the key. So of course, no-one ever got sacked recommending Java.

    Because I truly feel there is 'fast' and there is 'fast enough'. Does the trade off of a few percentage points of speed pay against the fact that it took less than half the time to develop? That you didn't have to spend cash on invitations to tender, specialist hardware, training etc.

    The money you've saved could buy you a better network, pipe and more 'puters.


    PS: sorry I went on a bit but I wanted to get some of this off my chest.
      Servlet technology lacks the rapid prototyping that a scripting language allows. I've spent 3 weeks developing a prototype that would have taken days in Perl.

      This may be true for you, but what about a company where everyone knows servlets inside out, but barely anyone has written any Perl? When making these decisions one should keep in mind the skills of their employees. Of course, in many situations it's worth it to train employees, if the language/product/whatever can get your job done sufficiently easier.

      The money you've saved could buy you a better network, pipe and more 'puters.

      Excellent point. Developer time is almost always far more expensive than hardware and bandwith costs. It's a pretty safe bet to try and minimize the former with a small investment in the latter.

      Actually the point about CGI's being slow is a dumb one too. I can get about 80 requests/second on a small C CGI. And I can get about 90-100 requests/second on the same server from a mod_perl Apache::Registry script doing pretty much the same thing. CGI has a reputation for being slow mostly because of the Perl startup time, because perl became synonymous with CGI.
      A reply falls below the community's threshold of quality. You may see it by logging in.
      I don't know if anyone ever got sacked for recommending Java, but I did interview with a shop (who shall remain nameless) at one point that was generating an image-based search engine. They seemed to have a highly competent technical team.

      After they had done a bunch of prototyping in Perl, they decided that they had to do the real thing in Java.

      After a coule of months, they discovered that development time was significantly slower (and couldn't keep up with their changing business demands) and the execution time of the Java code was unacceptable relative to Perl.

      They immediately switched back to Perl and discovered that, although the business folks had lost a bit of buzzword-compliance, Perl had been by far the most practical choice from the get-go.

      Go figure.

Re: Perl advocacy, CGI/ModPerl vs ASP/JSP
by perrin (Chancellor) on Jun 17, 2002 at 14:56 UTC
    Thanks for the props, cjf. The thing about Java being inherently secure is indeed absurd. Most web app security bugs are things like people being able to change the prices of items they buy on commerce sites or hijack other people's sessions and steal their personal data. Java can't prevent you from making these kinds of mistakes. Perl tries harder than Java by offering a taint mode, but you can still shoot yourself in the foot.

    In addition to the fact that mod_perl is at least as fast as Java servlets, ask them to name some big sites that run on Java. Then point out some big sites that run a lot of perl: Yahoo, Amazon, Ticket Master/CitySearch. I don't see anything in the top 10 that runs a significant part of their site on Java.

    You could also quote some stats to them from my article about using mod_perl at eToys.

Re: Perl advocacy, CGI/ModPerl vs ASP/JSP
by cjf (Parson) on Jun 17, 2002 at 13:46 UTC
    Perl is slow and clunky for doing web stuff

    Yell mod_perl at them really loudly (update: apparently you did, but yell it louder, and throw in some benchmarks :). That should end that discussion.

    Also read perrin's excellent reply to a similar thread at Re: CGI (Perl) vs JSP.

Re: Perl advocacy, CGI/ModPerl vs ASP/JSP
by Aristotle (Chancellor) on Jun 18, 2002 at 05:26 UTC


    They may look like line noise to the uninitiated, but I dearly miss them when I'm not working in Perl. They offer anchor points to my eyes - I can see where there's a variable and where there ain't with just a casual glance over the code. Together with Java's tendency to use reallyLongMashedTogetherIdentifiersWithNoVisualSpacing and the fact that as a strongly typed language, it needs a lot of paperwork to get the simplest tasks done, it takes me many times longer to figure out the shortest bits of Java, compared to Perl where a short eye-over will often suffice to tell me what's going on.

    Even more important, in Perl, when an eye-over doesn't suffice, I know just by that fact that I'm looking at a tricky little ditty.

    CGI = clunky

    You can write CGI scripts in Java too. Guess how clunky that is. *grin* They're not realizing that mod_cgi != perl.


    Well, I needn't reinstate the previous points. If you don't check your input data for single quotes, Java's security model won't prevent you from feeding user-supplied SQL into your database. Java is "secure" because it the VM mistrusts the code. Perl is secure (if the programmer took the proper care) because the script mistrusts its input. There's a fundamental difference in the way of thinking here. The former mainly fixes symptoms and makes me as the programmer feel handcuffed. The latter lets me hang myself with the long leash I have if I'm careless, but constantly reminds me to be cautious and responsible.

    Makeshifts last the longest.
Re: Perl advocacy, CGI/ModPerl vs ASP/JSP
by domm (Chaplain) on Jun 18, 2002 at 09:39 UTC
(wil) Re: Perl advocacy, CGI/ModPerl vs ASP/JSP
by wil (Priest) on Jun 18, 2002 at 11:00 UTC
    I think a big problem at the moment is that hosting providers will not load mod_perl on shared hosting plans. I've often heard the argument from ISPs saying that any process can grow uncontrollably and take all a server's memory and/or CPU resources, which could theoretically mean one user could destabilize the machine for hundreds of users quite easily.

    However, mod_perl 2 is supposed to do something about this. I think this is a very important step. If mod_perl 2 can find it's way onto most major shared hosting providers, then we'll see it's usage increase and, hopefully, we'll see more and more people using mod_perl instead of the traditional Perl/CGI route which will put Perl back on the speed map again in terms of web programming.

    - wil
      I think a big problem at the moment is that hosting providers will not load mod_perl on shared hosting plans.

      This is true, but just try to find an ISP that will run Java/JSP on a shared server or on any managed environment. Most of the time (as with mod_perl) you will be completely responsible for everything except the cables being plugged in. The truth is, that JSP/J2EE is still not very mature and the ISPs are rightly careful about supporting something that hasn't really proven to be all that stable.

      OTOH, if you make a system in Perl/CGI and you take some care of your coding practices, you can start your site on a shared server and move on to a dedicated machine and mod_perl when the need arises (and in my expirience, it mostly doesn't).

      As for one user taking out the whole system, those providers are right: any process can grow uncontrollably and take all a server's memory. This includes a CGI program if it's determined (or stupid) enough. It's just easier in mod_perl. :-)

      -- Joost downtime n. The period during which a system is error-free and immune from user input.
        Hosting is still an issue since it requires mod_perl to run properly, but I've found Apache::ASP to be awesome after having used CGI, ColdFusion, and servlets/JSP. I say just colocate a server and use what's best for you if you can't find a host with the right stuff. The big advantage that most people aren't mentioning much is speed of *development*! You can always throw more hardware at it if you find execution speed to really be an issue (I never have...mod_perl is plenty zippy for me). Hardware is cheap; programming effort is not. I am a Sun Certified Java programmer, but I can do the same things I can do in Java in Perl with probably 1/3 of the code. I've reached the point where the only reason I care about Java is for my resume. Perl is the language for getting things done!
Re: Perl advocacy, CGI/ModPerl vs ASP/JSP
by ignatz (Vicar) on Jun 18, 2002 at 10:56 UTC
    The big thing that is missing with Perl is kickbacks. Perl needs some perky young sales reps that can take corporate bigwigs out to lunch and dazzle them with powerpoint presentations and Pacoware version 6.0 Now with scrubbing SOAP bubbles cloth briefcases and in the case of Fortune 500 accounts games of golf where big envelopes full of $$$ can be discretely passed. Where did companies get the idea that throwing millions at technology while treating their programmers like surfs is going to achieve anything of value?
Re: Perl advocacy? Why have a dog and bark yourself?
by frankus (Priest) on Jun 20, 2002 at 08:26 UTC
    I find advocacy discussions are moot.
    Rarely do participants enter with an open mind.
    Best to smile politely, let the people air their opinions.
    Perl wins, as good things do, in use: not in debates or classrooms.
    It's pragmatic and don't forget that.


    Brother Frankus.