How about a tool used to simulate a portion of a cellphone network in order to test another portion. A few features of the tool:
- Updates took (usually) 10 minutes, once we got the info.
- Was used for 90% of the workload for 2 groups, and 50% for a third
- Was requested by both an internal group and a customer to be sold outside the company, in lieu of we were selling right now.
- One and a half people supported it, as opposed to the similar JAVA application, which required 20 people.
- Supported 3 incompatible versions of messaging (and could support more easily)
- The same code ran on both Unix and Win32. (We didn't release the Win32 version solely because of trying to figure out distribution issues.)
- Had its own scripting language that was used to automate over 10,000 tests, saving close to 25,000 man-hours per year. (That's not an exaggeration.)
And, I could've kept typing.
Now, it didn't have a ton of bells and whistles, but our primary users (engineers) didn't want them. I wanted to add them, but kept being yelled at. :)
Now, in case you're wondering about the merits of Perl, this is what they are:
- Ease of development. You might not release it in Perl, but you prototype it in Perl.
- Ease of maintenance. I've found that it's easier to keep something current in Perl, due to the speedier edit-run cycle.
- Extensibility. Something not in the language? Add it, at the compiler level!
- Ease of transition. Since it's easier to teach someone Perl than, say, C++ or Java, it takes less time for someone to come up to speed to take over your job.
Very frankly, most of the benefits of Perl over VB aren't easy for non-programmers to understand ... cause they're programmer benefits. And, Perl isn't for every job. For what I do, Perl is generally the best option. But, if I was going to sketch out a GUI, I'd use VB. If I was going to write an AI for a game, I'd use C (or asm). Not Perl.