Stop-saying-PHP-is-dead(medium.com)
medium.com
Stop-saying-PHP-is-dead
https://medium.com/swlh/stop-saying-php-is-dead-9489ed7dc25e
35 comments
These "stop making fun of PHP" articles are all the same. They are full of strawman arguments like "PHP is not actually slow!".
Nobody is complaining about it being slow. What about the fact that using an undefined variable is not an error in PHP? Yes, even in the brand-new PHP8. The fact that the function to open a file can also open an HTTP URL, run a glob, or even execute a command over SSH? Take a look at some of the things that were just fixed in PHP8 and ask yourself: if these things were just fixed after this many years, what other monstrosities are still in there?
Instead of writing "PHP is good because I've been using it for 20 years", I want someone to tell me "no errors for undefined variables is good because _______".
Nobody is complaining about it being slow. What about the fact that using an undefined variable is not an error in PHP? Yes, even in the brand-new PHP8. The fact that the function to open a file can also open an HTTP URL, run a glob, or even execute a command over SSH? Take a look at some of the things that were just fixed in PHP8 and ask yourself: if these things were just fixed after this many years, what other monstrosities are still in there?
Instead of writing "PHP is good because I've been using it for 20 years", I want someone to tell me "no errors for undefined variables is good because _______".
It's less "good or bad" and more of a philosophical choice.
PHP, especially old PHP, prioritized survivability over technical correctness. The "no errors for undefined variables" thing is just one aspect of that. Unquoted text strings accepted rather than being treated as constant names or throwing errors. Functions that failed silently and you had to retrieve the error code with a seperate function or return value. Implicitly cast a string into a taco salad. All of these things mean that code with a modest density of minor bugs-- the sort of code you'd get from normal skill programmers with low-spec tools circa 2005-- will manage to stagger its way far enough to output something useful in a browser window. It won't pass any sort of rigorous analysis but it will still work well enough to solve real user problems and make real money.
You could make a case that while more restrictive paradigms may be desirable in 2020, they are not strictly required because they can be pawned off on the ecosystem. IDEs are more capable, there are any number of auto-linters and rule-enforcers available. So you can get most of the benefits of a shinier language, but with the flexibility of still being able to drop back to "here's the 20-year-old PHP4 code that does a business critical task and can never ever be touched" level mid-project.
I feel like comparing PHP with $trendy_newer_language is sort of like the HTML/XHTML divide a long time ago. Making an intentional brittle system that demands correct developer behaviour might force you to make better code, but cheap, quick, and practical might make a better business.
PHP, especially old PHP, prioritized survivability over technical correctness. The "no errors for undefined variables" thing is just one aspect of that. Unquoted text strings accepted rather than being treated as constant names or throwing errors. Functions that failed silently and you had to retrieve the error code with a seperate function or return value. Implicitly cast a string into a taco salad. All of these things mean that code with a modest density of minor bugs-- the sort of code you'd get from normal skill programmers with low-spec tools circa 2005-- will manage to stagger its way far enough to output something useful in a browser window. It won't pass any sort of rigorous analysis but it will still work well enough to solve real user problems and make real money.
You could make a case that while more restrictive paradigms may be desirable in 2020, they are not strictly required because they can be pawned off on the ecosystem. IDEs are more capable, there are any number of auto-linters and rule-enforcers available. So you can get most of the benefits of a shinier language, but with the flexibility of still being able to drop back to "here's the 20-year-old PHP4 code that does a business critical task and can never ever be touched" level mid-project.
I feel like comparing PHP with $trendy_newer_language is sort of like the HTML/XHTML divide a long time ago. Making an intentional brittle system that demands correct developer behaviour might force you to make better code, but cheap, quick, and practical might make a better business.
I hear what you're saying and I appreciate your answer to the question I asked. But I still can't see it that way.
I worked in PHP5 for many years. The "survivability" thing didn't make anything cheaper, quicker, or more practical. It just made it harder to find bugs, and slower to develop new code that could pass tests (since getting your tests to pass is the process of eliminating bugs).
Achieving correctness is not hard in most languages. It's possible in PHP, but more difficult than most. I'd say the same for readability, given PHP's wide array of naming conventions.
So if we're crossing off cheap, quick, practical, correct, and readable, what do we have left? I suppose if nothing matters, then programming language choice doesn't either. But I think what we have left is "using PHP". The reason people use PHP is because using PHP matters to them. It's just what they want to do. Look at the post we're commenting on, where nearly the entire argument is "I use it because I've always used it".
It's fine if people want to use it. What gets me is when a manager wants to use PHP and I explain what a poor decision that would be, and in return I get sent a blog post like this one which makes a bunch of strawman arguments without actually addressing the real issues with the language. Your attempt to address them is among the best I've seen, but I'm still not buying it.
With regard to survivability vs. correctness, I'm glad the language is going the other direction now. It looks like they added a bunch of errors to PHP8. I am holding out hope that as every major decision in the language gets reversed, eventually something unrecognizable and much better will emerge!
I worked in PHP5 for many years. The "survivability" thing didn't make anything cheaper, quicker, or more practical. It just made it harder to find bugs, and slower to develop new code that could pass tests (since getting your tests to pass is the process of eliminating bugs).
Achieving correctness is not hard in most languages. It's possible in PHP, but more difficult than most. I'd say the same for readability, given PHP's wide array of naming conventions.
So if we're crossing off cheap, quick, practical, correct, and readable, what do we have left? I suppose if nothing matters, then programming language choice doesn't either. But I think what we have left is "using PHP". The reason people use PHP is because using PHP matters to them. It's just what they want to do. Look at the post we're commenting on, where nearly the entire argument is "I use it because I've always used it".
It's fine if people want to use it. What gets me is when a manager wants to use PHP and I explain what a poor decision that would be, and in return I get sent a blog post like this one which makes a bunch of strawman arguments without actually addressing the real issues with the language. Your attempt to address them is among the best I've seen, but I'm still not buying it.
With regard to survivability vs. correctness, I'm glad the language is going the other direction now. It looks like they added a bunch of errors to PHP8. I am holding out hope that as every major decision in the language gets reversed, eventually something unrecognizable and much better will emerge!
I really can't think of any green field project that would be started with PHP today. Maybe if there is some specification to use something PHP specific. But any use case I can think of, Python or node is a better choice. Maybe even Java. And Rust is on the rise now, in case speed is needed. PHP isn't dead yet. But it definitely is not growing.
Also arguing that choosing a language based on ugliness is a stupid idea is a stupid idea on itself. Quality of life during development is not an insignificant thing. The resulting project will suffer greatly if the chosen language makes me want to tear my hair out.
Also arguing that choosing a language based on ugliness is a stupid idea is a stupid idea on itself. Quality of life during development is not an insignificant thing. The resulting project will suffer greatly if the chosen language makes me want to tear my hair out.
I have started one side project , and one startup this last 3 month, all in php/symfony, though I have made extensive use of python (and php) in the past (and do a lot of rust on the side)
1. A mature ecosystem: Symfony is really really mature, all use case of a classic website are covered:
3. easy as hell to find developers, developers that likes to get things done and that are pragmatic (They know, I know, we all know PHP have shortcomings, do we joke about it? yes. Does it prevent us from moving forward ? no)
1. A mature ecosystem: Symfony is really really mature, all use case of a classic website are covered:
* easy "admin" generation -> check
* easy styling of your forms (a guy already made a 'tailwind' template, now I just do {{ form(my_form }}, and that's it
* easy integration with webpack for my usecase with tailwind
* pretty fast load to the point that the backoffice feels like a SPA (no flickering)
* word-class ORM (Doctrine is just the best ORM ever, they really got right the 'if you know SQL, you will not have to learn yet an other dialect, all our functions/method use the exact same naming as in SQL , take that django ORM)
* once again word-class ORM (Doctrine make it very easy to use all postgres-only, or mind you, mysql-only feature, DATE_TRUNC , json operators, full-text search operators etc. etc.)
* The documentation is not only encyclopedic , but also 'cookbook' (i.e you can either go A to Z, or they have dedicated article "how to have 2 database" , "How to implement a login through JSON" , which are much better and up to date than googling "how to X with framework Z"
3. easy as hell to find developers, developers that likes to get things done and that are pragmatic (They know, I know, we all know PHP have shortcomings, do we joke about it? yes. Does it prevent us from moving forward ? no)
You have invested a lot of time into PHP and can make a living out of it. More power to you!
But from my anecdotal experience not many new developers invest the time to learn PHP. At the two universities I've been to, PHP is usually one and done thing. You take one course or just a few lessons with PHP in web development class and then move on to other things.
But from my anecdotal experience not many new developers invest the time to learn PHP. At the two universities I've been to, PHP is usually one and done thing. You take one course or just a few lessons with PHP in web development class and then move on to other things.
I also got the same kind of class, I think php was a 2 week class (less than the Java courses or SQL courses, same as the ASM courses).
a 2/3 of my career was python, I 2~3 years of PHP around 2011-2014, and now I'm using it back as I'm finally doing my own company.
And the best part of it ? It's right where I left it, even thought it went from 5.4 to 8 , and from symfony 2 to 5. It feels like leaving your old band from college to find out you all have the same habits, just everyone improved along the road.
Regardless how much I like python, to have been the one needing to own the "python2 to 3 migration" projects of 3 companies, it was not pretty.
a 2/3 of my career was python, I 2~3 years of PHP around 2011-2014, and now I'm using it back as I'm finally doing my own company.
And the best part of it ? It's right where I left it, even thought it went from 5.4 to 8 , and from symfony 2 to 5. It feels like leaving your old band from college to find out you all have the same habits, just everyone improved along the road.
Regardless how much I like python, to have been the one needing to own the "python2 to 3 migration" projects of 3 companies, it was not pretty.
My anecdotal experience is that in university, the only programming languages I learned where C, C++, and COBOL.
The rest was data structures, algorithms, etc. I've picked up many languages over the years and just applied CS concepts on them.
The rest was data structures, algorithms, etc. I've picked up many languages over the years and just applied CS concepts on them.
Market share of WordPress as website platform in 2011 : 13%
In 2020 : 38%
Yeah, php is not growing. Growing might start to become difficult when you en 40% of the web.
Which of these new websites have large userbase? Anyone can start their Wordpress blog with some limited free hosting and thus increase Wordpress market share. And since internet has grown considerably in the last 10 years more people tried to make their own website. And with Wordpress that is incredibly easy for people who are not technologically inclined.
Sure, websites like TechCrunch, BBC, Playstation Blog or Variety use it but they have done so for a long time. Newer websites/companies are not using Wordpress and maybe not even PHP. Medium runs on combination of Node and Go, Twitch has gone with Ruby on Rails among others, Trello runs on MongoDB and CoffeeScript on the frontend and I could go on.
Sure, websites like TechCrunch, BBC, Playstation Blog or Variety use it but they have done so for a long time. Newer websites/companies are not using Wordpress and maybe not even PHP. Medium runs on combination of Node and Go, Twitch has gone with Ruby on Rails among others, Trello runs on MongoDB and CoffeeScript on the frontend and I could go on.
PHP for web is great but you'll still want to use another technology for real time functionality, such as: Elixir/Phoenix, nodejs, Go, Java.
I really actually like PHP in a lot of contexts (and think I could make a better case for it than the author), but on the project I'm working on now, we recently got hit with the real time requirements and I'm feeling some regrets that I didn't pick Elixir+Phoenix to start with.
Phoenix does offer a pleasant, streamlined full stack experience, and it does seem kludgey to bake together PHP and Phoenix without good reason.
If I didn't have a team to deal with a large Elixir codebase (a common issue), I'd glue PHP and BEAM together anyway, even going as far as to pass along the "meat and potatoes" backend work to PHP even for socket interactions (or in some asynchronous way, as needed). In that scenario, the Elixir sockets frontend could be fairly minimal, both in terms of codebase and DB interactions, and would possibly not need a lot of code changes over time.
If I didn't have a team to deal with a large Elixir codebase (a common issue), I'd glue PHP and BEAM together anyway, even going as far as to pass along the "meat and potatoes" backend work to PHP even for socket interactions (or in some asynchronous way, as needed). In that scenario, the Elixir sockets frontend could be fairly minimal, both in terms of codebase and DB interactions, and would possibly not need a lot of code changes over time.
That's probably where we're heading: the existing PHP code will still control state for the app and push events/messages to a relay app managing websocket connections with the front end (probably written in Elixir, or possibly a websockets-as-a-service offering initially).
I mostly heard, yeah it’s not great but I’ve been doing it for so long..
But hey, I’ve been doing it for a while to, so how can I learn to write more beautiful php? And do you only use it for backend since you said “we don’t do php in html anymore”?
But hey, I’ve been doing it for a while to, so how can I learn to write more beautiful php? And do you only use it for backend since you said “we don’t do php in html anymore”?
I think the php in html thing has been replaced by templating tools where we write html templates with"template strings" that allow you to put dynamic data into the html, and all the php is concentrated in more well defined libraries.
The amount of logic we used to do with php inside otherwise html files has been shown to be bad software design.
The amount of logic we used to do with php inside otherwise html files has been shown to be bad software design.
I think you might have the wrong end of the stick.
Stop saying PHP is dead, stop saying PHP is bad, stop saying PHP is good.
Php has been dead for years.
Seems like this "dead" language has, as of today 2020-12-05, been used by the 79.1% of websites.
https://w3techs.com/technologies/overview/programming_langua...
https://w3techs.com/technologies/overview/programming_langua...
>Php has been dead for years.
So has C, and C++, and Java, and literally every other programming language besides Rust and Go, and maybe Python, depending on who you ask.
So has C, and C++, and Java, and literally every other programming language besides Rust and Go, and maybe Python, depending on who you ask.
PHP-is-dead
No.
When Laravel came out, it had introduced me to Symfony and at that time I have decided to give it a second chance.
I haven't regretted it ever since.
Are there ugly parts in it? Yep, like every single programming language out there.
But here's the good thing: I have applied SOLID principle thanks tto Symfony and Laravel, which is (at least to me): hide the ugly parts behind a friendlier code base and deal with your newly designed interface.
Not only it makes your code clearer, it makes it extremely easy to follow your logic, plus it motivates you to write more projects just for fun.
About WordPress...yeah, it has its countless quirks, but trust me; it's getting there.
Eventually, it will become a nicer platform for the end-user, especially now that adopts more JavaScript in both back and front end.
All the legacy code is getting upgraded slowly but steady with modern PHP standards, even Composer is being used at some code bases now, plus with modern tools we automate lots of procedures that used to be considered chore.
Now about writing code that can deal with high traffic...you can do that with modern PHP, yes, but you have an extra option nowadays: Swoole!
If Baidu and other Chinese companies are using PHP exclusively, they deal with MILLIONS of people on a daily basis, and contribute back in the language itself (core / swoole extension), what else do you want?!
Is it dead?
Not even close, especially now with the release of PHP 8.0 that gets closer to enterprise standards!