Hacker News Reader

Comment by dexen | Hacker News Reader

There is something to be said about PHP's staying power. The early versions of the language weren't considered "right". Except maybe they were right for the problem at hand.

The way I see it was PHP captured the vector of change, and left ample room for future developments. Both internal changes (hello, bytecode; hello, JIT), language level features (hi there, namespaces), and runtime level features (oh hai, countless built in classes and functions).

Moreover, unlike many framework that shone brightly and burned out quickly (Rails?), PHP captured the essence of the environment: HTTP is stateless, and URLs aren't uniformly routable from either end, and well-formed HTML/XML/JSON is just a subset of tag soup.

Worse is better.

View on HN

I think PHP had a couple of obvious advantages - it almost had a "first mover" advantage in that it happened to be installed alongside CGI-BIN on shared webhosts way back in the way - plus Drupal and WordPress being PHP projects.

But to me, one of the most significant advantages PHP has is that its documentation is terrific. PHP.net is simple, clear about parameters and return values (as clear as PHP lets it be anyways) and best of all has a terrific comments / examples section for each function.

Better documented is better.

Things may have changed since v7 but historically I’ve not found PHPs documentation any better than any other language.

In fact I remember a few occasions where I’ve ended up going by the advice of the comments rather than the documentation itself because the documentation was either out dated or just plain wrong.

Perhaps not better, but there certainly have been worse.

As for the comments. Yes. But at least they're there, and quite often helpful. Plenty of times I've read other docs where I wished they had commenting but alas didn't.

The comments are only needed because the documentation is often wrong or confused. And, of course, usually most of the comments are wrong too.

Other languages don't need comments because they at least aim to have documentation that's correct.

If you find the documentation wrong or confused please let us know. https://bugs.php.net/ We do our best. I was granted access some ten years ago and whenever I find a confusing page I fix it. I know there has been terrible pieces before but for the last oh five or six years I don't really find anything too bad. Please let us know what you found wrong. Thanks!

I was mostly responding to the idea in an ancestor comment that PHP has unusually good documentation (better than that of other languages), "best of all" having comments.

I'm sure the PHP documentation is getting better all the time! Other languages also have good documentation, though. And as pushpop said in an earlier comment, the reason that the comments were useful historically is that the documentation was not always correct or complete. (Perhaps in part because the the language used to have a lot more unintended quirks?)

I don't see it that way. The comments are there to prevent others from re-inventing the wheel, to share insights, etc. Yes, sometimes that also highlights a "bug" or some other "flaw" but that's the rare exception.

Maybe it would help if you listed some links to language docs that you feel the rest should use as benchmarks?

"Often wrong"? Really? By often, 50% more wrong than right or less? Or more? I can count on one hand the number of occasions I've found the documentation to be incorrect.

"Often" is a fuzzy term and it's used subjectively here. It doesn't mean "most of the documentation" (which would be the >50% goal post you're driving at). It simply means "a lot of the time $OP checks the docs". It might be the case that the only time they need to check the docs is for some of the more advanced features of PHP where errors are more likely to be found in the docs. While you could correctly argue "selection bias", it doesn't still take away from the OPs perspective that it often happens to him.

That has not been my experience but anyway there's a "Report a Bug" link on every doc page.

That hasn’t always been there. Or of it has, then the maintainers haven’t ever done anything with bug reports because there have been errors in the docs for the entire life of 5.x.

I don’t really recall earlier versions of PHP being any better either. So I really don’t think PHP became popular because of the docs.

The other comments about how it was easy to learn and easy to deploy is far more accurate. If I recall correctly, back when PHP gained traction, your main options then were Perl (which understandably confused the hell out of a lot of people), ASP (VBScript / JSScipt and requires Windows NT + IIS so not a popular option) or JSP (Java and at that time was pain to deploy. So not something you’d expect a casual web developer to bother with). So PHP is like BASIC or Raspberry Pi of the 90s web. It was made for one specific job, it didn’t do it perfectly, but it was cheap, easy to learn and just about good enough to get the job done.

Maybe this is true, but by virtue of its popularity and ease of use, PHP has one of the largest selections of tutorials on everything, so that it’s possible to write code by just copy-pasting example snippets.

Maybe within one very narrowly defined field. However move outside of your typical web services and tutorials take a sharp nosedive.

Really the kind of stuff that is well documented in PHP is the kind of stuff that is well documented in most general purpose languages. They are also the kind of problems that aren’t particularly hard to solve anyway.

But this is a moot point because the reason documentation was discussed was because it was credited as being one of the reasons for PHPs popularity. However tutorials wouldn’t exist if a language wasn’t already popular so your comment doesn’t reinforce the point made by the GP.

"it almost had a "first mover" advantage in that it happened to be installed alongside CGI-BIN on shared webhosts way back in the way"

That's a good observation. Because the mod_php and mod_perl Apache modules were much faster and lighter weight than CGI-BIN, and pre-installed on shared hosting, both PHP and Perl dominated the early web days.

Not sure about lighter. Mod-perl at least was quite RAM-hungry if I remember.

Lighter than original CGI-BIN, fork() and exec() for every request.

Faster, yes, but not lighter on RAM usage.

When / where was mod_perl ever widespread? Perl was usually provided via CGI, and php was mostly deployed with mod_php back in the day which gave it a great speed advantage, often at the price of security.

When? Before 2000.. php came after PERL. PHP wasn't a serious language was the general though. ASP was seen as that.. or Java/JSP

I know that Perl was earlier, I've worked with Perl before PHP came around. However, I've never seen a shared hosting environment that offered mod_perl, they were all using CGI.

Might be region specific, I've mostly worked in Western Europe, but even the two NA-based providers I've used back then didn't offer mod_perl for shared hosting.

You could certainly get it on a managed server, or set it up yourself on your dedicated box, but PHP's strong suit was the low-end shared hosting options. It ran anywhere, and usually fast.

I haven't found PHP documentation to be better or worse than the documentation of other languages I've used.

What I dislike about it is the comments that every page includes. Most of them are very poorly written snippets of code from 15 years ago.

If you dislike those comments too, consider adding this to your ad blocker:

    php.net###usernotes

Seriously? On the spectrum of things worth ad blocking, this would never even hit my radar.

I use uBlock Origin and its :style() feature to remove and modify parts of websites that I don't like.

I don't block user comments on PHP doc pages out of spite, I do it because they are very long, making it harder to scroll vertically on the actual documentation.

How does comments at the bottom make scrolling harder?

Not OP, but for me (as a potential example) there are websites that I want to scroll up and down on to view different things, but when you scroll down far enough websites have an annoying habit of auto-opening the comments at the bottom, suddenly tripling (or more) the length of the page, making me lose my spot on the page (potentially) and also making it harder to scroll with precision and/or need to scroll through all this new content I didn't want.

Its a minor quibble on desktop, but on mobile its a really annoying feature because I have to manually scroll with my finger for an age.

Doesn't your browser scroll much faster when you swipe twice in quick succession? I mean while the scrolling is going on, you swipe again and in worst case a third time. I never need to swipe more than three times unless the page is gigantic.

>Doesn't your browser scroll much faster when you swipe twice in quick succession? I mean while the scrolling is going on, you swipe again and in worst case a third time. I never need to swipe more than three times unless the page is gigantic.

Yes, but then if I'm looking for a specific part it has scrolled way past and I need to then scroll back down, sometimes past it, and then scroll back up. Bearing in mind I have to scan the page as it flashes past too.

It's a frustrating experience.

fortunately the date the comment was posted is very prominent on the page

I've actually found many of the comments rather useful over the years, and although I'm not crazy on how old and random they often are, I find them at least worth a quick look.

I've also found that the comments sometimes have very useful notes.

There is the issue of bad advice, but recently I've noticed that there seems to have been a voting system introduced at some point (not sure how long that's been there, I was away from PHP for a good chunk of the last decade), and I think the moderation system is older, so in theory, some of the worst advice should be filtered down/out and some of the best should be filtered up.

> Better documented is better.

I was talking to some kid who wanted to be a developer, and I echoed this sentiment. A complex tool with good documentation is easier to use than a simple tool with bad documentation.

I learned to program through php and the documentation was a major part of that before the prevalence of stack overflow etc

Nah, PHP survived because it wasn't strict, it tolerated a lot of crap. It would process almost anything it can and not fail. Most other languages would error out seriously. Also it's model of running each request as a fresh process eliminated persistent bugs. PHP's documentation is garbage. I say this as someone that has made money handsomely from PHP. :-).

> PHP's documentation is garbage

Birds are Cats.

See, we can all make unsubstantiated claims.

Why do you say PHP's documentation is garbage?

Just one reason is enough. I personally disagree, I think it's great.

the very first first mover advantage was that php was the free alternative to asp, jsp, and coldfusion. all of these languages were built around the simple premise that web devs wanted to inject code into html, which is the way beginners tended to think about coding.

asp locked you into microsoft, jsp was laden with heavy/expensive java app servers and semantics, and coldfusion was a paid product (and eventually locked you into macromedia/adobe).

i think that if coldfusion had the same free+paid model as php, it would have taken the place of php in web history. despite its faults (maintenance and performance, for example), it was easier and faster to learn and matched the mental model of beginners, just like html itself.

PHP started in 1994 and was released in 1995. It was the alernative to writing C code inside the web server (like CERN's httpd) and recompiling the server, or doing everything via CGI. (Yes, hacking servers was a thing. In 1994 I worked on a project in which I did exactly that. This was before Apache and modules.)

ASP 1.0 was released in 1996. The first Cold Fusion in 1995. JSP not until 1998.

Cold Fusion and PHP appear to be neck-and-neck, almost; it's plausible that if Cold Fusion had been free, it might have taken more mind share away from PHP.

Interpolating results into HTML dynamically isn't an idea that originated with any of this software. Prior art is the shell "here document", also implemented by imitation in Perl and other languages. "Here documents" were used in CGI scripting before PHP. (I'm not saying that the shell's "here document" is the ultimate prior art, either).

At your system prompt:

  $ cat <<!
  <table>
  $(for x in 1 2 3; do echo "  <tr><td>$x</td></tr>" ; done)
  </table>
  !

  <table>
    <tr><td>1</td></tr>
    <tr><td>2</td></tr>
    <tr><td>3</td></tr>
  </table>

I think PHP endures because it does one thing and does it exceptionally well. There is no other tool that makes the creation of simple dynamic server side web sites as easy and accessible. Simple FTP/SCP deployment to the server is such a killer feature.

It is also one of the few choices available on cheap shared hosting sites.

PHP was practically "serverless" before serverless was even a thing. You just deploy your code with ftp, rsync, git, or whatever. There's no step 2.

How is syncing your PHP code with the server serverless?

and now you see why "serverless" is misleading.

"serverless" now means you don't run your own web server, you use someone else's.

That's not what serverless means. It means that your code isn't running on a specific server, and between requests it isn't in any kind of running state whatsoever. It's effectively in cold storage until it's needed, then it's pushed to a frontend/edge server and run. Serverless doesn't mean that there's no servers anywhere, but rather that you don't have a webserver or set of webservers that your code is on; it goes onto a webserver when it's needed, and not before.

serverless and compute-on-edge are different things.

Which is what the earlier poster was alluding too. PHP code is stateless and sits there not taking up any resources until it is needed.

PHP hosters have been doing this for 20 years. You have 100s of customers on a single machine, running with a single Apache/PHP process (and child forks), and only if that Host+URL of a customer is requested that PHP code actually gets executed, then completely discarded from memory after its finished.

PHP is very much comparable to serverless. All that talk about bootstrapping costs in serverless is something PHP developers have been tackling forever.

This is a very silly equivalence--you're just glorifying vhosts and method dispatch.

The mechanism isn't the point (and vhosts aren't really either). The point is what a developer (or ops) has to think about when deploying, and in this regard, the default PHP model has a lot in common with serverless.

I don't see a difference there, PHP code can run on any webserver your hoster operaters provided they route the request correctly (I've once used a web provider that would rsync your PHP code to a geolocated DC if they detected more traffic from your region). If this is via vhosts or other routing methods is almost irrelevant, PHP code behaves extremely similar to "serverless" code (except it's often much cheaper).

You still have to deploy to Lambdas.

I believe the post you're responding to was alluding to the degree to which a lot of single-file PHP/HTML is written in a very "serverless-esque" way: no dependencies on an outer framework, and likely scales quite far compared to other languages when run on any number of servers (with the required libraries).

In addition to what you mentioned, with PHP there's no need to start, restart, monitor, or otherwise manage your own daemon. Apache and/or PHP-FPM does that for you.

That's not a PHP thing, it's a CGI thing. You can use any scripting language to do it. Perl was popular but you could use Python or even bash.

Exactly this. I've been doing back-end development for work the last 7 years, first Java then NodeJs and I'm now playing with the Rust web backend (still very early-stage but promised to a bright future IMHO) but my personal blog is still PHP, and so was my wedding's website. Being able to drop a file through FTP on a 2€/month shared server is so convenient!

PHP is the VBA of the web: it's ugly but too useful to ignore.

The other thing it does excellently is that you can take any .html file, renamed it to .php and add some <?php code ?> and it'll work.

In a previous site of mine i had the entire site be statically generated but needed some server-side stuff in one of the pages, so i put something like %%PHPCODEHERE%% and modified the script that built the site to replace the %%PHPCODEHERE%% with the contents of a .php script.

> There is something to be said about PHP's staying power.

The only reason I use php for my own sites is because I don't want to administer any server and I don't want to be tied to a provider.

PHP is a good fit for this, because it's available at practically all cheap hosting providers (I don't need to administer the server with shared hosting) and I'm not tied to a single provider, because I can switch to an other hosting provider without too much effort.

With other langauges I either have to manage my own VPS (I don't want to pay for managed VPS), or I'm tied to a provider (Appengine, etc.).

Same here, I used to wrestle with PHP, then I just accepted that the best path to make a productive use of my time was just to use it, the same way as you do.

I agree with just about all of your post except using Rails as an example of something that burnt out quickly. It was the most popular web framework around for the best part of a decade and is still being chosen for new projects.

Rails was popular among those that never saw such approaches before, like on AOLServer and Zope.

I just kept using Java, .NET and C++, while enjoying their performance, IDE tooling, and whatever ideas they could bring into their web stacks.

Nowadays most cool companies that were pushing Ruby, are on JVM languages.

I think your view is skewed and doesn't reflect what actually happened in the mid-00s.

All views are correct. Look at the number of jobs in cities around the world. Ruby was 1 in California but no where else during that time period.

Skewed from European enterprises point of view.

I only got to know one start-up doing Ruby (not Rails), which happened to rewrite our Perl deployment scripts as a project subcontractor, as they didn't had anyone with Perl knowledge.

Rails was never the most popular framework. But for a certain geography it was. Those were the anti-java crowd.

Part of its staying power is also due to Wordpress. If you're looking for an off the shelf CMS you'll almost certainly be considering Wordpress, Drupal, Joomla, et al.

I could be wrong, but I think the ubiquity of those frameworks/CMSes is rather due to the language's success rather than vice versa. Web hosts made the near universal decision to support PHP as a dynamic language at some point, and the frameworks that were built in PHP then thrived on that. Wordpress wasn't that popular back when I started out with PHP, but PHP was already universally supported by web hosts (hence my learning it). The switch from, uh, I don't know what came before (Perl? Or just a jumble of different languages called by CGI?), to PHP as universal dynamic hosting language, is before my time though.

From my memory (which is not the most reliable source) it was a co-dependent relationship initially. PHP gained acceptance as a language for open source web projects, which lead to the likes of phpBB and Wordpress which in turn lead to PHP gaining even more presence on the web.

I think the staying power of php is at least in part due to the continued success of popular projects that rely on it, whoever was responsible for its initial successes.

As someone who worked in the hosting industry before moving to supporting and consulting on cloud stuff, it's a couple of things.

A handful of projects really are the driving reason for PHP's ubiquity.

Wordpress/Joomla, phpBB/Invision/vBulletin, Magento...

The demand for support for these and some smaller and similar projects really drove webhosts to need to support PHP, and for a lot of the standardized tooling webhosts used, such as cPanel/WHM and Plesk, to support not only PHP, but the automated installation of these projects.

Sure, WordPress wasn't the first - phpNuke, Postnuke, etc, were really popular CMS tools before WP, but if we're talking staying power, you really can look at the stuff I listed as being why it has stuck around.

I could be wrong but my recollection was that PHP initially became the only way to do dynamic pages on shared hosts since it had "safe_mode". At least at my first host, if you wanted to use cgi-bin, you had to submit it to their admin who would read the code and vet it for safety before installing it. While safe_mode probably didn't actually solve that many problems it was a good enough excuse that it meant that admins could allow arbitrary PHP without too much worry.

Similar for self hosted shopping carts. Magento, PrestaShop, OpenCart, etc. There are very few complete shopping cart platforms that aren't PHP.

It wasn't right, no. I remember going "WTF" repeatedly even back in 2000, while first learning it and then using it in a commercial project.

It's mostly that everything else was either worse (ASP), or insanely overengineered (JSP), or both (ColdFusion).

Also, with LAMP, you had a stack that was free top-to-bottom. Back then, it still wasn't as common as it is in the industry today, and that especially helped it in the hobbyist and small business niche.

PHP also didn't make the mistake Perl did. A shame because Perl tried very hard to make the right thing easy with security.

make the right thing easy with security.

All other things being equal, security is usability[1] anti-pattern. You don't get to make clever hacks (in the original sense) on a secure system.

Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. - Doug Gwyn

[1] at the very least for a power user or a developer

PHP was not really designed, though. It grew accidentally from a templating system. When other systems are said to be more secure, I think it's meant in the sense of not being horrifically broken and routinely injecting untrusted input into namespaces, markup and SQL queries.

Just like C grew accidentenly from a language created to bootstrap compilers and JavaScript was a hacky 10 day solution.

Wikipedia quotes[1] Rasmus Lerdorf as saying: "I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way."

Another relevant quote: "I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say 'Yeah it works but you're leaking memory everywhere. Perhaps we should fix that.' I’ll just restart Apache every 10 requests."

And: "For all the folks getting excited about my quotes. Here is another - Yes, I am a terrible coder, but I am probably still better than you :) "

...which is probably true, but all the more reason to use tools that work properly rather than encouraging me to build more poorly thought-out stuff on top of a broken hack.

[1] https://en.wikipedia.org/wiki/PHP#cite_ref-itconversations_1...

[2] https://en.wikiquote.org/wiki/Rasmus_Lerdorf

Perl's decline relative to PHP is a bit more nuanced. With mod_perl you had to be really careful with global variables otherwise another process could access them in memory. Mod_php did a better job of isolating processes so mod_perl gained a reputation as a security headache which most cheap hosting companies were not prepared to deal with. It's often overlooked that a lot of cheap hosts only offer PHP as a CGI so the benefits over Perl/CGI appear, at first glance, to be minimal but even as a CGI PHP has templating built-in where Perl, Python and Ruby don't. Perl only has CGI.pm when limited to CGI. Sure, you can try to run Perl web frameworks such a Mojolicious, Dancer and Catalyst under CGI but they're not going to compete with PHP since they don't run as drop-in templated pages. Perl did have a PHP clone - HTML::Mason - but it wasn't worth using unless you ran it with mod_perl. That's where Perl lost to PHP.

When PHP gained full OOP support with PHP5 the Perl community was still tearing itself apart over introducing a MOP and which of the dozen Moose clones should reign supreme. That was the final nail in Perl's coffin, at least in it's bid to compete with PHP.

What's that mistake?

Perl 6. You think Python 3 was bad?

Have you looked at Perl 6 recently?

The issue isn't the language which is great. The issue is with the development hell sapping resources from the community

I think it's a given that Perl6 will not achieve the prevalence that Perl5 has.

It's pretty much a given that no language will ever be able to achieve that again.

Ah, of course. But IIRC Perl usage on the web already started to decline (mainly in favor of PHP) before the whole Perl 6 debacle.

I think PHP's strength was also its weakness: an amalgamation of specialized functions thrown into a global namespace without having to bother with modules, CPAN or anything.

If you're an experienced dev it looks like a huge mess but if you're a complete beginner it makes it easier to work with.

I once wrote a post comparing PHP to the Zerg in StarCraft. It's ugly as hell yet manages to spread everywhere. Purity of Essence trumps Purity of Form. PHP let you defeat competitors wielding superior technology through rapid time to market. A zergling rush, if you will.

Another thing PHP had was good reference documentation with a comments section for every function.

Systems that are difficult to reason about are difficult to replace.

> URLs aren't uniformly routable from either end

What do you mean?

Having a single, uniform router (function/class/whatever) is only valid for trivial software. Any non-trivial system is better off with multiple independent URL routers with different semantics.

And yet lots of non-trivial systems have a single uniform router and are just fine with that. So there's that.

Reply on news.ycombinator.com