3 ms·

"I've really squeezed everything out of this shitty little language" Whenever PHP is mentioned people always jump to talking about the limits of the language a

"I've really squeezed everything out of this shitty little language" Whenever PHP is mentioned people always jump to talking about the limits of the language and I'm curious what those limits were? I've worked on big and small code bases, large scale and small, and everything in between and haven't hit anything I'd call a "limit of the language" that we didn't just go right past without missing a beat. I do agree there are much better options out there now but based on a very different criteria which is why I'm doing what I can to learn many of them and move on from PHP.

opendais 12y ago
Tbh, the only true limits I see in PHP are performance related. [e.g. I can write in Golang something that outperforms straight PHP+Accelerator or HHVM by a mile] That and it was really designed as a fire-and-forget language so longer running processes have issues.
mantrax5 12y ago
The reasons I can list are thousands. But to understand them it's really a matter of mindset. I can talk about long-running processes, threads, weak references, actor systems and so on, but most PHP developers would just phase out completely if I do this without sufficient background. At most they'll say something like "shared nothing!", like a tick, almost. Because to PHP developers absolutely any problem fits into "state in MySQL and logic in PHP". Even with Memcache, or now with NoSQL stores like Redis, the mindset remains the same, just the API is different. Someone once said "You can't connect the dots looking forward you can only connect them looking backwards." To realize why PHP is shitty, you have to first get familiar with the larger landscape. Because if you don't, you'll believe every problem is fit for the golden hammer of MySQL+PHP until the end of your days, even if there are vastly superior solutions out there.
- bowlofpetunias 12y ago
  So, you're talking about design choices for which PHP (amongst many other languages) is the wrong tool, and your complaint is that... PHP is the wrong tool. Therefor, PHP is shitty. Yes, I'm not surprised people phase out when you start talking.
  - mantrax5 12y ago
    You see, turns out the design choices for which PHP is the wrong tool start to very seriously overlap the design choices that are best for most projects written in PHP these days. But you can only know this if you are even aware of these design choices, and their benefits. PHP's architecture isn't the best paradigm for web development & "web scale" despite years of brainwashing in the PHP community. It's not the best by far. So we have countless PHP apps shoved into the PHP paradigm for no better reason except that this is what PHP offers. I've seen this happen a few times before with various technologies and I recognize the signs. Despite PHP supporters talk about PHP's bright future, the fact it's seriously starting to resemble a bad Java clone is only further moving us to the point people will start abandoning PHP in droves. An example from the recent past which PHP devs might be familiar with is Flash. Flash's future was extremely bright mere year before it imploded very suddenly and "unexpectedly" to the uninitiated. The signs were there for years prior to that.
- debaserab2 12y ago
  Yes, if you're writing a multithreaded memory sensitive application (or really just any application in general that has performance as a primary objective) then PHP is not the right tool for the job. It's not a golden hammer, it's just that most websites at their core are simple CRUD apps that initially don't need more than what PHP offers. When you do need to scale your PHP app to tackle these problems, there's no reason why you should limit your stack to PHP. It's OK to not like PHP because it's not a beautiful language but I don't buy the argument that it's never useful.
- opendais 12y ago
  The problem is your logic is circular and you make generalized claims about how 'most PHP devs' do X. No one here is saying PHP is a "golden hammer" to solve all problems. PHP is a tool for a specific problem domain and it solves problems within that domain effectively with certain cost/benefit characteristics. > long-running processes No one here suggested you should be writing PHP daemons. > threads Hint: That is what PHP-FPM is for. > actor systems Actors are also generally long running processes. etc. > Because to PHP developers absolutely any problem fits into "state in MySQL and logic in PHP". Even with Memcache, or now with NoSQL stores like Redis, the mindset remains the same, just the API is different. Every single CRUD application fits into this particular problem domain. Many PHP developers happen to work on CRUD applications, therefore many PHP developers first attempt to solve a problem in this way. I've seen a large, well known IT company basically admit they did this [none of them were PHP devs] when they should have been using a very different architecture. This is not a PHP problem, this is a mindset problem independent of the language used.
  - icehawk219 12y ago
    > No one here suggested you should be writing PHP daemons. I agree with everything you've said and this statement isn't false in the scope of this thread. But I can't count how many times fellow PHP developers have suggested using PHP to write daemons and scripts that would be running on servers for weeks or months (or presumably even years) without restart or how much push back I received when I suggested using something better suited for it. But to your point none were proficient in other languages so it's only natural they'd try to figure out how to do it in the one they knew best.

opendais 12y ago

Tbh, the only true limits I see in PHP are performance related. [e.g. I can write in Golang something that outperforms straight PHP+Accelerator or HHVM by a mile] That and it was really designed as a fire-and-forget language so longer running processes have issues.

mantrax5 12y ago

The reasons I can list are thousands. But to understand them it's really a matter of mindset. I can talk about long-running processes, threads, weak references, actor systems and so on, but most PHP developers would just phase out completely if I do this without sufficient background. At most they'll say something like "shared nothing!", like a tick, almost. Because to PHP developers absolutely any problem fits into "state in MySQL and logic in PHP". Even with Memcache, or now with NoSQL stores like Redis, the mindset remains the same, just the API is different. Someone once said "You can't connect the dots looking forward you can only connect them looking backwards." To realize why PHP is shitty, you have to first get familiar with the larger landscape. Because if you don't, you'll believe every problem is fit for the golden hammer of MySQL+PHP until the end of your days, even if there are vastly superior solutions out there.

bowlofpetunias 12y ago
So, you're talking about design choices for which PHP (amongst many other languages) is the wrong tool, and your complaint is that... PHP is the wrong tool. Therefor, PHP is shitty. Yes, I'm not surprised people phase out when you start talking.
- mantrax5 12y ago
  You see, turns out the design choices for which PHP is the wrong tool start to very seriously overlap the design choices that are best for most projects written in PHP these days. But you can only know this if you are even aware of these design choices, and their benefits. PHP's architecture isn't the best paradigm for web development & "web scale" despite years of brainwashing in the PHP community. It's not the best by far. So we have countless PHP apps shoved into the PHP paradigm for no better reason except that this is what PHP offers. I've seen this happen a few times before with various technologies and I recognize the signs. Despite PHP supporters talk about PHP's bright future, the fact it's seriously starting to resemble a bad Java clone is only further moving us to the point people will start abandoning PHP in droves. An example from the recent past which PHP devs might be familiar with is Flash. Flash's future was extremely bright mere year before it imploded very suddenly and "unexpectedly" to the uninitiated. The signs were there for years prior to that.
debaserab2 12y ago
Yes, if you're writing a multithreaded memory sensitive application (or really just any application in general that has performance as a primary objective) then PHP is not the right tool for the job. It's not a golden hammer, it's just that most websites at their core are simple CRUD apps that initially don't need more than what PHP offers. When you do need to scale your PHP app to tackle these problems, there's no reason why you should limit your stack to PHP. It's OK to not like PHP because it's not a beautiful language but I don't buy the argument that it's never useful.
opendais 12y ago
The problem is your logic is circular and you make generalized claims about how 'most PHP devs' do X. No one here is saying PHP is a "golden hammer" to solve all problems. PHP is a tool for a specific problem domain and it solves problems within that domain effectively with certain cost/benefit characteristics. > long-running processes No one here suggested you should be writing PHP daemons. > threads Hint: That is what PHP-FPM is for. > actor systems Actors are also generally long running processes. etc. > Because to PHP developers absolutely any problem fits into "state in MySQL and logic in PHP". Even with Memcache, or now with NoSQL stores like Redis, the mindset remains the same, just the API is different. Every single CRUD application fits into this particular problem domain. Many PHP developers happen to work on CRUD applications, therefore many PHP developers first attempt to solve a problem in this way. I've seen a large, well known IT company basically admit they did this [none of them were PHP devs] when they should have been using a very different architecture. This is not a PHP problem, this is a mindset problem independent of the language used.
- icehawk219 12y ago
  > No one here suggested you should be writing PHP daemons. I agree with everything you've said and this statement isn't false in the scope of this thread. But I can't count how many times fellow PHP developers have suggested using PHP to write daemons and scripts that would be running on servers for weeks or months (or presumably even years) without restart or how much push back I received when I suggested using something better suited for it. But to your point none were proficient in other languages so it's only natural they'd try to figure out how to do it in the one they knew best.