Stop-saying-PHP-is-dead
medium.com
medium.com
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!
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 _______".
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 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!
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.
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)
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.
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.
The rest was data structures, algorithms, etc. I've picked up many languages over the years and just applied CS concepts on them.
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.
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.
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”?
The amount of logic we used to do with php inside otherwise html files has been shown to be bad software design.
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.
At least C (and C++) will never fully die.
https://w3techs.com/technologies/overview/programming_langua...