6 ms·

Any analysis of Perl’s decline that doesn’t mention PHP is incomplete. Between the height of Perl’s popularity in the 90s and today, web development was the sin

Any analysis of Perl’s decline that doesn’t mention PHP is incomplete. Between the height of Perl’s popularity in the 90s and today, web development was the single biggest growth area, and PHP ate Perl’s lunch in that domain. Why did that happen? In my opinion, PHP had two major advantages over Perl: 1. mod_php for Apache could safely be run in a shared hosting environment, so hosting for PHP was cheap and ubiquitous. mod_perl couldn’t be run in shared hosting, so anyone doing web development in Perl was stuck with either using CGI, or paying for more expensive dedicated hosting. 2. PHP’s approach made it easier to get started for people who were new to web development, or new to programming entirely. This was important in the late 90s and early 2000s as a huge number of people started doing web development for the first time. By 2000, PHP was already the dominant “scripting language for the web”. If the Perl community had focused on improving web development, then maybe Perl could have caught up, but they focused on Perl 6 instead, and PHP continued its growth without much serious competition from Perl for web development mindshare. MediaWiki was written in PHP in 2002, and both Facebook and Wordpress were written in PHP in 2003. The article focuses on Python, but during the relevant time period (roughly 1995-2005) Python was a niche and unorthodox choice for web development. Python finally started to gain traction for web dev in 2005 (Django, Pylons, TurboGears, and web.py were all released that year), but by that point Python was mostly competing with PHP, and Perl was already much less relevant. In summary - the article focuses on how Perl lost the market for scripting, but scripting was always a smaller and less important market than web development, and PHP killed Perl in the web development market. If Perl had stayed relevant for web development, it likely would have stayed relevant in scripting as well, because programmers like to use languages they already know (see: JavaScript). Perl 6 was the nail in the coffin that ensured Perl wouldn’t catch up in the web dev race that it was already losing.

tyingq 6y ago
Excellent point. For the same reason, Ruby/Rails is worth mentioning too. The article does mention Ruby, but not Rails.
- alexhutcheson 6y ago
  Rails didn’t really pick up until 2005 either, by which point Perl had already faded considerably. The most interesting counterfactual is “What if someone had written something like Rails for Perl before 2005?” It was definitely technically possible, and it might have made Perl take back off (Ruby usage grew from basically nothing due to Rails), but the community’s focus on Perl 6 at the time made it much less likely.
  - cutler 6y ago
    Perl had Mojolicious which was almost as good as Rails and a lumbering beast called Catalyst which was used at the BBC.
    - alexhutcheson 6y ago
      Mojolicious wasn’t released until 2008, by which point Rails and Django had both been available for >3 years. Catalyst was released in 2005 (so still after Rails), and definitely didn’t provide Rails-like productivity. If Mojolicious had been available in ~2003 or earlier, it’s entirely possible Ruby never takes off, because developers could get similar productivity in a more “known”/“mainstream” language.
spookthesunset 6y ago
I agree with this. Deployment of Perl was a pain in the ass. With PHP you literally just FTP’d the files to your normal web directory and you were off to the races. Even today PHP still has that advantage over many other languages. To my knowledge even now you can’t just upload a bundle of .py, .rb or .jar files into a directory hosted by Apache and go. That being said these days the other languages become their own http server and are usually fronted by a reverse proxy or two. But still that is like an order of magnitude harder to stand up than PHP.
- tyingq 6y ago
  You can set up such that newly uploaded Perl, Python, etc, scripts are runnable as soon as you put them there. But, typically, you're using a template framework or other dependencies and don't want those things exposed to the web server. PHP initially worked well that way because you lumped your templates and code into one file.
- shagie 6y ago
  Back in days of old, I would upload a bunch of perl files into the cgi-bin directory for the server... or files that ended in .cgi into wherever in the htdocs directory. With some juggling of what the script that was the .cgi, it would have been trivial to make it launch Java and consume the data... but Java wasn't set up for that (and the startup times for a Java cgi would have been nightmarish).
- Evidlo 6y ago
  > To my knowledge even now you can’t just upload a bundle of .py, .rb or .jar files into a directory hosted by Apache and go. Doesn't that just depend on Apache settings? You can set up Apache to serve all requests ending in .py as CGI. As long as these scripts emit HTML the situation is the same as PHP.
  - darrenf 6y ago
    Small nitpick: it doesn't, and never had to be, HTML that was emitted. Executables were/are responsible for headers (including `Content-type`) as well as the body.
acomjean 6y ago
On PHP 25year birthday Rasmus Lerdorf talked about how php came to be. He literally thought something better would replace it at all times. https://thenewstack.io/php-creator-rasmus-lerdorf-shares-lessons-learned-from-the-last-25-years/ https://thenewstack.io/php-creator-rasmus-lerdorf-shares-les... I think he thought it would be Perl: "And Lerdorf tells an only-in-the-1990s story about the day when Perl finally also released its own optional embeddable module for Apache web servers — mod_perl. “They’d made it way too powerful… If you were on the virtual host on an Apache server, and you had mod_perl access, you could steal the requests from every other virtual host if you wanted to…” Because of this vulnerability, ISPs wouldn’t offer mod_perl alongside other clients in a single Apache instance. “So if you came to an ISP and said ‘I would like mod_perl‘, they would say, ‘Okay, that’ll be $600 a month,’ because back then, we also didn’t have VMs, containers, anything like that. So you had to have a separate, physical bare metal box for mod_perl. Whereas on PHP, you could put 3,000 customers on one machine, versus one mod_perl customer.” the 25 year php talk: https://www.youtube.com/watch?v=wCZ5TJCBWMg&t=315s https://www.youtube.com/watch?v=wCZ5TJCBWMg&t=315s
- pengaru 6y ago
  I was a sysadmin through this era, and we refused access to both mod_php or mod_perl on shared hosting accounts. Customers always received php-cgi. Even if one could convince themself mod_php was safe, it was so unstable version-wise syntactically and every webapp wanted its own snowflake combination of version and configuration and versions of dependencies like imagemagick/gd, it was simply impossible to satisfy all customers on a given host sharing a single apache+mod_php instance. By the time I left that role we had what must have been nearly 100 different php cgi builds in a global repository maintained on behalf of customers. Whenever a vulnerability came out we'd have to go revisit all these snowflakes and push fixes out. At least the pushing out was mostly automated since we had all the hashes, but the maintaining of the variously configured source trees and backporting of fixes was always a largely manual nuisance. In retrospect we spoiled our customers, and I learned PHP was a damn disaster area. At one point we forced all customers to migrate IIRC from php3 to php4 and in that transition we learned the previous version was ignoring such glaring syntactic problems as mismatched curly braces ambiguously delimiting blocks of code. What a nightmare that week was, before that we could largely ignore the contents of customers' scripts. But with so much broken we had to start looking at what they were doing and automating counting of open vs. close curly braces in php scripts across the fleet. What a horror show. Edit: forgot to mention shared hosting providers generally relied on suexec which only works w/cgi processes anyways. Nobody in the shared webhosting space cared about the subtle differences of mod_php vs. mod_perl, they were both irrelevant to anyone trying to isolate web customers sharing a single host.
cutler 6y ago
Perl 6 wasn't the main factor. In the early/mid-2000s Perl lost mindshare because it's PHP equivalent - HTML::Mason - relied on mod_perl which cheap hosts were reluctant to offer for many reasons. Perl's main web framework, Catalyst, was a beast and only a few big companies took it seriously. There was also Mojolicious and Dancer but they never hit the big-time either. Internally the Perl community fought with each other over how to implement OO. A Meta Object Protocal (MOP) was hotly debtated but the main implementation remained just a library. Likewise with Perl's main OO library Moose which spawned lightweight offspring such as Moo. TIMTOWTDI became a liability as competing scripting languages with built-in OOP (Ruby, Python & PHP5) ate Perl's lunch. Perl also lost a lot of mindshare to Python in the an area it had dominated for many years - system administration.
- alexhutcheson 6y ago
  Agreed mod_perl was a bigger problem in the critical time period than Perl 6. Perl 6 just made it so it was less likely anyone would fix the situation. Catalyst (released 2005), Mojolicious (2008), and Dancer (2009) were all released too late to matter.
tres 6y ago
Totally agree on point 2. PHP's documentation was always excellent, available and was always a quick Google search away from finding the relevant materials. It was tangibly superior at the time. Coding with other languages at the time always involved some kind of physical reference book (or some closed off "compiled" walled "context sensitive" help system whose search capability and discoverability was little-to-none). Although I had sooo many O'Reilly reference books, I don't think I ever had an O'Reilly PHP reference book... (Not sure there ever even was one because it would be totally unnecessary)
- cutler 6y ago
  Sklar's "PHP Cookbook" was an O'Reilly favourite, now in it's 3rd edition.
- rav 6y ago
  PHP's documentation is still excellent and is still available at the same place it was 20 years ago: Typing php.net/FUNCNAME in the address bar gives the documentation for FUNCNAME(). I'm glad my current work is only about 1% PHP and not the 100% it used to be, but whenever I need to edit one of those PHP scripts we still have around, I know how to get by, even though I'm seriously rusty.
agumonkey 6y ago
These two points should be in books because no matter how good you are, new market dynamics will eat you alive faster than you can blink if you don't address the actual needs. Think how brittle limited and fuzzy php was for so long, yet it's a major thing in IT now.
karmakaze 6y ago
I know both Python and PHP had numerous successful and moderately successful web frameworks. I don't know what it was like with Perl, was it still much more roll your own custom set for each app from libraries?
- petre 6y ago
  No, we had CGI.pm and a bunch of other stuff like Mason. Then came Plack and then Mojolicious and we threw out CGI.pm. Good riddance. I am so glad we picked Mojo over Catalyst or Dancer. Now the other two frameworks are basically dead and they were also technically inferior back then. Catalyst pulled 90+ something packages as a dependencies, Dancer was stuck at version 1.3 and they were rewriting it as Dancer2, which is still being rewritten at the pace of four patch versions every year. It'll probably be ready by the time Mars is colonized. Mojolicious just released it's 9th major version this spring, which has promises and other modern stuff. We started at 2.52 or something.
kazinator 6y ago
For any X, "PHP ate X's lunch" is going to be very bitter pill to swallow for proponents of X. :)
xnx 6y ago
This is exactly right and a story we see over and over again. A mature high-quality incumbent is defeated by an upstart that's inferior in all dimensions except the one that ends up mattering the most. At launch Google Sheets was worse than Excel in so many ways, but the online collaboration made it 10x better for all but the most specialized users. Imagine how different things would be in the alternate reality where the server-side JavaScript support of Netscape Server morphed into a mod_javascript module for Apache.
tluyben2 6y ago
We moved to PHP from Perl in the late 90s because of mod_php. It was just easier, faster & cheaper. We had a vast perl codebase we rewrote to PHP. Competitors here started to use Zope (Python) begin 2000s so we started to look around again and went over to Java which moved our company from little small/medium business clients, straight to enterprises (fortune 1000). The 'easier, faster & cheaper' went straight out of the window, but we did beat the Zope competitors in mostly all sales pitches.

tyingq 6y ago

Excellent point. For the same reason, Ruby/Rails is worth mentioning too. The article does mention Ruby, but not Rails.

alexhutcheson 6y ago
Rails didn’t really pick up until 2005 either, by which point Perl had already faded considerably. The most interesting counterfactual is “What if someone had written something like Rails for Perl before 2005?” It was definitely technically possible, and it might have made Perl take back off (Ruby usage grew from basically nothing due to Rails), but the community’s focus on Perl 6 at the time made it much less likely.
- cutler 6y ago
  Perl had Mojolicious which was almost as good as Rails and a lumbering beast called Catalyst which was used at the BBC.
  - alexhutcheson 6y ago
    Mojolicious wasn’t released until 2008, by which point Rails and Django had both been available for >3 years. Catalyst was released in 2005 (so still after Rails), and definitely didn’t provide Rails-like productivity. If Mojolicious had been available in ~2003 or earlier, it’s entirely possible Ruby never takes off, because developers could get similar productivity in a more “known”/“mainstream” language.

spookthesunset 6y ago

I agree with this. Deployment of Perl was a pain in the ass. With PHP you literally just FTP’d the files to your normal web directory and you were off to the races. Even today PHP still has that advantage over many other languages. To my knowledge even now you can’t just upload a bundle of .py, .rb or .jar files into a directory hosted by Apache and go. That being said these days the other languages become their own http server and are usually fronted by a reverse proxy or two. But still that is like an order of magnitude harder to stand up than PHP.

tyingq 6y ago
You can set up such that newly uploaded Perl, Python, etc, scripts are runnable as soon as you put them there. But, typically, you're using a template framework or other dependencies and don't want those things exposed to the web server. PHP initially worked well that way because you lumped your templates and code into one file.
shagie 6y ago
Back in days of old, I would upload a bunch of perl files into the cgi-bin directory for the server... or files that ended in .cgi into wherever in the htdocs directory. With some juggling of what the script that was the .cgi, it would have been trivial to make it launch Java and consume the data... but Java wasn't set up for that (and the startup times for a Java cgi would have been nightmarish).
Evidlo 6y ago
> To my knowledge even now you can’t just upload a bundle of .py, .rb or .jar files into a directory hosted by Apache and go. Doesn't that just depend on Apache settings? You can set up Apache to serve all requests ending in .py as CGI. As long as these scripts emit HTML the situation is the same as PHP.
- darrenf 6y ago
  Small nitpick: it doesn't, and never had to be, HTML that was emitted. Executables were/are responsible for headers (including `Content-type`) as well as the body.

acomjean 6y ago

On PHP 25year birthday Rasmus Lerdorf talked about how php came to be. He literally thought something better would replace it at all times. https://thenewstack.io/php-creator-rasmus-lerdorf-shares-lessons-learned-from-the-last-25-years/ https://thenewstack.io/php-creator-rasmus-lerdorf-shares-les... I think he thought it would be Perl: "And Lerdorf tells an only-in-the-1990s story about the day when Perl finally also released its own optional embeddable module for Apache web servers — mod_perl. “They’d made it way too powerful… If you were on the virtual host on an Apache server, and you had mod_perl access, you could steal the requests from every other virtual host if you wanted to…” Because of this vulnerability, ISPs wouldn’t offer mod_perl alongside other clients in a single Apache instance. “So if you came to an ISP and said ‘I would like mod_perl‘, they would say, ‘Okay, that’ll be $600 a month,’ because back then, we also didn’t have VMs, containers, anything like that. So you had to have a separate, physical bare metal box for mod_perl. Whereas on PHP, you could put 3,000 customers on one machine, versus one mod_perl customer.” the 25 year php talk: https://www.youtube.com/watch?v=wCZ5TJCBWMg&t=315s https://www.youtube.com/watch?v=wCZ5TJCBWMg&t=315s

pengaru 6y ago
I was a sysadmin through this era, and we refused access to both mod_php or mod_perl on shared hosting accounts. Customers always received php-cgi. Even if one could convince themself mod_php was safe, it was so unstable version-wise syntactically and every webapp wanted its own snowflake combination of version and configuration and versions of dependencies like imagemagick/gd, it was simply impossible to satisfy all customers on a given host sharing a single apache+mod_php instance. By the time I left that role we had what must have been nearly 100 different php cgi builds in a global repository maintained on behalf of customers. Whenever a vulnerability came out we'd have to go revisit all these snowflakes and push fixes out. At least the pushing out was mostly automated since we had all the hashes, but the maintaining of the variously configured source trees and backporting of fixes was always a largely manual nuisance. In retrospect we spoiled our customers, and I learned PHP was a damn disaster area. At one point we forced all customers to migrate IIRC from php3 to php4 and in that transition we learned the previous version was ignoring such glaring syntactic problems as mismatched curly braces ambiguously delimiting blocks of code. What a nightmare that week was, before that we could largely ignore the contents of customers' scripts. But with so much broken we had to start looking at what they were doing and automating counting of open vs. close curly braces in php scripts across the fleet. What a horror show. Edit: forgot to mention shared hosting providers generally relied on suexec which only works w/cgi processes anyways. Nobody in the shared webhosting space cared about the subtle differences of mod_php vs. mod_perl, they were both irrelevant to anyone trying to isolate web customers sharing a single host.

cutler 6y ago

Perl 6 wasn't the main factor. In the early/mid-2000s Perl lost mindshare because it's PHP equivalent - HTML::Mason - relied on mod_perl which cheap hosts were reluctant to offer for many reasons. Perl's main web framework, Catalyst, was a beast and only a few big companies took it seriously. There was also Mojolicious and Dancer but they never hit the big-time either. Internally the Perl community fought with each other over how to implement OO. A Meta Object Protocal (MOP) was hotly debtated but the main implementation remained just a library. Likewise with Perl's main OO library Moose which spawned lightweight offspring such as Moo. TIMTOWTDI became a liability as competing scripting languages with built-in OOP (Ruby, Python & PHP5) ate Perl's lunch. Perl also lost a lot of mindshare to Python in the an area it had dominated for many years - system administration.

alexhutcheson 6y ago
Agreed mod_perl was a bigger problem in the critical time period than Perl 6. Perl 6 just made it so it was less likely anyone would fix the situation. Catalyst (released 2005), Mojolicious (2008), and Dancer (2009) were all released too late to matter.

tres 6y ago

Totally agree on point 2. PHP's documentation was always excellent, available and was always a quick Google search away from finding the relevant materials. It was tangibly superior at the time. Coding with other languages at the time always involved some kind of physical reference book (or some closed off "compiled" walled "context sensitive" help system whose search capability and discoverability was little-to-none). Although I had sooo many O'Reilly reference books, I don't think I ever had an O'Reilly PHP reference book... (Not sure there ever even was one because it would be totally unnecessary)

cutler 6y ago
Sklar's "PHP Cookbook" was an O'Reilly favourite, now in it's 3rd edition.
rav 6y ago
PHP's documentation is still excellent and is still available at the same place it was 20 years ago: Typing php.net/FUNCNAME in the address bar gives the documentation for FUNCNAME(). I'm glad my current work is only about 1% PHP and not the 100% it used to be, but whenever I need to edit one of those PHP scripts we still have around, I know how to get by, even though I'm seriously rusty.

agumonkey 6y ago

These two points should be in books because no matter how good you are, new market dynamics will eat you alive faster than you can blink if you don't address the actual needs. Think how brittle limited and fuzzy php was for so long, yet it's a major thing in IT now.

karmakaze 6y ago

I know both Python and PHP had numerous successful and moderately successful web frameworks. I don't know what it was like with Perl, was it still much more roll your own custom set for each app from libraries?

petre 6y ago
No, we had CGI.pm and a bunch of other stuff like Mason. Then came Plack and then Mojolicious and we threw out CGI.pm. Good riddance. I am so glad we picked Mojo over Catalyst or Dancer. Now the other two frameworks are basically dead and they were also technically inferior back then. Catalyst pulled 90+ something packages as a dependencies, Dancer was stuck at version 1.3 and they were rewriting it as Dancer2, which is still being rewritten at the pace of four patch versions every year. It'll probably be ready by the time Mars is colonized. Mojolicious just released it's 9th major version this spring, which has promises and other modern stuff. We started at 2.52 or something.

kazinator 6y ago

For any X, "PHP ate X's lunch" is going to be very bitter pill to swallow for proponents of X. :)

xnx 6y ago

This is exactly right and a story we see over and over again. A mature high-quality incumbent is defeated by an upstart that's inferior in all dimensions except the one that ends up mattering the most. At launch Google Sheets was worse than Excel in so many ways, but the online collaboration made it 10x better for all but the most specialized users. Imagine how different things would be in the alternate reality where the server-side JavaScript support of Netscape Server morphed into a mod_javascript module for Apache.

tluyben2 6y ago

We moved to PHP from Perl in the late 90s because of mod_php. It was just easier, faster & cheaper. We had a vast perl codebase we rewrote to PHP. Competitors here started to use Zope (Python) begin 2000s so we started to look around again and went over to Java which moved our company from little small/medium business clients, straight to enterprises (fortune 1000). The 'easier, faster & cheaper' went straight out of the window, but we did beat the Zope competitors in mostly all sales pitches.