in reply to Perl advocacy, CGI/ModPerl vs ASP/JSP

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.
  • Comment on Re: Perl advocacy, CGI/ModPerl vs ASP/JSP

Replies are listed 'Best First'.
Re: Re: Perl advocacy, CGI/ModPerl vs ASP/JSP
by cjf (Parson) on Jun 17, 2002 at 21:24 UTC
    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.

Re: Re: Perl advocacy, CGI/ModPerl vs ASP/JSP
by Matts (Deacon) on Jun 17, 2002 at 23:00 UTC
    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.
Re: Re: Perl advocacy, CGI/ModPerl vs ASP/JSP
by Starky (Chaplain) on Jun 18, 2002 at 09:45 UTC
    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.