[apeace]

So the entire argument is that PHP is single threaded and each request starts with no state? Am I missing anything else?

I’m trying so hard not to rant here, so I just wanted to confirm that those are the only positives he outlines about the language.

[coldtea]

>I’m trying so hard not to rant here

Not that hard, there's a bias showing.

First, those things you've mentioned are nothing to sneer at, are actual very good decisions (even if accidental) for a webserver-centric language.

They enable even naive developers to achive good scalability and isolation, and make fast development/debug cycles trivial.

Second, PHP has been improved by leaps and bounds from the days of 4, to the point of being a totally different language - all of the above points are already made in TFA.

Most arguments against it are moot today, or only apply superficially to the standard library, not the language (order of arguments, and so on).

Plus, it is speedy too, post 6, and especially post 7 (and there's a whole new JIT in 8). In any case, it has constant work on speed and memory reduction.

And of course it has a huge ecosystem of libs, projects, and frameworks, including not available anywhere else projects like Wordpress.

And the standard library (warts included) between JSON, DB drivers, LDAP support, SMTP, etc., is one of the most complete ones this side of Python, and perhaps even fitter than Python's for typical web development work.

Plus the deployment model is one of the best. Copy your files to a directory. Done. Add a redirect instruction to your server if you want to make it more fancy...

For third party libs, composer is up there with any major package dependency/install solution.

And for the core libs, plugins, etc installation is handled perfectly by the standard package managers in all Linux distros (and probably Windows too), and is even easier with MAMP, WAMP, etc for local development. Trivial to dockerize too if that's your thing.

[throw_m239339]

> PHP has been improved by leaps and bounds from the days of 4, to the point of being a totally different language.

No, most of bad parts are still here, all the stdlib inconsistancies and co are still here. Just because add more functions to a language doesn't change the bad design decisions at its core. The weird mix between dynamic typing and Java style rigidity (without most of its benefits) didn't go away.

What makes it a different language since PHP 5? more type guards? no, it's still a templating language.

[munk-a]

Those strange naming choices definitely still have a cost but a lot of effort has been invested in documentation and alternatives to lessen their cost.

The mixed typing is... honestly, it's amazing. You really need to try it out for yourself in PHP7 or 8 - you can lean on really strict type checking in your application, go the old route or generally adhere to strict typing and relax that for entry points and library calls.

Lastly, PHP has come down hard and actually introduced backwards compatibility in a few key places to address some of the biggest WATs, I've been pretty impressed by the balance of the language stewardship.

It does definitely have warts, but there are warts on everything that people actually use in industry.

[recursivedoubts]

FTA: "I claim that PHP’s simpler “think; edit; reload the page” cycle makes developers more productive.

I agree wholeheartedly with this. I prefer statically-typed languages w/ a bit of local inference (I end up in java usually, but C# got it right) and I consistently see people in my world underestimate the edit/reload workflow. Even a small compilation step is enough to break flow and make development a chore, once you've worked that way.

As a side note: java not allowing signature changes and requiring a whole server restart is absolutely awful. It didn't have to be this way: the DCEVM[1] was presented at the 2009 JVM Language Summit[2], by Thomas Wuerthinger. He patiently demonstrated and explained how his work allowed for hot swap of arbitrary class changes, while the Sun guys sitting in the audience told him that what he was demonstrating was impossible. We ended up using the DCEVM for a long time, but as of right now I'm back to restarting my server when I make breaking changes. It's a funny world.

¯\_(ツ)_/¯

[1] - This is a modern fork of the project: https://dcevm.github.io/

[2] - http://wiki.jvmlangsummit.com/Hotswap

[apeace]

It’s hard for me to relate, because I just don’t see “edit; reload” as being that important.

I think the difference is I write tests. I usually code everything while writing/running tests. Then it always works the first time I run it, so there’s no need for “edit; reload”.

[munk-a]

I really like working in PHP but I'd actually agree that edit;reload is a virtue of the language (in the environment everyone normally assumes it's running in) that is losing value.

This virtue was incredibly valuable to me when I was throwing a website together with ducttape and bubble gum and it was the only way (that I knew of) to be able to clearly and quickly see the results of my changes. With tests in the picture I think it loses a lot of that value - it still has some since nobody likes writing front-end tests but most of your code changes should be "proven" by some level of automated test coverage.

[recursivedoubts]

Oh, you were asking about benefits that you can easily relate to.

Well, in that case then you'd be in a much better position to answer than I am.

[pavel_lishin]

> I think the difference is I write tests. I usually code everything while writing/running tests. Then it always works the first time I run it, so there’s no need for “edit; reload”.

I write tests, too. I guess I'm not as good of a software developer - because just as my code has bugs and unexpected edge cases, so do my tests, and they don't catch every mistake I made, since I'm the one making them.

[zug_zug]

IMO it's such a good thing about PHP that I think other stacks should follow that model (I assume ROR does).

I think it's a superior model to the long-running application. Unless your company has 0 developers in it who make a memory leak, or make a fatal uncaught exception.

[fuzzy2]

Hm. This is this and that is that. It is perfectly possible to write a stateless service hosted in a stateful process.

In fact, the popular PHP-FPM way to host PHP does just that.

If you want to take it to the extreme, there's always CGI, of course.

[pentium166]

Ruby on Rails lives inside a long-running application server. In development, it has dynamic class loading and will reload on file changes, but in production an app can have a lengthy startup time. It does have the memory problem, but I have never seen the server crash outright as a result of an exception while handling a request.

[glaucon]

You might have missed this bit - "Did Facebook, Wikipedia, WordPress, Etsy, Baidu, Box, and more recently Slack all succeed in spite of using PHP?"

[IshKebab]

They didn't provide any real arguments that the answer is anything other than "yes".

Plenty of languages have support for hot reloading, which means you can just edit, save, refresh exactly the same as in PHP, with the added benefit of not having to use PHP.