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.
> 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.
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.
Same problem. Hearing so good in quieter environments that it seems impossible to some people, and totally unable to make out a single word in a typical bar or club or party etc.
I’ve always thought it had something to do with undiagnosed ADD, or maybe more likely some autism spectrum disorder (though I never understood why medical professionals felt the need to label something that feels to me mostly like a few commonly coexisting personality traits and is not a source of any medical adversity for me a “treatable disorder”, so I’ve always rejected this).
I also have problems with alarms and sirens. I’ve walked down many miles of city blocks in my life, and I’m the only person I’ve ever seen who has to put down everything they’re holding and cover their ears with both hands any time an emergency vehicles drives by. That makes me enough of an outlier that I think there’s probably something medical to this, I don’t know what though.
Huh, the bit about emergency vehicle sirens is weird - because I'm exactly the same. If an emergency vehicle is driving past I have to cover my ears or otherwise it's just...painful? I've never seen anyone else do this.
Interesting! I’ve never seen anyone else do it either.
It’s similar to pain but it’s more like a sensory input at a level of intensity that is so overwhelming that it feels like it is or could cause permanent physical harm to whatever in my ear is receiving that input.
I guess I just described pain, but it feels a little different because the sensory input itself is the source of it, it’s not a side effect of anything else that’s happening, and it doesn’t really feel similar to any other kind of pain.
Fire alarms do this to me too. I lived in a building with false alarms every few weeks. I would like to have ignored them and continued working, but it is just impossible. I have to cover my ears and wait for the pauses between sounds to even do anything with my hands, like unplug a laptop or open a door.
I've never told anyone this, but Bill's next bit in that clip about customer service, I actually did that last year.
I had this big mess with my whole flight itinerary, and I was stuck at an airport for like 30 hours with nothing to do.
I got the airline's customer service on the phone. They were refusing to compensate me, I was livid but I just did exactly what Bill said: Don't curse and they can't hang up.
I talked really, really slowly. The intercoms in the airport would sound off periodically and I'd just wait until they stopped then ask the rep to repeat himself. So he'd repeat a point that he already made like 15 times. And I'd just keep feigning that I misunderstood the point he was trying to make.
I just kept talking in an infinite circle about common law, and the implied covenant of good faith and fair dealing, and running through all these increasingly ridiculous hypothetical scenarios of overbooking and flight delays and which party should be liable in those scenarios and for what reason, and on and on...
Bill is right about them not being allowed to hang up. I had him on the phone for over an hour.
He kept it together for a while, but toward the end I could tell that he was starting to crack. Then he made some unprompted comment about how he didn't care because he was getting paid to deal with me, and shortly after that, the line just abruptly cut off mid-sentence.
I got a callback the next morning offering me a $200 airline certificate, a hotel voucher, and a meal voucher.
True story.
At the time I was just really angry about my travel getting screwed up, and especially about not having a place to sleep, and being stuck in an airport terminal. And all that anger just channeled into this game of calmly wasting that guy's time.
But in hindsight, what I did was a very unjustified and shitty thing to do, and I was rewarded handsomely for it. And that guy may have been reprimanded through no fault of his own. I don't feel great about it and won't be doing it again.
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.