Perl is a historically a combination of bash, awk and sed.
There's the first clue that this is a troll. Perl was devised to replace the model of using a Unix shell to wire together bits of sed and awk, but the shells that informed the creation of Perl through v4 cannot have included bash unless Larry Wall has a time machine. There's certainly some sh influence in Perl and maybe csh as well, although one could believe that the influence was a desire to redeem the idea of a C/sh hybrid from the mutant horror of csh.
And for purposes well suited where people would use the former three tools to implement shell scripts to help administration tasks on a daily basis. However, Perl is not so well suited for other purposes, like small and medium sized web applications.
Um, yeah... because apps like Slash, RT, and Movable Type are really large and frameworks like Mason and Catalyst are overkill for anything modest. Or maybe I am reading you wrong?
More directly: It is absolutely true that a lot of sysadmins use Perl as a shell alternative for text processing and that it has its roots in that problem space. However, it also was the overwhelmingly dominant language for web application development for many years and its extension to that job largely defined the functional space for what a web application language has to do. Perl is a procedural language from its roots, but it also has a mature object implementation and a rich universe of modules using it that include multiple frameworks for web applications. IMHO most of the perception of Perl as less "suited" for web development is a result of the diversity of Perl code aimed at the web. There isn't an obvious single stack of Perl modules to use as a basis for all web apps (i.e. an analog to Rails) but rather a bazaar of options that make sense for different sorts of app. It is certainly NOT suited to casual amateur web development.
Therefore, it will not gain any more ground in that area, as better tools are available. The first Perl enemy was PHP. While PHP sucks in many ways, it was better designed to write simple dynamic web pages.
Not really "better" but rather "only," at least in its origins. It is inevitable that a language created to be web-specific at a time when most web development was done in languages designed for more generalized use (e.g. Perl) would be better fit to that specific purpose, at least in the most trivial ways. It certainly makes PHP more accessible for low-skill coders, a fact demonstrated by the unending stream of fundamentally simple security problems in widely-deployed PHP code.
Today it is used for medium sized web applications, which is clearly a dangerous thing, but still it restricts the growth of Perl in that direction, as younger coders came first in contact with PHP and all the hosters support PHP, but not everyone is supporting Perl. Also things like Joomla or Typo3 are PHP based and many people start coding by extending them.
Yes, PHP has largely soaked up the pool of interest of casual code tweakers and it is much easier to offer commodity-grade hosting with credible PHP functionality than it is to do the same for any other language/platform. That was arguably true for FrontPage some years back and we all know how it managed to take over the world.
For custom application or other mostly larger system Java-based or .NET-based technologies are used. Perl has nothing to do in that area. It lost its job there many years ago. InterShop was once coded in Perl, but - well - who cares?
There is more diversity in large-scale and custom enterprise web applications than you admit. In many cases big Perl systems have not lost their jobs, they've just matured and stabilized. Movable Type is a great example: it is still the engine behind a lot of very large websites but it has lost buzz to weaker platforms over the years because it isn't constantly being updated for idiotic security flaws and has never been suitable for commoditized deployment by low-clue hosters. It isn't being displaced by anything else, rather it has become part of the mostly stable infrastructure of those who use it rather than something that demands constant attention.
As the Unix command shell is only a limited realm (in number of installations), Perl will never become that widespread again. At least that is my assumption considering today software base and structure, as well as the education in programming languages.
A non sequitur based on a ridiculous assertion. The idea that Perl is somehow dependent on the "Unix command shell" (by which I assume you mean a shell similar in function to the classical "/bin/sh" on an OS that is significantly Unix-like) is delusional. Referring to the number of installations of such shells as a "limited realm" is a formal truism in a finite world and the limitation is further constricted by the existence of Windows servers, but it is a bit misleading. The fact that a web developer or website content owner can't run an interactive shell session on a server is no indication of the existence or other use of a shell on that server. It is also not inherently an impediment to the use of Perl for web development on a server. The most significant commonality between Perl and shell is that they are almost universally installed as core tools on non-Windows/non-mainframe platforms.
