• It is such a power tool to deal with regexp, I don't see any other language can do it better;
• The development only costs so little time, so quick, and you can even make it GUI.

• Some guys in my shop deal with IBM mainframe. It is really a pain whenever they need to make testing JCL's from production JCL's, and test something. I made a GUI tool, which FTP JCL's from mainframe, analyzing them, converting to testing JCL's, and finally FTP them back to mainframe. regexp, of course, and I also used Net::FTP and Tk.
• We recently got some C/C++ source code from another company, and need people to understand those source code. I made a small tool to allow programmers to view their C/C++ code in a tree view. The tool analyze the C/C++ source code and visually guide them through the calling/called function chain. Again, regexp and Tk.
• ...

Well, several ideas come to mind:

• there's the usual log munging that can be done on the back end,
• automated project builds (perhaps using template toolkit),
• set up a heretical server to play with stuff like HTML::Mason and the Template Toolkit,
• Application testing, perhaps using Puffin,
• set up a wiki for your group,
• use perl to write your ASP code for you.

These are some off the cuff ideas. Each of them should, however, provide you with plenty of fun projects to distract you from billable work.

Have fun!

TGI says moo

How does Puffin relate to the question? Puffin is written in Python.

Since your company is already using ASP, you might be able to sneak in some PerlScript (an ASP plug-in that comes with ActiveState Perl for Win32). For leverage, wait until you find some text processing job that'd be a nightmare to do in VB or JScript, and show people who easy it'd be to do in PerlScript.

AFAIK PerlScript is NOT what you want to use with ASP.Net. You don't use VBScript either, you use VB.NET. What you want is PerlNET.

I did not try it yet but I'd bet it would be best to the the interface related stuff in VB.NET or C# (simply something supported natively by Visual Studio.Net) and only use PerlNET to either implement things that are much easier written in Perl than in the .Net languages or to wrap up the functionality of some CPAN module.

Jenda

PerlNET AFAIK is just a program developed by activestate to help develop Perlscript.NET components, not the actual language itself. However, I do agree with you about what I would use Perl for in a .NET scenario, I'd stick with C# for most things and switch for things simply too much easier to do in Perl to ignore, and to take advantage of CPAN modules.

There's lots of places perl can still be useful to you. In log-munging, and CGI apps (though you've mostly moved to ASP, CGI can be nice for rapid-prototyping, and for building static pages with), but other people have already pointed them out to you. However, it's quite possible to call perl code from Microsoft languages, or any other language where it's possible to use COM Automation, with the Microsoft Scriptlet Control library -- just create a perl object, execute a file-do, or a use, and then execute your functions. Once people see how much easier it is to code things in perl, esp making hard things possible, they're start to code in it more and more, I suspect.

(You're need an activestate perl install, and the microsoft scripting runtime, which is standard with IE5+.)

Simply put, there is nothing better for adhoc work than Perl. Knowing how any environment works, there is always somebody who needs "just one quick report" again and again and again. Or, if you've been lucky like me, and you work in an environment where nearly every interface between systems is broken somewhere, you need some good script to fix the database quickly, and for me Perl has done it for me.

Although it may seem in your environment that the only way that web services can be done is with .NET, Perl (using SOAP::Lite) is the quickest way to test web services. I use Perl almost exclusively as a client to Web Services since I started using it about a month ago. I'm sure with the MSness of your environment, that web services will be popping up in your workplace.

Although the vast majority of my development work is VB.NET/ASP.NET, I do manage to get a fair amount of perl coding in.

I use perl ALOT on our UNIX servers to eliminate the need to telnet sessions (I've pretty much replaced that with socket servers through a web interface), as well as to handle routine maintenance and clean-up and any other task that I don't want to deal with.

Perl serves to make my job as a developer easier. I'm actually going to use it in an ASP.NET web-app, in the near future, to generate a massive amount of SVG from a SQL Server database. Because of the modules available, I'm going to be able to write this in much fewer lines of code and in much less time.

Every once in a while, I get an assignment to write some quick and dirty tool for a specific task. About half the time, it's about text parsing. Maybe it's checking filesize, or measuring a specific parameter from netstat, or pulling a string from a web page. With perl, I can hack something together fast fast fast. Need a wrapper around a command? Perl. Need to parse a logfile? Perl.

Perl allows you to code fast, on the fly. Perl handles text parsing better than anything else. Keep perl for the little projects, the little tools that make your job easier. Show your people something cool, and they'll come around.

-Logan
"What do I want? I'm an American. I want more."

I'm in a similar environment, though we did not really start the move to .Net yet. I'm basicaly using Perl

• as COM objects from the ASPs and VB (using ActiveState's PerlCtrl)
• for services that do tasks that'd be much harder to write in VB/C
• for small scripties that need to be run on the servers every now and then and do not deserve a separate service.(There's a Perl service that serves as a "scheduler". Some of the tasks need to be run once every ten minutes, some once a week ...)
• for log mungling and parsing
• to generate VB code
• for various "hand-made" utilities

Jenda

Great suggestions! I especially like the link. Lots of food for thought there, and plenty of things to play with.

Cheers!

Acolyte
Studying at the feet of the masters