A more concise, but less fun, question would be, "What don't you use Perl for?" The lists would be much shorter. :)

• Blog platform (in Catalyst).
• Parsing data from diving websites and writing into Excel sheets.
• Server health checkups.
• Converting broken, nasty Project Gutenberg HTML to clean XHTML and automatically posting it.
• Ajax forms and user voting.
• Jokes, like Acme::LOLCAT.
• RSS/Atom writing and reading.
• Automatic tear down and rebuilding of databases; DBIx::Class::Schema::Loader + DBICx::Deploy.
• Reminder emails.
• Date counters and parsers.
• Graphing weblog stats.
• Filtering mixed text+html perfectly to clean XHTML with DWIM paragraphs and newlines.
• Perl code coloring.
• Chat server.
• Typographical auto-markup; e.g., (r) --> ®.
• RTF --> HTML.
• CSS collapsing and style inlining.
• Perl controlled rsync as part of build scripts.
• Colored XHTML document revision diffs.
• Tax calculators.
• Order tracking and manipulation.
• Language translation services.
• Search engines; raw, metaphone, vector.
• DB --> YAML --> DB.
• MP3 manipulation.
• Image stamping.
• Et cetera, et cetera

Language translation services.

I'm intrigued. Are you developing a machine translation system?

That's probably a bit out of my depth. :) I'm tying into a human language translation API. Korean --> German kind of thing.

"Perl code coloring."

What is that?

--
I used to drive a Heisenbergmobile, but every time I looked at the speedometer, I got lost.

Sorry, that's nondescript. XHTML/CSS syntax coloring to display Perl code. I've done it with Syntax::Highlight::Perl -- did a very buggy version with perltidy once -- in the past and PPI in the last year or so.

I know that Jonathan Rockway's Angerwhale does generic syntax coloring of many different languages (it's based on a package, the name of which eludes me right now). I keep meaning to look into it.

• shell (well, job control is lacking still)
• patch e.g Windows DLLs (proprietary stuff) to convert English messages to German, and other random hackery on binaries
• make our Java Witnesses emit shrieks of horror and go dump core - things done while they still debate interfaces
• avoid touching the stinkin' crappy SAP GUI
• just prove "it's possible"
• bend and twist my OS to rendition
• decorate myself with an aura of rare weirdness for using such an exotic tool
• ... (to be continued)

So, little useful stuff, except where needed. (update) Needed things:

• tools for de-centralized management of centralized DNS and DHCP resources (think QIP)
• glueing handles to SAP
• directory (as in X.400, LDAP etc) munging
• ... (to be continued)

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

(something tells me this thread will stick around for quite some time and will break some length records)

I use Perl for my school and job duties, which is solving computational linguistics problems. That involves dealing with XML, manipulating text files, dealing with encoding issues, interacting with other programming languages (like R) and using mid-complex data structures.

I actually use Perl for everything that needs programming and where I can use Perl. I found that since I started using Perl, there are more and more tools that I wrote among those I use. Whenever I do something regularly and it can be automated, it's time for some Perl. :-) These little thingies include a script for archiving mail from OKcupid.com, a script for timed saving internet streams (good when you're not at home when there's your favorite radio show), and TK program for sorting photos that you get from your digital camera.

I also recently started writing web apps in Perl.

What I don't use Perl for is system administration. I got used to Bash and standard Unix tools long before Perl and I don't feel a need to switch (however, some Perl occurs more and more in my command pipes :-) and I have aliased grep to pcregrep )

If you haven't seen it, do not deprive yourself of ack.

My dear mother, this is wonderful! Thanks for the tip. ;-)

Processing, management and distribution of scientific data:

• ingest : reading scientific format, extracting metadata, inserting into a database
• searching : SOAP front-ends to search the database (both client and server)
• browsing : web-based front ends to view browse products for the data
• federated searching : search aggregation to search multiple archives from a single interface, and query translation at each archive
• monitoring : making sure that the various processes (seem to be) running correctly
• ordering : user makes a request, we generate tarballs/zip files on the fly, or save to disk and notify them where it is
• reporting : generating metrics on usage (and some inputs need major cleaning first)

I've written a set of scripts that perform/automate the monthly billing cycle for a large agency. The system inputs are quite diverse and definitely need the sort of glue that Perl provides.

Inputs include:

1. Printer log files from Solaris printer servers
2. Printer log files from a proprietary Win2K3 printer server
3. Log files from IBM mainframe servers
4. A proprietary data collection application utilizing a MSSQL Server database
5. A manually maintained MS Access database containing > 20000 records

Since manual inputs are a big part of the system, it is important to validate that all data meets specified criteria and is complete.

I also generate logfiles and exception reports to support manual review/update of faulty data.

I got into Perl about three years ago wanting to convert an HTML version of a Word document to TWiki format retaining links and tables and splitting the document into appropriate pages for the wiki in the process. Since then I've used Perl in a range of tasks including:

• a range of scripts for an automated build system: validating HTML, validating dialog resources, checking version number consistency across projects, ... .
• (to be completed next year) the whole build management system re-written in Perl (currently C++) to allow coordinated build management across multiple computers and Operating Systems and managed through a database backend.
• a Tk application to draw teams for social games for a badminton club.
• a Perl application for generating Windows .msi based installers for our next product release (and a support module soon to be released to CPAN).
• An application that parses Microsoft Visual Studio compiler logs and presents an error summary using a tree control
• Lots of tiny utility apps for all sorts of daily drudge work.
• A very light weight emailing tool when our ISP decided spam could be prevented by limiting the recipient list for email to 20 addresses - which completely bollixed sending out a society newsletter I distribute.
• A web application that calculates diets given isotope data from archaeological sites.

and if any of these sound familiar, it's because many of them have appeared in some fashion in SOPW.

I'm still new, so as far as CPU volume, I think I've used Perl most for an online budget and stock market server for a Play By Committee strategy game I'm running.

It has a very high niftiness factor, since I was able to write the whole thing myself as a "Learn Perl project" with just a little bit of socket help from a template.

It started out as a telnet program, with regexes to parse instructions like "buy 5000 radioactives at maxprice 250 minerals", and I expanded it into a webserver with colours and icons and buttons :) (works great under anything but certain versions of IE :P)

And yes, I used strict, warnings, taint checking and paranoia right from the start

I've used Perl in the past to manage web applications, CGI and plain ol' dynamic web sites. I use it in maintenance mode now, since I run an installation of Bugzilla at our office.

That's much like the story of my professional life as well, save that I mostly deal in smallish projects which tend to be requested in PHP, so I say "I can do that faster, better, and cheaper in Perl" and they generally say "OK", so I rarely have to actually write/modify PHP code more often than once every couple months and can stick with Perl aside from that.

As for what I do with Perl...

• Web apps
• Logfile analysis
• Dynamic firewall rules based on what's found in those logfiles
• User accounting and workstation management for an internet cafe
• Web scraping
• Spam header analysis
• Scanning for "hidden messages" via equidistant letter spacing
• Automating system administration
• Fun
• Profit
• Impressing the hell out of the ladies clients

I'm totally with you on the Java and PHP front. We spent several months trying to bring Java into the mix. We've spent twice that trying to get rid of it completely. (nearly there). Java was a disaster for what we were doing.

All I wanted were some simple web pages talking to a database. I brought in very highly recommended Java experts. They had me with Hibernate and Springs and a host of other things (including using Eclipse as an editor). I asked them to do a few pages. The pages worked and then they showed me how many files were involved in the process. I nearly gagged. It was WAY over-engineered.

We pitched that and went with PHP and cranked out the app even with the delay we suffered from trying to go the Java route.

I'm not trying to dis Java. I just know it isn't for me, and I can usually out-code a Java person in terms of time and robustness. The only 'selling' point Java has in my company over Perl is that Java has become 'The Standard' (tm) so we have a million so-so java developers we can throw on a project. *sigh*

Good luck with the perl evangelizing. I hope it pays off in the end. Oh, and I haven't had to do anything in Windows for 10yrs+.

--
I used to drive a Heisenbergmobile, but every time I looked at the speedometer, I got lost.

Yep, ETL, log-file reading, dynamic web pages. Even Windows GUIs for myself and my colleagues.

Batch scripts too, and utility modules for sorting and printing out hashes nicely in 15 different ways - it's remarkable the number of fiddly, repetitive jobs Perl has helped me automate.

It gets to the point where you tie your shoelaces and think "Hmm - wasting time here. Surely a CPAN module.."

• Fun: Acme, Obfuscated Code
• Logfile parsing ( mostly throwaway onliners )
• Shell script replacements
• Unix tools improvements
• Web roboting: WWW::Mechanize + WWW::Mechanize::Shell
• Animating images: Image::Magick Template
• Generating statistics: Statistics::Descriptive
• Show ridiculousness of Java code

Well actually I use a mix of Perl and SQL. Most of the logic is in the SQL. But I need an interface between the SQL and the rest of the world, and the framework that interface lives in is all written in Perl.

Now that we have a real DBA (I'm really just a scientist), the tables may all migrate to the Oracle server but the Perl scripts will remain with only a few changes. Turning to LAMP can all be written off as my own unwillingness to devote my life to WIOA (Windows, IIS, Oracle, ASP) but using Perl helped me reserve a little time for my real job.

Even after the migration, Perl will always be my choice for manipulation of large amounts of data in and out of databases and large, proprietary scientific applications.

Anything and everything >:o)

But mostly networking with POE

And Windows system administration using Win32::OLE

Publishing these data on a web-server with Catalyst.

Running all kind of statistical tests on this data and publishing it with LaTeX (of course a Perl script using Template Toolkit writes the LaTeX file).

Lots of little tasks which IT cannot be bothered with and which are already finished before they have looked into it and found one more "Tool" to do it with (rather than learn a proper programming language).

• A script to emulate tar in order to rescue some data archived from a PrimOS box supposedly in tar format. Unfortunately, all the filenames had been truncated to 14 characters in the archive which meant that many filenames were identical and files were being overwritten when extracted using /usr/bin/tar. This was my first *big* script.

• A script to find duplicate files in multiple directories recursively.

• A GUI script using Tk to check my lottery tickets. The script works much better than the tickets, sadly ;-(

• A script to synchronize a partition between two machines using FTP.

• A module to replace File::Find by something with a nicer interface. Seems to work ok on Solaris and Linux, will try and get it working on Windoze one day.

• Various ad hoc scripts to help people out of difficulties. They are usually amazed at how quickly Perl can solve the problem, (most work in house is Java).

Having started with Fortran IV and Cobol, moving on through PDP-11 assembler then C and Fortran 77, I am still amazed after ten years how Perl can cover so many bases and make my life so much easier and more enjoyable.

Cheers,

JohnGG

My corporate overlords require the use of ClearCase ™ but we wise and genlte serfs use subversions for our day-to-day operations. We use ClearCase when we have to. And that's when we deploy to production. So have you got some recommendations for perl + ClearCase integration?

--
I used to drive a Heisenbergmobile, but every time I looked at the speedometer, I got lost.

Yeah I am acquainted with Perl+CC intergration.Throw something lemme see how good I am :[

---

The world is so big for any individual to conquer

Uses I remember:

• web backend. I've never touched PHP in my life.
• windows desktop scripts for all types of file manipulations and anything else I can automate (ex: rename all files to this mask)
• image processing where I need to get down to the byte level of files like TIFF and PDF.
• simple data migrations
• ETL
• scrapping
• learning regex about 5 years before any of the Window dev drones even heard of it.

I have been using Perl since 2 yrs.
And I managed to imagine a soln for any requirement at work, with Perl.
I have been writing utility scripts that ease my work.
So I use it for:
> automate tasks
> parsing log files
> parsing excel, xml files
> generating excel files (reports basically)
> utility scripts (eg. play mp3 files)
The best was, a framework developed using only Perl to automate testing of Video Streaming.

I am amazed at the options Perl offers you to give a soln.

Truly, "You more than one way to do anything, with Perl"

At work:

• Configurtation management automation (deployment control, et al. with CA Allfusion Harvest Change Manager)
• System administration
• Test scripting

At home:

• Cryptography hobby (See brief discussion on my home node)
• My daughter is doing a Science fair project on the affects of Caffeine on Memory and needed several lists of random numbers. I got exactly what she needed in a Perl one-liner and redirected straigiht to the printer. It was 10 minutes including the time to download Activestate.

• Processing camera input
• Generating graphical OpenGL output (OpenGL::Simple, attempting to use OpenGL, a few others)
• Processing SDL events (keyboard, mouse)
• Sending and receiving automated Jabber messages (Net::Chat::Daemon) to monitor autobuild system, wiki edits, manual builds, etc.
• Interfacing between C++, JavaScript, and Flash code
• Monitoring revision control systems and running checks, sending out commit messages, figuring out who to blame for the commit(s) that broke the automated build, etc.
• Implementing Perl-style "regular" expressions with backends in Perl5, Parrot, and C.

From time to time I wonder that, too. Here's my somewhat shy reply...being just a newbie to the Monks.

I have been using Perl for about 4 years now. I am a Chief Sys Engineer building and flying satellites.

Our satellite integration and testing teams have (for several years before I got involved with Perl) used Perl to script and automate their testing to confirm that our satellites are ready to go into space. I got involved in Perl just to understand what my I&T teams were doing...and I got hooked.

We use the same ground systems for testing that we also use to fly the satellites and I am also one of many Flight Directors for flying the satellites. I realized that the same scripts that we used for testing could, with a little modifications, enhance and improve our on-orbit oversight and management of the satellites. We have since begun using Perl as a tool to much more flexibly and fluidly manage some of our on-orbit operations.

I am not much of a programmer, so I try to utilize some of our Perl gurus to do most of the script development work. But I dabble and do some of my own, too.

The Perl language's ability to rapidly prototype, try little ideas or snippets of code, often it's compactness, and its cross-platform portability (which allows us, often, to prototype ideas on PCs and then implement them on Solaris workstations) makes Perl ideal and, certainly, it is our language-of-choice.

None of our scripts are very complicated and none but a few are more than 50 lines of code (typically). The power and expressiveness of Perl has allowed us, even with such small scripts, to implement some pretty powerful capabilities. For example, one such script is a meta-interpreter that allows our flight controllers to specify functional spacecraft activities (e.g., "go to this place and do this within such-and-such constraints") and auto-generate the spacecraft command loads (often several hundred commands) for the satellite that are auto-verified, repeatedble, and reliable...a task that used to take my controllers over a day or two. They can do the same task in only a few minutes.

Perl has become "my (and our) friend" and contributes to satellite test and operations for us.

As a side note to my reply, one of the "challenges" of using Perl is that, in our environment, we can't bring in "external code" (i.e., code that we, ourselves, haven't generated) other than the Perl distrubition package itself.

The consequence of most pain to us is that we can't really avail ourselves of rich set of tools from CPAN...a most distressful situation...but our security and strict configuration controls necessitate this sad state of affairs.

However all is not entirely lost, as we *can* bring in code we've developed and/or tested ourselves. That is the paradigm that allows to, for example, develop and test code on the PC and then port to the Solaris.

So, we can, for example, download CPAN modules, test them, develop with them and then port them over to the Solaris and simply include them (in the form of saving them in the same directory as our scripts as *.pm files) as we do the libraries that we, ourselves, have created.

That works surprisingly well most of the time but it has the disadvantage of being libraries that are not "installed" in Perl...i.e., that aren't automatically gathered together with their other "required modules" and made automatically known to our apps.

So we have to do the painful task of figuring out all of the "required modules" and then figuring out all of those modules' "required modules", etc. and then loading them into our app's directory(ies)... actually we have a standard library directory that all of our apps know to use and is in our path statements.

Hence, we tend to only use the CPAN modules that meet our needs AND that don't require any other modules (at least any other than the ones that come pre-packaged with the Perl distribution).

Unfortunately, of late, we have found a couple of CPAN modules that we'd really like to use...but they seem to have an unending "deep-dive" set of "required modules". That is a real "frowny face" for us.

ack Albuquerque, NM

It was me answering. For some reason, I wasn't logged on ...