It's the shitty PHP projects they don't tell you about in the interview that people have a problem with that they then shovel on your plate.
But that really goes for any language.
The true extent of technical debt is almost never realized in an interview, but you can't really do much about it if you accept the job and they tell you to work on it.
It goes so much more for php than any other language. PHP used to be so popular and even now with JS and other languages on top, there's still so many legacy php apps out there for maintenance. I deal with them regularly and most of them are really bad.
And no, I'm not shitting on the language. It's a decent language nowadays.
You know many people who are enough into CS to go through "The Art of Computer Programming" multiple times but yet use PHP a lot? Modern PHP is OK but I doubt it's a good default choice at present given all the alternatives.
If a company already has a large PHP codebase, then it's probably the right choice to stick with it. And it can scale just fine, easily as well as Python or Ruby if you dig into how to do it right.
But to manage scalable PHP (or any language, for that matter) you still need smart programmers, a lot of whom will have been through most of the serious academic works in the field. They won't love working with PHP (I never did), and it might mean greater flight risk (yup!), but they might join the job anyways (at least half a dozen people that I know with those creds that joined up with the last project I was on where we had no choice but to deal with PHP) because of other reasons, like liking the company, people, or goals.
I've worked with a dozen different languages over the last 20 years. PHP is not one that I'd pick for a new project, but TBH, it's not the worst I've had to deal with. My experiences with the Visual Basic, Perl, and R code that I've had to interact with were actually far worse (typically because the people that code them are not as solid in software engineering), but I wouldn't judge people that use them just based on having done so. Unless we're spinning up new prototypes, very few of us actually get to choose the technologies that we use.
I've learned to avoid vb.net shops not because of the language per se, but because of the culture that allows for sticking with something that has widely considered legacy for some time now.
I know this is painting with a broad brush, and I'm working from a sample size of 2 (or, 2 vb.net shops that I've worked with), and the software engineering culture as a whole was really bad on those teams.
>>> And it can scale just fine, easily as well as Python or Ruby if you dig into how to do it right.
The webserver is scaled by just adding more instances in parallel with a load balancer. It's the database that needs to scale and that's the challenge.
Absolutely, though I'd warn that if you naively use PHP and a default setup (Apache with default settings for PHP or something like that), you're probably not going to serve as much traffic per server as a naive Python or Ruby setup will get you. You have to tune your way there, and it can be a bit of a process, but it's definitely possible, and there's nothing very subtle about it.
One of the biggest problems with PHP, IMO, is that most of the code you'll find online is extremely old, and probably will give you terrible advice, using old deprecated mysql libraries, etc.
And don't you have to reopen database connections for each php request? Even that seems fairly difficult to scale, unless there's a way around it that I'm not aware of (I don't use php very often, definitely not at scale).
PHP is very much like Java, only being dynamically interpreted.
Symfony is a very high quality framework, with which can build serious applications.
Python is surely nice looking, but as it allows redefinition of everything at runtime, it is impossible to optimize at compile time. I think PHP, with the recent type strictness functionality, is better positioned for making way to new developments like meaningfull code analysis, (compile time) optimizations and performant JIT compilers.
Python is too dynamic for that, unfortunately. The same holds for JavaScript.
I don't know Ruby well, but I know it is also slow.
The biggest problem with PHP is that it standards library has inconsistent naming. The syntax is very much Java-like.
If PHP would shove the standard library into `LegacyPrelude` (and have it automatically loaded like Haskell) it could improve on that as well. This problem is not as fundamental as the other problems in my opinion, although still requiring a major effort to slowly turn to a new `Prelude`.
The biggest problem with PHP is that a lot of smart people don't want to work with it for whatever reason, and you really want these smart people. To succeed you have to have a good team. Difficult to assemble one with PHP as your language.
If you use PHP you are going to lose. The world has moved on. Remember that you are not the only game in town. Good engineers have opportunities in Python, Javascript, Ruby, Rust, Golang, whatever. These languages have better reputation, better communities, they are more exciting. PHP might have become better but it's too late. It wasn't late for Javascript, but it is late for PHP.
