Hacker News Reader

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-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

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.

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.

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.

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.

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.

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).

> 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.

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.

An example of this was the old, classic, counter.cgi which, when accessed would:

* Read a file containing an integer

* Increment the integer in memory

* Emit a .gif with the new value

* Write the new value back to the file

That's a bad order to do things, is that how it worked?

There is a huge window while emitting the .gif during which other visitors may appear. At best a new visitor appearing during another visitor's "emit gif" phase does not increment the counter, at worst a visitor on a very slow line causes the cgi instance for this visitor to run for a long time and then write back a very old value to the file, making the counter run backwards.

For things that matter, the counter reading+increasing should be an atomic read-modify-write. But since this is just a web counter, I guess it's sufficient if you at least keep the hazardous window very small (by not doing the write-back at the end).

I mean, these were slapped onto peoples personal pages right below an animated "under construction" gif and fractal looking background images. Accuracy was not a huge concern.

Heh yeah. It didn’t matter because there weren’t that many people hitting the pages. It was more of a thing to do that was cool because when it hit like a thousand you would be like “OMG a THOUSAND people all over the world have visited my page, what a world we live in”

And dynamic--anything dynamic--was completely insanely cool.

For this case, eventually consistent is good enough

If you're not locking the counter whilst reading, incrementing, applying, and updating it, what you're eventually getting ... isn't really consistency.

"A widely shared myth" would be more accurate.

Yeah, the "it's just a web counter, so maybe just keep the window small" suggestion I made in the end was not meant to say that this provides any consistency, just that it keeps the underestimation of actual visitors smaller.

By the way, I'm totally aware that those counters didn't matter, but I thought it's worth discussing anyway. Someone might read this and apply it to things that matter.

Kind of. The files need to be executable and need to have a valid Shebang. That was a common issue with Perl when developers uploaded from Windows, because the Shebang was now "/usr/bin/perl\r". ASCII mode FTP mitigated that, but was itself a terrible idea. Passing flags to Perl ("/usr/bin/perl -w") or putting env into it ("/usr/bin/env perl") usually helped.

Chmod'ing over FTP isn't straight forward in most clients, so it was much more complicated for beginners to get things to run than "upload those files, go to your browser".

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.

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)

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.

Sklar's "PHP Cookbook" was an O'Reilly favourite, now in it's 3rd edition.

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.

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

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.

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?

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.

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

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.

Perl had Mojolicious which was almost as good as Rails and a lumbering beast called Catalyst which was used at the BBC.

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.