Perl
Perl was the original web application language, glueing together bits of legacy systems, parsing user-supplied text and printing HTML via STDOUT through CGI to the web server. As web sites grew in popularity outside academic circles, CGI's performance limitations became more relevant, and Perl's stock as a language for web applications dropped in the face of non-CGI competition from PHP, ASP and ColdFusion, whose architectures further benefited developers by allowing the insertion of code within their HTML pages.
But Perl has rallied in the face of these upstarts: mod_perl now allows Perl developers to embed their favourite language within Apache, removing the performance restrictions of the traditional CGI approach. And a slew of templating systems (Mason, HTML::Template, the Template Toolkit) do a better job of separating code from presentation than Perl's peers. New systems such as Maypole also allow Perl to shine for small database-driven web applications.
However, we believe that Perl's ubiquitous strapline - "there's more than one way to do it" - marks its ultimate unsuitability for large scale web applications involving a team of developers. It's cultural rather than technical: Perl hackers tend to be a fiercely individualist bunch, fending off imposed design patterns and coding conventions, and delighting themselves with devilish shortcuts and opaque regular expressions.
Our uses of Perl, therefore, are typically standalone mini-applications, written by one coder for cases where Perl's text-processing performance and rapid application development abilities make it shine. We recently rewrote a link compilation shell script (using GNU sed, grep and find) in Perl - whose regex support allows the evaluation of a substitution string with an expression - resulting in a 480* performance improvement. We also consider using Perl templating systems (such as Maypole and Mason) for small web applications.
