Sorry guys,PHP is the outdated! (From someone who start PHP in 2000 with PHP 2.0 and is still reading lastest Laravel code source).
To young people: choose your language wisely, you don't need to know PHP to be successful in Web dev
The top open-source ecommerce platforms (magento, woocommerce, etc) and content management systems (wordpress) are all in PHP, and yes they were written before 2000. You don't need to know PHP to be a successful web dev if you are working at a silicon valley tech / social media company, but e-com and content management are still what most companies are trying to do on the internet, and if you are interested in a tech career outside of silicon valley, being handy with PHP is great.
That's certainly true, but we're living in a funny time, everything has evolved so quickly that there are 15yr old PHP apps rubbing shoulders with 7yr old Rails apps next to 4yr old Node apps and now React etc. Some of that represents actual progress, some fashion, but for all those legacy apps, someone has to keep the lights on (until the plug gets pulled). That said, I don't really miss PHP too much, it was much nicer than Perl for adding a little magic to html, but building anything big was not fun (I gather Laravel makes that better these days, but there are a lot of other choices if you're starting fresh).
That doesn't add up. There was no "PHP 2.0"; the language was still referred to as PHP/FI at that point. And PHP 3 was released in 1998 -- by 2000, I have a hard time believing you would have still been using PHP/FI, which was a much more limited tool.
Those all seem like features any modern programming language has. Nothing here particularly distinguishes PHP from the rest of the crowd. I don't think anyone is surprised by the fact that PHP has classes and some niche methods integrated in most standard libraries.
I would like to go one further and say most other more modern programming languages do each of these better. It's always a good idea to look what is beyond the horizon.
Exactly. I’d argue what makes modern PHP less awful is almost entirely in what it lacks. Checking a bunch of random OOP boxes is not going to make it a good language. People love plenty of programming languages that don’t check those boxes. (Lua, C, Go are all languages that lack many of those OOP features, for example.)
And to be sure, modern PHP is better. The beginnings of typing, the fixing of horrible standard library behaviors, and an ecosystem with package management are game changers. But to me, all of that means nothing if the ecosystem is primarily running legacy apps. There are clearly proponents of modern PHP that embrace the new PHP, but what really gives it any modern relevance is old school apps like Mediawiki, phpBB, etc. and I feel like they all underscore what I dislike about PHP: not a single problem but a mindset that is incompatible with modern internet. There is no assumption of shared nothing; most apps assume the disk can be used for persistence. And it’s tricky to dockerize a PHP app effectively since you typically need multiple processes; I know there’s work on an app server in PHP itself but last I checked it was for development, and rather I ended up using uWSGIs embedded PHP support as the only solution I could even find that could do this in a way that wasn’t horrifically ugly or intensive.
It still has its issues. For me the prime issue with PHP is the execution model. I am not in for my document root being my source dir. This weird behavior comes from the CGI era and to this day it doesn’t really feel like there is intent to move away from it. Rather, the age old front controller pattern is poised as a “solution,” entangling web server, PHP and application configuration together in some unholy mess, versus the modern pattern of having an app server.
> And it’s tricky to dockerize a PHP app effectively since you typically need multiple processes;
Absolutely. I handle a lot of the devops work at my job and PHP containers are just all around more annoying to build, configure and run than most other languages. Even on modern frameworks like Laravel still have a lot of default assumptions of being hosted on a server all by themselves.
It's weird how a language that gained so much traction for being the easy language to host has become one of the harder ones to deploy in the modern era.
People who hate PHP-- or even worse, hate other people for writing PHP-- generally don't have anything of value to add to the criticisms of PHP. They just dismiss the language entirely, link to 2012-era blog posts about its imperfections, and never bother to see if anything was fixed in PHP 7 (or, as of the end of this year, PHP 8).
This kind of toxic mentality doesn't produce better code, and it sure doesn't produce better coders. It's just free-floating hostility and gatekeeping.
Here's a few parts of PHP that improved in the past 6 years:
* Static type declarations (and return types, and strict typing, ...)
* Composer has become the de facto package manager for the PHP ecosystem
* Better cryptography (bye mcrypt, hello sodium)
* High quality open source libraries (i.e. Guzzle)
And I haven't even reviewed all of the changes coming in 8.0.
I think it's fair to say that PHP was okay, historically, but with hindsight, I wish I would have moved on sooner.
I made a lot of money on PHP code. But then realized there were other languages that I could also make money on, that worked better for what I needed. But would I go back? No..
I've no doubt that there are people taking programming opinions way to far and it sucks that PHP devs have to deal with that.
OTOH, there are now mainstream languages with null in the type system, union types, pattern matching, etc... it looks (from the outside) like PHP caught up to where the industry was 10 years ago. If I'm uninformed I'd love to see a comparison to Typescript, Kotlin, Swift, or Scala3.
The part on database access is not a plus for php. Writing sql like that is horrible, especially when it's simple. I'm in a huge refactor right now, where i'm utilizing postgres schemas and doing it with php, like in the article would be absolutely horrible.
After reading the PDO section, I started to wonder if the author has used a language other than PHP. How can PHP have the best database integration if the best example you can show are simple prepared statements?
When I last worked with PHP, I used PDO because it mostly worked like Perl DBI. I agree that it beat using the old mysql interface in SQL-injection mode, but it was by no means a revelation. The Perl DBI has been around since the 1990s: O'Reilly's Programming the Perl DBI came out in 2000.
"Best" is subjective, though, isn't it? What do you regard as being better? Personally I hate frameworks like Zend which abstract database operations into multi-parameter functions. It serves very little purpose when you can just write actual SQL, in my opinion.
I'm sure that a lot of other people have great experiences with other database interfaces such as C#'s Linq or Ruby's ActiveRecord, but that really isn't the point of my comment. The PHP snippet in the article is pretty much the bare minimum for SQL integration in other languages. As another reply to my comment points out, the PHP snippet posted is nearly identical to Perl's DBI (which I believe PDO is based on), which came out 1995!
For an article that purports "PHP is good now", I wouldn't expect one of the selling points to be something that could be done in (and is routinely done), in Python/Perl/Ruby for over 25 years now.
Using PHP sounds like a perfectly sensible choice, given your circumstances. Your argument falls short of convincing that PHP is the best tool for _everyone_, though.
1. I'm not aware of any non-trivial feature in Laravel that isn't matched by e.g. Rails, Django, Elixir, or indeed any sufficiently modern web framework.
2. This speaks more to where your comfort zone resides than any intrinsic merit of the language/ecosystem.
To be clear: there's nothing wrong with your using PHP. I'm just left wondering what your initial point was... that PHP is your favorite language?
I'll grant both of those points, with the caveat that I wasn't trying to say that PHP is the best choice for anyone to solve my project's problem set, but rather the best choice for me.
I'm also wondering about the initial point, but ...
Is there ever a best tool for _everyone_?
I have only ever been convinced that something is the best tool for a job, when taking into a account a lot of context, exact requirements, available resources, etc. Otherwise you are almost always left with quite a large number of options that are equal for the information available and you can basically choose from by rolling dice.
Regarding 2) I think it goes beyond comfort zone. I have seen plenty of completely chaotic, unmaintainable code bases due to the initial developer(s) starting the project without any prior experience of the technology. Of course many paths lead to chaos, but I would wary to start anything time critical in something too different to what I'm already quite comfortable in
Laravel benefits substantially, IMO, from a "benevolent dictatorship" contributor model that targets "is this easy to work with" over pretty much anything else. Taylor Otwell can be a controversial figure in the PHP world at times, but the results are difficult to argue with.
But wasn't this precisely the case with Python? Guido was also its Benevolent Dictator for Life, and Python also placed high value on ease of use, and that there should be only one obvious way of doing something (without being dogmatic).
Did Python stray from this? Occasionally yes. Did PHP with Laravel? I'm going to guess also yes.
Laravel has had features before Rails ActiveQueue(?) for eg was adopted in Rails core a few years after Laravel had a stable Queuing system. Rails delegated to Sideqik for long and that caused issues for the ecosystem.
One advantage of PHP over Node or Java is that it is stateless, so no worrying about memory leaks. And most disadvantages of this disappear when scaling out.
"Stateless" here meaning that a given process only lives as long as it takes to receive and respond to a single request, as in the classic CGI model (where PHP originated), or like how an AWS Lambda works.
In practice it mainly means that, in exchange for process startup overhead added to your response times, you get to get away with being sloppy about how you initialize and dispose of resources. It's not something I have ever really regarded as a virtue, and it's one reason why PHP devs can have real trouble transitioning to platforms where the same assumption no longer holds.
Which modern framework? The most common alternative: python. A 30 year old language with two completely different syntactical versions 2 & 3. Packed with all the great shit fest, eg: urllib, urllib2, urllib3.
Python isn't a framework, but in contrast to Pythom, PHP made some bad decisions that are hard to roll back, the biggest being cramming hundreds of inconsistently named standard library functions into the default namespace. PHP can be very productive but I think it's fair to day it was designed a lot less intentionally than many languages.
PHP is very guilty of cramming hundreds of inconsistently named standard library functions into the default namespace, but I wasn't aware of Python doing this?
Sure, Django/Python is a plenty good example. Python manages to be older than most of its competitors while still feeling like its cutting edge. Django is hard to beat in all but speed. What about newer stuff like Elixir/Phoenix, or even Node/Express or Ruby/Rails.
That said, I'm not even saying PHP is bad, but this article doesn't convince me why I'd pick PHP over literally anything else.
Isn't it just not that popular an option anymore to start new projects with? Most people are aware of the language having changed a lot since its heydays.
And honestly, from the article I'm not quite sure why I should consider using PHP. Sure, it has a lot of modern bells and whistles now that it didn't when I last used it 2005-ish, but what makes it stand out? I know a number of people that are super happy and productive with modern PHP, but those are all people that have been using it continuously since forever so it makes a lot of sense for them. But why switch to it from another stack?
E.g. the supposed best database integration of any language with "PHP Database Objects". At least the examples given are the absolute bare minimum I'd expect to get from such an integration. What makes it the best?
The more experience I get, the more I think that most languages are just fine. Coding is increasingly the easiest part of my job. I’d work in PHP if needed. But I’m still not touching MUMPS.
> The more experience I get, the more I think that most languages are just fine.
Quite. Just give me a boring language with a stable ecosystem, mature and extensive tooling and fully understood quirks. That means all the time and effort can be spent building the actual product instead of burning time monkeying around with the shiny-new language.
This means that things like Java and PHP (and C in some domains) are nearly universally the correct answer if your goal is to build a product instead of building a resume.
Source: consulted at two companies that survived dot com crash recently, which were PHP shops. They are a node/java shop now. And mentioning PHP will get you fired.
We have a government customer with PHP in their list of technologies that we are prohibited from employing in service of their contract. I thought it was kind of random to single out something that we never intend to use, but in their minds PHP is right up there with Flash as a pariah of the web.
So yeah, there are some people out there who really really hate PHP.
I've been using PHP for years and am a believer. It's just as good, if not better in many cases, as other languages used for similar purpose. Especially with the features PHP 7 brings; I particularly like the more robust type hinting. Just gotta write good code!
I recently had to work on a PHP codebase. It wasn't a very old one in terms of churn, but it had been around for a while. It was surprisingly clean and well-built from what I could tell, it just got lost in a transition to a new server in a new language. Symfony itself still has some warts in terms of boilerplate but it wasn't difficult to poke around the code. In fact, the most painful bit was setting up on a Mac because the extensions for IMAP and other things weren't easy to add in. That's more of an issue with Homebrew and their decision to reduce what they were willing to support.
Language wise, it's catching up a lot and the additions seem to be sensible enough. I'm not sure I would start a fresh project in it but it's great to see how it's matured over the years, and just like Typescript is to JS, I hope it provides a good introduction to things like static typing to novice programmers who are starting out with PHP for pure ease of use.
Beyond that, what's the point in hating a language? I've found real joy and enthusiasm in playing with different ones just to get a feel for how you would approach certain problems with them.
There's no point in hating a language. A former boss of mine had a saying (which I'm sure he didn't invent, but he definitely lived up to it and I admired him a lot) which was "love the problem, not the tech". He took pride in engaging with any problem to the best of his abilities, regardless of the language. He thought it was pointless to complain about the tech itself; if the tech wasn't suitable maybe it was part of a problem to be tackled rationally, not with hatred.
That said, I'm uncomfortable working with languages which I feel are outdated and get in the way, such as COBOL. You could say I do hate COBOL. I really, really disliked javascript in its infancy; you fought the (lack of) tools and suffered a lot just to achieve something that would have taken you 5 minutes with other languages. This is not the javascript of today, mind you.
One last thing: one should always be wary of the Blub Paradox (one of the best essays by PG in my opinion; I don't particularly like the rest, mind you). People who ignore advances in programming languages tend to look at "their" language, maybe praise its late-coming improvements, and wonder why other people think it's not enough. But it's often not enough indeed, once you learn those other languages...
I've no opinion of PHP because I've never used it.
The PHP IMAP extension is a bit of a sore spot. It's an interface to a C library (https://github.com/uw-imap/imap) which has been effectively abandoned for the last >10 years. There's been some off-and-on discussion about unbundling the extension from PHP or dropping it entirely.
I think a lot of people are confused at the lack of comparative statements here. As far as I can tell, every single benefit listed in this article also comes with, say, a Python/Django stack.
PHP has been on-par with Ruby and Python for a long time now. There's no reason to hate it, but also not a lot of reason to use it (or Ruby), since I think Python really has the mindshare now.
This is such a surface-level article. Most of the things listed as advantages exist in other languages as well.
Here are some actual reasons to like PHP:
1. Java-like interfaces and classes and strict argument (and soon parameter) typing enforced at runtime
2. Autoloading and "lazy loading" of classes means defining bi-directional relationships between classes/types is painless (this can of course also make you shoot yourself in the foot, but I prefer that to dealing with circular imports in Python for example)
3. The deployment model is dead simple on a VM (with drawbacks, but by the time you need things like atomic deployments you've probably moved to containers anyway)
4. Statelessness
5. Performance (despite the statelessness!)
6. A very healthy package ecosystem, with several cross-framework interoperability projects
It has lots of bad parts as well, of course, but so does every language. And you may disagree with some of the things I listed if you don't like the particular feature or design, but that doesn't make them not advantages.
You're right, probably the word advantage was a bad choice here.
The point I wanted to make was that you might disagree with a certain feature/design but that doesn't make them invalid reasons for someone else who likes them to see them as advantages.
I don't really like PHP, because of inconsistency (it tends to break to flow for me) (but maybe it changed since 2014), but php with strict typing is a big plus for me and php7 is already more than fast enough. I might try it again.
AFAIK, PHP 8 will support named arguments. I think that will make it easier to call built-in function without knowing the correct order of its arguments.
Compared to what language? I don't think PHP frameworks are very different from other languages I've played with.
Here's my framework guide: Slim if you're a minimalist and like doing things yourself, Laravel if you like convenience and are a quick learner, Symfony if you want to build something that will last 5+ years.
Laravel or Symfony. Laravel is far better for actually getting things to production quickly IMO. It's quite batteries-included but still lets you roll your own paradigms where you need to.
I don’t hate PHP either. I just want to be able to get another job doing something interesting after I spend 18 months at your company.
Otherwise I’ll be stuck in the public sector maintaining broken Deloitte unemployment portals, making 1/3rd of what junior coding academy developers make.
Blame the language for boredom. I think you'll like working at Microsoft. Because they frequently reboot apps, their OS, apis with completely different languages and ui paradigm for absolutely no reason - quite stimulating to the devs.
This comment is so true it hurts to read. Same can almost be said for other languages I actually _do_ like (perl, clojure.. sure there's _some_ jobs but the market just isn't the same as many others)
Source: left php about a decade ago and I'm not looking back
Whatever irritations I may have with current PHP-the-language (my biggest one is it's too easy to make string handling mistakes) are dwarfed by my irritations with that decrepit but incredibly popular PHP behemoth, WordPress.
The spirit of early-days security-ignorant PHP lives on in WordPress, where proper security is basically impossible. You'll never be confident that you've found all the back doors after an incident.
PHP to me is a bit like the new Perl. Sometimes you just need a small script that does one thing well. Took me 10-15 minutes to implement an interface for customer support so they can look up a clients last order based on incoming phone number (via Aircall) or name and surname. FTP'd it to an already existing company server and it just works. And saves them weeks of time over a year probably. Nobody cares that I debugged it via die("error");
With Python I'd be stuck reading the latest tutorial on how to deploy virtualenv properly. Java/Spring I'd die of boredom before I figure out where WebMvcAutoConfigurationAdapter wants me to put Bootstrap css this year. Sometimes you just want a quick solution to an easy problem and move on to other things than coding, and I find PHP fits that use case perfectly.
something about just getting the job done, i remember working at a place like that. i think we romanticize it a little bit though. we didn't have any version control, and deploys were literally paste the file on var/www and refresh. onboarding a new engineer, spend a month before they are actually productive.
i'm glad those times happened, they were fun - but i wouldn't want to work like that today.
The autoloader feature sounds interesting. I've always wondered why there is so much ceremony around importing modules when it seems like the compiler could figure it out in many cases (e.g. when you follow the Go-like style of having module names at the call site).
For example every Java file seems to start with entire screenfuls of imports.
I've never seen that in any other language. Though I'm sure there are a lot of pitfalls, because module systems tend to grow complex over time.
I don't see the appeal in omitting that ceremony. Modern IDEs do it for you. On the other hand, a reader of the code must not replicate the work the autoloader does. If there is a class named Database from the backend module. The concrete class referenced there is highly dependent on the environment, the autoloader has at runtime. For me, this seems to be a source of many non reproducable bugs.
Many comments here complaint that this article doesn't convince them to use PHP. Well, I think that is not the purpose of this article either. In my opinion, it only lists some feature of PHP to show that actually PHP as a language an ecosystem also has the feature other considered modern languages have.
84 comments
[ 2.7 ms ] story [ 171 ms ] threadThat doesn't add up. There was no "PHP 2.0"; the language was still referred to as PHP/FI at that point. And PHP 3 was released in 1998 -- by 2000, I have a hard time believing you would have still been using PHP/FI, which was a much more limited tool.
I would like to go one further and say most other more modern programming languages do each of these better. It's always a good idea to look what is beyond the horizon.
[1]http://www.nusphere.com/kb/phpmanual/language.oop.htm
And to be sure, modern PHP is better. The beginnings of typing, the fixing of horrible standard library behaviors, and an ecosystem with package management are game changers. But to me, all of that means nothing if the ecosystem is primarily running legacy apps. There are clearly proponents of modern PHP that embrace the new PHP, but what really gives it any modern relevance is old school apps like Mediawiki, phpBB, etc. and I feel like they all underscore what I dislike about PHP: not a single problem but a mindset that is incompatible with modern internet. There is no assumption of shared nothing; most apps assume the disk can be used for persistence. And it’s tricky to dockerize a PHP app effectively since you typically need multiple processes; I know there’s work on an app server in PHP itself but last I checked it was for development, and rather I ended up using uWSGIs embedded PHP support as the only solution I could even find that could do this in a way that wasn’t horrifically ugly or intensive.
It still has its issues. For me the prime issue with PHP is the execution model. I am not in for my document root being my source dir. This weird behavior comes from the CGI era and to this day it doesn’t really feel like there is intent to move away from it. Rather, the age old front controller pattern is poised as a “solution,” entangling web server, PHP and application configuration together in some unholy mess, versus the modern pattern of having an app server.
Absolutely. I handle a lot of the devops work at my job and PHP containers are just all around more annoying to build, configure and run than most other languages. Even on modern frameworks like Laravel still have a lot of default assumptions of being hosted on a server all by themselves.
It's weird how a language that gained so much traction for being the easy language to host has become one of the harder ones to deploy in the modern era.
This kind of toxic mentality doesn't produce better code, and it sure doesn't produce better coders. It's just free-floating hostility and gatekeeping.
Here's a few parts of PHP that improved in the past 6 years:
* Static type declarations (and return types, and strict typing, ...)
* Composer has become the de facto package manager for the PHP ecosystem
* Better cryptography (bye mcrypt, hello sodium)
* High quality open source libraries (i.e. Guzzle)
And I haven't even reviewed all of the changes coming in 8.0.
I made a lot of money on PHP code. But then realized there were other languages that I could also make money on, that worked better for what I needed. But would I go back? No..
OTOH, there are now mainstream languages with null in the type system, union types, pattern matching, etc... it looks (from the outside) like PHP caught up to where the industry was 10 years ago. If I'm uninformed I'd love to see a comparison to Typescript, Kotlin, Swift, or Scala3.
For an article that purports "PHP is good now", I wouldn't expect one of the selling points to be something that could be done in (and is routinely done), in Python/Perl/Ruby for over 25 years now.
Some folks might call that backward. I call it solving a problem with the right tool.
1. The Laravel ecosystem.
2. I have over ten years of PHP experience.
1. I'm not aware of any non-trivial feature in Laravel that isn't matched by e.g. Rails, Django, Elixir, or indeed any sufficiently modern web framework.
2. This speaks more to where your comfort zone resides than any intrinsic merit of the language/ecosystem.
To be clear: there's nothing wrong with your using PHP. I'm just left wondering what your initial point was... that PHP is your favorite language?
Is there ever a best tool for _everyone_?
I have only ever been convinced that something is the best tool for a job, when taking into a account a lot of context, exact requirements, available resources, etc. Otherwise you are almost always left with quite a large number of options that are equal for the information available and you can basically choose from by rolling dice.
Regarding 2) I think it goes beyond comfort zone. I have seen plenty of completely chaotic, unmaintainable code bases due to the initial developer(s) starting the project without any prior experience of the technology. Of course many paths lead to chaos, but I would wary to start anything time critical in something too different to what I'm already quite comfortable in
Did Python stray from this? Occasionally yes. Did PHP with Laravel? I'm going to guess also yes.
I don't think any Python folks would bother to clone it as most of what it does already has better answers in the Python world.
For example, SQLAlchemy is amazing, and I'd never willingly swap it for Laravel's ActiveRecord implementation.
To be clear, I definitely prefer Python to PHP, having worked professionally in both languages (PHP much more often, and currently).
In practice it mainly means that, in exchange for process startup overhead added to your response times, you get to get away with being sloppy about how you initialize and dispose of resources. It's not something I have ever really regarded as a virtue, and it's one reason why PHP devs can have real trouble transitioning to platforms where the same assumption no longer holds.
But dealing with small leaks that build over time can be a time sink to track down, particularly if in libs you didn’t author.
Proceeds to give a long list of outdated and clunky examples that look like a joke next to any modern framework.
That said, I'm not even saying PHP is bad, but this article doesn't convince me why I'd pick PHP over literally anything else.
Isn't it just not that popular an option anymore to start new projects with? Most people are aware of the language having changed a lot since its heydays.
And honestly, from the article I'm not quite sure why I should consider using PHP. Sure, it has a lot of modern bells and whistles now that it didn't when I last used it 2005-ish, but what makes it stand out? I know a number of people that are super happy and productive with modern PHP, but those are all people that have been using it continuously since forever so it makes a lot of sense for them. But why switch to it from another stack?
E.g. the supposed best database integration of any language with "PHP Database Objects". At least the examples given are the absolute bare minimum I'd expect to get from such an integration. What makes it the best?
Quite. Just give me a boring language with a stable ecosystem, mature and extensive tooling and fully understood quirks. That means all the time and effort can be spent building the actual product instead of burning time monkeying around with the shiny-new language.
This means that things like Java and PHP (and C in some domains) are nearly universally the correct answer if your goal is to build a product instead of building a resume.
Source: consulted at two companies that survived dot com crash recently, which were PHP shops. They are a node/java shop now. And mentioning PHP will get you fired.
So yeah, there are some people out there who really really hate PHP.
Language wise, it's catching up a lot and the additions seem to be sensible enough. I'm not sure I would start a fresh project in it but it's great to see how it's matured over the years, and just like Typescript is to JS, I hope it provides a good introduction to things like static typing to novice programmers who are starting out with PHP for pure ease of use.
Beyond that, what's the point in hating a language? I've found real joy and enthusiasm in playing with different ones just to get a feel for how you would approach certain problems with them.
That said, I'm uncomfortable working with languages which I feel are outdated and get in the way, such as COBOL. You could say I do hate COBOL. I really, really disliked javascript in its infancy; you fought the (lack of) tools and suffered a lot just to achieve something that would have taken you 5 minutes with other languages. This is not the javascript of today, mind you.
One last thing: one should always be wary of the Blub Paradox (one of the best essays by PG in my opinion; I don't particularly like the rest, mind you). People who ignore advances in programming languages tend to look at "their" language, maybe praise its late-coming improvements, and wonder why other people think it's not enough. But it's often not enough indeed, once you learn those other languages...
I've no opinion of PHP because I've never used it.
Here are some actual reasons to like PHP:
1. Java-like interfaces and classes and strict argument (and soon parameter) typing enforced at runtime
2. Autoloading and "lazy loading" of classes means defining bi-directional relationships between classes/types is painless (this can of course also make you shoot yourself in the foot, but I prefer that to dealing with circular imports in Python for example)
3. The deployment model is dead simple on a VM (with drawbacks, but by the time you need things like atomic deployments you've probably moved to containers anyway)
4. Statelessness
5. Performance (despite the statelessness!)
6. A very healthy package ecosystem, with several cross-framework interoperability projects
It has lots of bad parts as well, of course, but so does every language. And you may disagree with some of the things I listed if you don't like the particular feature or design, but that doesn't make them not advantages.
Since the above equally applies to you, I suppose you're saying that these "advantages" are a matter of opinion.
The point I wanted to make was that you might disagree with a certain feature/design but that doesn't make them invalid reasons for someone else who likes them to see them as advantages.
I don't really like PHP, because of inconsistency (it tends to break to flow for me) (but maybe it changed since 2014), but php with strict typing is a big plus for me and php7 is already more than fast enough. I might try it again.
The real issue i have with PHP is frameworks :/
Too much choice is a productivity killer for me.
For instance, the arguments for array_map and array_reduce are reversed, one takes the function as first argument, one the array.
Here's my framework guide: Slim if you're a minimalist and like doing things yourself, Laravel if you like convenience and are a quick learner, Symfony if you want to build something that will last 5+ years.
Otherwise I’ll be stuck in the public sector maintaining broken Deloitte unemployment portals, making 1/3rd of what junior coding academy developers make.
Easy calculus.
Source: left php about a decade ago and I'm not looking back
The spirit of early-days security-ignorant PHP lives on in WordPress, where proper security is basically impossible. You'll never be confident that you've found all the back doors after an incident.
Nothing can beat features like hot reloading, fast debugging, get things done in a matter of few hours.
With Python I'd be stuck reading the latest tutorial on how to deploy virtualenv properly. Java/Spring I'd die of boredom before I figure out where WebMvcAutoConfigurationAdapter wants me to put Bootstrap css this year. Sometimes you just want a quick solution to an easy problem and move on to other things than coding, and I find PHP fits that use case perfectly.
i'm glad those times happened, they were fun - but i wouldn't want to work like that today.
For example every Java file seems to start with entire screenfuls of imports.
I've never seen that in any other language. Though I'm sure there are a lot of pitfalls, because module systems tend to grow complex over time.
Entity Framework in .NET is lightyears ahead of PDO.
I'm a fan of PHP but the DB connectivity is definitely not one of the strong points.