I'm going to echo a few things already said here, mostly by jeffa, so forgive me. :-)

I am rather sad to admit that I have written more lines in ColdFusion Markup Language (CFML) than in Perl. Each have their strengths and disadvantages, and it's important (as has been mentioned) not to "defend" Perl (nor, for that matter, to "attack" me^H^HColdFusion) but to realize that each technology has it's strengths and weaknesses.

Alongside the development of three intranets and a handful of e-commerce sites in ColdFusion, I was coding up barchart generators and webserver logfile parsers in Perl. I really got a firsthand look (always the best) at the two languages and how they butt up against each other. ColdFusion is incredibly simple to learn and deploy, and really is the epitomy of Web RAD (Rapid Application Development). Take this simple example:

<cfquery name="ProductList" database="#DSN#">
    SELECT Name, Description, Price
    FROM Products
    ORDER BY Name
</cfquery>

<table border="0">
<tr>
    <th align="left">Name</th>
    <th align="left">Price</th>
</tr>

<cfloop query="ProductList">
    <tr>
        <td>#Name#</td>
        <td>#DollarFormat(Price)#</td>
    </tr>
    <tr>
        <td colspan="2">#Description#</td>
    </tr>
</cfloop>

</table>
[download]

It really doesn't get any easier than that. At the time, developing for a Windows platform, the only other option was really ASP with VBScript. PHP hadn't arrived yet, DBD::ODBC was still in it's infancy, and we needed a fairly robust, easy to learn and use solution. Enter the Dragon, as they say. It also had the advantage of being portable to Solaris Unix (to contradict an earlier poster, CF is cross-platform, albiet not nearly at the level that Perl is).

Backend programming wasn't really a problem (again, to contradict an earlier poster) because ColdFusion came with a scheduler that could be used to run pre-written scripts and specific intervals and times. It has a decent collection of functions for any data type you can imagine (especially dates and times, let me tell you) and could even perform regexps without too much of a hassle. Not only that, but it came with a binary file search engine (PDFs, Word docs, spreadsheets) that was simple to setup and even easier to use. How can you lose? ;-)

I'll tell ya. CF's worst failing points are where Perl steps in and whoops butt:

• Speed
  It took a dual Pentium II 400 running NT 4.0 to host a 20-user corporate intranet. The language overhead was nothing short of incredible. Far, far worse than the so-called "slow as beans" Perl interpreter.
• Complex Operations
  Anything more complicated than adding a day to a date or tokenizing a string required LenghtyBunchesOf(ReallyLongFunctionNames(ThatWereTediousAndPainfulToType()))). Compare this to a little =~ and @%$ magic and the winner is obvious. But maybe not to everyone. :-)
• Flexibility
  CFML was built for database-to-web programming. That's it. No more, no less. Perl can wedge itself into almost (ALMOST darnit) any place imaginable.
• Cost
  This is the killer. Not only did you have to pay for a powerful server, NT 4.0 and licenses, MSSQL and licenses, but a $1300 software package and $200 development suites. Yeah right!

Knowing what I know now about Perl, Apache, DBI and friends, I probably would have never put myself through the hell that I went through if I could have avoided it. <flame retardant>I actually enjoy programming in Perl. I really didn't in CFML. Perl is just a "better" language.</flame retardant>

Hope this helps to clarify things a little more, and hopefully my incessant rambling didn't put you to sleep...

Alakaboo