| I see a lot of comments defending PHP with arguments about how fast it is. They may be right about the PHP7 implementation generally executing faster than most popular Python or Ruby implementations, but they're really missing the point when we're talking about languages and language design, which is what these conversations are really about. Languages aren't fast or slow, implementations are fast or slow (and all to varying degrees in various contexts). Implementations are also limited in how much they can impact speed, because the speed of execution is primarily a function of the code, how it's written, and sometimes input size (not how it's executed). In other words, speed improvements derived from implementation optimizations are generally constant-time improvements, not improvements that scale with code complexity or input size. That means speed of implementation is mostly a concern of certain specific domains where milliseconds really matter. A few of them are HFT, computer graphics, UI rendering, systems programming, etc. Outside of that, code and system design optimizations will be far more fruitful than implementation optimizations. PHP's design is so intertwined with the HTTP request-response lifecycle that it has been (pretty much) completely and permanently relegated to a very narrowly defined set of use cases, mostly template rendering (or more organized code in the same vein as template rendering, WP, most Laravel projects, etc) and HTTP APIs. Nearly all PHP use cases involve network latency for every user interaction that makes it past caching layers (to where it's actually executed by the PHP7 interpreter). Allowing network latency to impact user experience for every user interaction (which is practically the only thing PHP knows how to do) isn't acceptable anymore in 2019, and the solution is client-side rendering (JS/V8/webkit/blink/etc). PHP cannot (could not) solve that, because no matter how much you optimize it, it will still take 500ms of network latency to reach the user's browser. So there's really no use case or domain where PHP is the correct choice if speed of execution is a primary concern, and that would continue to be true even if you made PHP's interpreter run as fast or even faster than V8. The language's design is inherently incompatible with use cases that care about speed, because of how deeply in bed it is with HTTP request-response lifecycle. What this leaves us with is a language that is only functional in environments and use cases where implementation speed does not matter. PHP's marriage to HTTP request-response lifecycle has also had the effect of enabling bad coding practices at the interpreter level, because when no process lives longer than a few seconds, a lot of things that should matter just stop mattering. This is why very few people have ever tried to use PHP outside the context of HTTP, and those who have returned with the worst kinds of horror stories. What that leaves us with is a language that can't even reasonably be called a general-purpose programming language. And through all the efforts to save PHP from these problems, what are we trying to save? The most inconsistent, cluttered, disorganized and ugly syntax and standard library of any prevalent modern language. I understand that a lot of people have to work with PHP, that good communities can form and be sustained around that, and that some people can even like it. But if there's going to be any semblance of objectivity in any conversation about language design, it has to be agreed that PHP is a terrible language. A language that served a great purpose and arguably accelerated the success of the web to a historical degree, but not a language that still needs to be here in 10 years. |
Maybe I'm misunderstanding you, but it sounds like you're saying that speed doesn't matter when responding to HTTP requests. This couldn't be further from the truth. The less time a response takes, the more requests can be handled per second, which is critical for scaling Web services. PHP 7.x handles 2-3 times as many requests per second on the same hardware compared to PHP 5.
Also, I don't agree that PHP is only suitable for responding to network requests. I've also found it ideal for writing CLI programs which can run on a schedule and share logic with HTTP APIs.