Before I make any comparison, I have to point out the obvious: ASP is not necessarily an evil thing. All technologies need to be evaluated on their merits, but their merits include several different things:

1. Who will be implementing them?
2. What resources do they have available?
3. What problem are they trying to solve?
4. Who is their target audience?
5. What are the political considerations?

For item number 1, you have to remember that Perl should generally require a higher skill level on the part of the programmer. You get more power and with that power comes more danger. Don't give toddlers guns.

If the target audience is located on a company intranet, with a homogenous environment, you can take advantage of that fact and ASP may actually be a good choice.

Political considerations are tricky. If the CIO of the company says "we are sticking with Microsoft due to ease of integration of components", pointing out the rather limited vision of such an approach may not be wise.

Problems with ASP (IMHO):

• Do you want to switch to Apache for better performance, control, and security? Too bad. (It's my understanding that the Apache::ASP module is Perl only)
• Uses ActiveX for its components. Now your stuck with a Microsoft OS.
• ASP has quite a few security issues
• ASP typically relies on VBScript or JScript, two simple languages that ultimately frustrate programmer development.

Being lock into proprietary software can be fine for corporate intranets, but if you're developing something that you expose to the world, lacking the ability to really do anything about security concerns is a serious issue. There has been growing political momentum to hold vendors accountable for their security holes. If that ever happens, you can expect that vendors are going to start considering technologies that give them the choice of programming languages, operating systems, databases, etc.

Frankly, I'm not a fan of any corporate decision that locks you into an inflexible technology solution. There are reasons to do this, but Web development is typically not an area where this is true.

As for the pros of Perl, you may want to read Re (tilly) 1: Why Use Perl?.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

* Do you want to switch to Apache for better performance, control, and security? Too bad. (It's my understanding that the Apache::ASP module is Perl only)

There is always ChiliSoft ASP which is a web server independent version of ASP. It runs on Apache, iPlanet, and Zeus plus a few others. For languages you can use:


VBScript, Javascript or one of the leading Web application development tools (e.g., Macromedia® Dreamweaver Ultradev, Adobe® GoLive, or Microsoft® FrontPage 2000)

Of course it's $495/server and it's still not perl, but at least it's not IIS right? ;-)

So tell them "Yes, I'll use ASP", and then go ahead and use it with PerlScript. {grin} No kidding, that would probably be better than CGI with Perl, but not as good as Apache/mod_perl/Perl for a combination.

-- Randal L. Schwartz, Perl hacker

ASP is a language-agnostic "glue" technology ... So tell them "Yes, I'll use ASP", and then go ahead and use it with PerlScript.

That advice is both technically correct and dangerious. To less knowledgable managers, ASP means "Microsoft's way of doing it" (i.e., VBScript or JScript). Sneaking in a non-Microsoft technology using a "Well, you didn't understand the acronym" argument is liable to get you in trouble.

You might be able to sneak Perl in this way, and demonstrate how it's superior to VBScript or JScript by solving a gnarly problem quickly, but you're going to have to weight this against the probability of getting your management chain pissed off that you tried to sneak something in under their radar.

Is there a problem so painful that management wouldn't care how it was solved, just that it was solved quickly? That'd be where to start.

I really don't think it's such a big deal. I used to write ASP, started with VBScript, they wanted things that could not be reasonably done, and I was pushing for Perl anyways and so we did it in PerlScript. The main issue is that if it's a commericial product or enterpise use you need to get the license. Otherwise, it really is about them understanding, and it's not your problem. ASP is the IIS solution for FastCGI/mod_perl, etc.

--
perl -pew "s/\b;([mnst])/'$1/g"

I agree with dws here in that your only chance of getting them to "see" the value of Perl is to show them what it can do, to show it to them in action.  I would suggest that you ask to be allowed to experiment in limited ways with Perl.  Ask them to let you install it on the server for your use.  Then, occassionally create scripts to do creative things that no one else is doing now.

At my office, we started using it for behind the scene system administration, to listen for hackers, and to process data for reports for managers.  We used it to do things that no one had ever considered doing in VB (in our case) because it wasn't worth the effort and was too much work to set up.  The result has been that people have been pleased by the fact that server maintainence is easier, that hackers are being detected quicker, and that reports that were previously put together manually by managers using MS Excel are now e-mailed to them by the server.

That's Spenser, with an "s" like the detective.

I haven't worked with ASP in quite a while, but unless things have changed, the only languages avaible are VBScript, JScript, and PerlScript as an add-on component. One significant problem was that PerlScript was ridiculously slow compared to VBScript. Also, from what I could tell, the PerlScript modules that are included seem to encourage programmers to mess around with object internals. Want to get the session ID?

  $session->{SessionID};
[download]

Want to change the timeout?

  $session->{timeout} = 15;
[download]

Not only is that bad coding style, but I deliberately put in a typo in the second example. The hash key is capitalized. If those were method calls, there wouldn't be an issue. Naturally, those are examples that are pulled straight from Microsoft docs (why is it that I always find such awful examples of code practices in Microsoft code snippets?). Perhaps there are accessors and mutators available, but the docs didn't make this clear. Code like they show is a sure recipe for disaster.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

One significant problem was that PerlScript was ridiculously slow compared to VBScript

I hadn't heard that before, and I haven't really done extensive benchmarking, but on the couple of JavaScript pages that I rewrote in PerlScript, there wasn't any significant difference. One page was reading filenames from a directory and displaying them, and the other was fetching data from a database (Update: yes, I realize these are not good examples for benchmarking the raw speed of a language, but on most of those pages, the bottleneck was the database (and development time :-)). This was just for an internal website, and not very high traffic, so YMMV.

The other thing is, if you are going to go with ASP and PerlScript, then Matts' Intro to PerlScript and his Win32::ASP module are your friends.

One argument: CPAN. Over a gigabyte of (compressed!), freely available, well tested and mostly very stable and well behaved libraries to draw from in a virtually infinite number of situations. You can't beat having your work having been done by others.

Another PHB argument: what do Google, Yahoo, Excite, Netscape, CNET, Amazon, eToys and other big ticket sites use for their backend? No, not ASP. No, not Java either (or derived technologies). They use Perl.

Also, keep the mod_perl success stories and O'Reilly Perl success stories links in your arsenal.

Makeshifts last the longest.

Macromedia AND Adobe both use mod_perl for their sites- pretty big endorsement, I think. (Links go to Netcraft's server query results. . .)

Update:
Oh, and the Wayback machine uses extensively in one of the largest databases on the planet. . .

Of course, your situation isn't parallel to these sites, but there HAS to be good reasons they made these choices- they could certainly afford any platform they needed.

-Any sufficiently advanced technology is
indistinguishable from doubletalk.

Maybe you should show your boss this link. 
It all plays to Wall Street. MS stock prices are very
important to retirement funds.  And so it goes..........

Like many others have posted here, I'll point out again that ASP is itself not a language, but an object model provided by IIS. Apache::ASP strives to follow this object model, with the addition of some non IIS api extensions.

A carefully written ASP page using PerlScript will run on both platforms equally well, and by using modules instead of ActiveX components you can strive to develop pages that are platform independent. Point out to your boss that by doing this you have the ability in the future to switch platforms without having to worry about rewriting an entire codebase. Some minor tweaks, and away you go.

Consider also that to derive most solutions in the evil empire's language (VBScript) you have to pay for components to do simple things like sending mail (where in PerlScript you have all of CPAN). You have to resort to keyboard gymnastics to something as simple as opening a file (create a filesystem object...) or assigning a value to a hash (create a dictionary object...)