When I arrived at a company with around 40 developers, there were zero Perl programmers. Within three years, that had grown to 20. This happened without an official project and without any management "approval". The trick was to not ask for approval but to simply go out and start solving useful company problems with Perl. If you have enthusiasm and what you are doing is useful, others will follow.

As for specific tasks, when I started, they were building a multi-platform "glue" tool, using Cygwin on Windows (rather than your MKS) to auto build and test a product across around 15 different platforms. Switching to Perl, I was immediately able to speed up some parts of this process from one hour down to five minutes (which was definitely noticed by the people who used to have to wait for an hour!). Someone in another department noticed what I was doing, and decided Perl was an excellent way to allow power users to extend and script our product -- noting that there is no barrier to bundling Perl with commercial product.

Outside the Web Application sphere, some areas where Perl might be used:

• Build and test automation.
• Adding power user scripting capability to product.
• Product installation and configuration, e.g. Mandrakelinux.
• Patch creation, distribution and testing.
• Bug/request tracking, e.g. Bugzilla, RT.
• Software configuration management, e.g. SVK (built on top of Subversion).
• In-house wikis for information sharing, e.g. kwiki.
• Creating slide presentations, e.g. Spork.
• Timesheet systems.

Procedure:

1. Find a process your company has that is inefficient.
2. Whip up a solution in under 40 hours that saves the company significant resources by streamlining the process.
3. Do #2 in your spare time.
4. Demo the solution to upper management, emphasizing the cost/benefit ratio as well as the time-to-market.
5. Be prepared to be called a liar.
6. Have a bodyguard for a few days to make sure you don't get jumped by the other developers in the parking lot.
7. Eventually, upper management will either see the light or you will find a better employer.

Then at work I became C programmer, and, after a couple of years of ineffective C programming I realized that it benefits a lot to include perl chunks of code to speed up my programming, so I used perl as external library.
As time passed by, I used Perl more and C less, and then I switched to pure Perl, and I consider that as a very good boost for my efforts.
Still, I use my C knowledge regularry, but only to find a way how to make perl more capable for my tasks :)

As for my duties at work - I help to transform text files for language translation process, and many related tasks, which is quite interesting area for Perl programming.

We're also developing some data management applications, all Perl. For instance I just shipped a data management software for INA ( french national media archive), that will manage a pool of 40 servers and monitor and index 160TB of storage in an Oracle database. I wrote it in a couple of months (total ~5000 lines of new code) and it just entered the test phase last week.

I'm pretty sure it was close to impossible to achieve such a work with most other languages on the time frame and budget. Especially with Java, C, C++ and friends...

I run my own freelance development business and as such I make more money if I do more things in less time. That means re-using as much api as possible. If I'm developing almost any kind of collaboration website that means useing OpenACS (http://openacs.org) if I am developing almost anything else, that means programming in Perl.

I also contract to a very large ISP - here perl is used for Everything (with a capital E). With the blessing of our division head, amd with the slightly-gritted teeth of the internal IT divisions(who take three times as long to get things done as we do :).

I did contract to an investment bank - A little perl was used with their C++ and Java. Unfortunately the culture was engineered against wide-spread use of perl, but a few far-sighted managers saw that you could replace people with perl scripts, and when that means saved mony - well you're talking their language!

I have friends who admin and program windows boxes - they wish they didn't. If they used perl, their life wouldn't be as bad. My 2c ;)

We moved Perl into the Windows based Financial Company I work for. Simply by using it to automate tasks. We have 15k machines to manage and all of the backend processing on the accounts, the anti-virus and the package distribution slowly became automated, via perl. That was how we got Perl into the company. It wasn't even a conscious effort to get Perl in. When comparing it to other tools Perl was more efficient and allowed us a fast turn around time, and as for cost, it never really showed up on the budget outside of our man hours and the projects we used it for. In any environment Perl can be used in my opinion to efficiently process large volumes of data and automate the response to that data or organise the reports so support staff can respond more quickly. And in any type of shop there are jobs that are being doing daily, weekly, monthly that you can set perl up to do for the company so that it frees up those man hours to focus on the core value of the business. And any manager will appreciate that.

22. If you have an earnest desire of attaining to philosophy, prepare yourself from the very first to be laughed at, to be sneered by the multitude, to hear them say,." He is returned to us a philosopher all at once," and " Whence this supercilious look?" Now, for your part, don't have a supercilious look indeed; but keep steadily to those things which appear best to you as one appointed by God to this station. For remember that, if you adhere to the same point, those very persons who at first ridiculed will afterwards admire you. But if you are conquered by them, you will incur a double ridicule.

* rely on the great flexibility and capability of Perl
* esp. in the areas of large volume text transformation and report gen
+eration 
* in multi-platform glue tool scenarios
* to speed up programming and facilitate process automation 
* thus saving money and thereby earning management approval

Establishing this truth to a traditional big IT-shop management by :
* initially flying below the radar, not asking for formal approval 
* but starting to solve useful company problems 
* initially as a proof of concept (in your spare time)

The apps you mention are typically in the sysadm and tech.tool departm
+ent:
* sys.automation (patch/upgrade, build/test/backup)
* sys.adaptation (install, config, user scripting)
* sys.management (customer, interfaces, suport, bugs)
* tools (wiki, time managers etc.)
[download]