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.

BTW, those are both very poor pages for determining the speed of the language from; they're both likely to be IO-bound. But, indeed, YMMV -- if these are typical pages of yours, the speed of the language isn't likely to matter.

---

Confession: It does an Immortal Body good.