1. Platform dependant (unless you pay massive amounts)
2. Hard to separate template and program
3. Templating almost exclusively SSI
4. The OO functionality does not allow for inheritence (under VBScript at least)
5. Usually there isn't TMTOWTDI unless you buy a dll library
6. ASP lacks syntactic sugar
7. Its too easy to write a bad script and not know it. Its easy to do the same in Perl but you know you have
8. Accessing a database requires a DSN. Theres no DBI equivalent.
9. Oh.. ADO...well ok. But after using it for nearly a year you notice its only really designed for doing things the Microsoft way....not your way.
10. It runs on a server that is too easy to hack
11. You rely on a corporation to bugfix the language which can take anything upto a year (or more). Can you say that for Perl?
12. Can you do more than dynamic pages in ASP? Would you want to?

If you want to compare PerlScript against server side VBScript or JavaScript, then that's another matter. Perl rocks, the others suck, and for many tasks you'll be writing one half to one quarter of the code in perl that you would have to write in (VB|Java)Script. And then there's CPAN...

For the client side (i.e. browser), then of course you're mostly stuck with (VB|Java)Script, though there is a PerlScript plugin available, I don't think I'd use it for anything but an in-house application (does anyone out there use it?). But then I'm not talking about ASP anymore, am I? :-)

Note: the following is a personal opinion.

Another poster mentioned the lack of syntactic sugar in ASP. I wish I had votes for "understatement of the day". When we started working on a project over a year ago, the project manager suggested using ASP because "there are millions of books on it". After looking into it, I realized it was VB for web programming, with all the overly-verbose syntax of Visual Basic.

But, aside from a clumsy syntax, it should work great, right? Well, try to write a file-upload web-application using only ASP. It can be done, but there is nothing (that I'm aware of) like CGI.pm that handles this kind of thing gracefully - most if not all of the solutions for file uploads using ASP are commercialware and rather expensive.

Enough negativity about ASP - I'd prefer to speak positively about perl. "Perl makes the difficult jobs possible, and the easy jobs easy." Basically it's pure freedom and comes with great perl communities like this one.

I hope this gives you some insight into why you got the responses you did on your previous post.

...Guv

There is is a pure-(perl)-ASP means of doing file uploads, Win32::ASP::CGI. I've used it without difficulty, there are also of course COM objects for VB to use most are commercial though.

--
perl -pe "s/\b;([st])/'\1/mg"

I've been running an ASP site for about four years now. At the time it was a great way to have a site with server side scripting with a hosting provider that didn't charge for occasional spikes of high bandwidth.

For me its biggest weakness is the bizzare hoops that you have to jump through in order to do things that are a breeze in Apache based solutions. For instance: at the time I was tryng to build a site that used templates around a file that was included from a variable. I searched and searched across the net for a free example of something that was as simple as <? include("$foo.php"); ?> in php. Here's the best that I could come up with at the time:

<%
SUB ReadDisplayFile(FileToRead)
   whichfile=server.mappath(FileToRead)
   Set fs = CreateObject("Scripting.FileSystemObject")
   Set thisfile = fs.OpenTextFile(whichfile, 1, False)
   tempSTR=thisfile.readall
   response.write tempSTR
   thisfile.Close
   set thisfile=nothing
   set fs=nothing
END SUB
Call ReadDisplayFile(foo)
' Server will ignore ASP commands in dynamic include files 
%>
[download]

The fundamental power of web scripting in Perl (or PHP or Python or C for that matter) is the rock solid foundation that you get from Apache. Apache is a monster app that no one (not Microsoft, not Oracle, not Sun, not IBM) has been able to even get close to let alone touch. Add to that the huge community that is built around Perl and just about any solution that you can find is just a click to CPAN away. On the ASP side you will quickly find dozens of groups willing to offer you 'solutions' as long as they get paid.

Even Asp is better in Perl. Apache::ASP is a wonderful module to work with giving you all of the useful bits about ASP while still in a Perl/Apache framework.

In recent days ASP has had a leg up on the XML support, but luckily AxKit is killer.

First of all, if it works for you, that is fine. They're tools, not religions - at least if you are in business.

Second, perl has its own problems. People complain about perl maintainability. It is easy to write a script that is hard for other people to understand in perl. Of course, if you follow good practice, you can write clear code in any language. If.

That said...

I haven't had much truck with ASP but one main problem with it - and PHP - is that they go for the "code embedded in web pages" approach. This is quick and easy, but it has serious problems. First of all, your designer has to wade through your programmer's incomprehensible geek gibberish, and your programmer has to scroll past your designer's hideous nests of TABLE tags. More importantly, this approach mixes in "application logic" with design.

For example, suppose you want to login a user. "User login" is a single concept. The code for it should be in one place. But because each ASP/PHP page can only display one web page, you have to break up your code. There's the code to display the login form and the code to display the result. These have to be split over two pages. That sucks.

You don't have to program like this (at least in PHP) but the design of the language encourages it. Beginning programmers mix code and display... then they end up with unmaintainable websites.

Perl is much more of a general purpose programming language than ASP or PHP, which are basically web solutions. As such, it supports a lot of different approaches: HTML::Template, CGI, HTML::Mason are all different ways of building web applications. And Perl has the power of CPAN, where there is a solution to pretty much any problem.

So basically, I don't know if ASP sucks, but I reckon Perl is better. It sounds like you are using it already... maybe you should upgrade.

dave hj~

Look at any site running ASP with a large number of concurrent users and the performance will be abysmal. A case in point is Microsoft's site itself, even the fairly simple pages take an age to appear in full. And they wrote the stuff, they should know how to optimise it, and have every incentive to show how good it is(!)

Compare that to sites running perl under mod_perl with similar connections to the Web.

If the marketing is to be beleived, this will all change with .NET, at least the way this is being implemented should cure the problems with ASP and beat JSP in terms of performance too. And we'll be able to program Perl natively into .NET through VS.NET, so none of the other problems noted in this thread. Except of course being bound to IIS: .NET framework for Apache anyone?

-- iakobski

It isn't awful. But, it isn't portable (which is not a problem if you live in an exclusively Microsoft environment).

Now had you asked, "why is Microsoft so awful?" I might have more to say about their negative impact on the IT world and business in general. ;-)

As to your second question; if you can deliver your application on time and without excessive midnight oil, if it works the way you intended, if it scales to meet user demand without chewing up all of your available resources and if it is easily maintained (especially if somebody other than the author gets to do this) then I'd say you have found a fine solution, regardless of the technology. And extra kudos if you had fun developing it along the way!

Question #3: Perl frequently allows developers to meet the criteria I give for Q#2 (although maintainability can be a bit tricky unless you resist the urge to use "tricky" code and skimp on documentation)... that makes it great in those particular situations. It is also my perception that Perl has associated with it a strong and selfless developer community, at least moreso than you would find with ASP.

Others have already pointed out that you can't compare ASP (not a language, but a server side scripting solution) with Perl (a language AND a party favor!). You could, however, compare PerlScript/ASP with VB/ASP and/or ECMAScript/ASP though, and if your app required a lot of string processing, I think we know how the vote would go.

PCS