in reply to Perl for the Masses?

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:
  1. Updates took (usually) 10 minutes, once we got the info.
  2. Was used for 90% of the workload for 2 groups, and 50% for a third
  3. Was requested by both an internal group and a customer to be sold outside the company, in lieu of we were selling right now.
  4. One and a half people supported it, as opposed to the similar JAVA application, which required 20 people.
  5. Supported 3 incompatible versions of messaging (and could support more easily)
  6. 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.)
  7. 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:

  1. Ease of development. You might not release it in Perl, but you prototype it in Perl.
  2. Ease of maintenance. I've found that it's easier to keep something current in Perl, due to the speedier edit-run cycle.
  3. Extensibility. Something not in the language? Add it, at the compiler level!
  4. 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.