It seems to be common knowledge that PHP is a terrible language and that it's not enough to simply avoid it, but to signal your position with memes...
For further actions, you may consider blocking this person and/or reporting abuse
Nothing wrong with criticism at all. Well grounded criticism is the only path to improvement
Details please, otherwise deep familiarity is required in order to evaluate your point.
Sure, maybe a different topic, but always a good reminder: never close your mind from other impulses and/or new possibilities
Well, on 3 ... where do we start ...
Basically what I would expect from PHP 8 to fully stand its ground are:
On a more general level, if you spend enough time with PHP and then look at things like Elixir or Go, it's natural to start question if there's a purpose to having so much tooling and conventions (standards) that on a higher level are all meant to make up for the shortcomings of the language and platform. Sure, PHP is not the worst offender in this regard (thinking Node/JS - but Node, aside from having its own lightweight runtime that doesn't need external tooling also has ReScript that helps with language issues).
Hm, so let's start with the obvious one:
Inconsistency of the standard library especially in utilities
Yes. Although I have seen arguments on how the libraries in itself are consistent, that doesn't help for userland.
Before going into the rest of your points, I want to clarify why I consider some of them as opinion: The opt-in approach to many features like typing, PSR etc while maintaining comparability to features like include have pros and cons. I can see how a team can say that there is too much room for bad practices and too much knowledge of side effects is required. On the other hand, I also understand the power of being able to grow within a language and disregarding these arguments with "of course you can use a knife as a weapon, but that doesn't make a knife a bad thing". As such, much of the following is my opinion.
Superglobals
With a huge amount of approaches available to create statefull apps, the more interesting question is why e.g. SESSION remains the standard implementation. You mentioned approaches yourself, so we don't have to go into it, but it's a nice example of many "we will stay compatible to X" that has defined discussions of PHP externals (and I of course internally) for years. The reason this is such a heated topic is in itself proof of different opinions even with very familiar and experienced devs. So yeah, if you can't live with these decisions, I guess you are not alone.
Routing
That's an interesting viewpoint and a new one to me. Ironically, one of the reasons I would opt for using PHP is when exactly that behavior is beneficial. Just like with asynchronous behavior and all the other features that nowadays are possible with PHP, I am not a fan of tweaking basic principles. So some of the points you make - and I may interpret that wrong, so please correct me - aim at a one-for-all solution, while other options (languages) might be a natural fit.
"On the other hand, I also understand the power of being able to grow within a language and disregarding these arguments with "of course you can use a knife as a weapon, but that doesn't make a knife a bad thing"." - definitely, though the issues come when working with others.
If I would have to categorise the issues I have with PHP, aside from language issues, those would be:
There are load of people trained under old PHP versions (I myself started with PHP 4, although one of my favourite PHP WTF's happened in PHP5 where you had a DateTimeInterface which you couldn't implement yourself). These people will hang on to doing things their own way. The platform still allows that! It takes a lot to reframe people's minds and doing that when you happen to have someone used to PHP 5.6 on your PHP8 project is overload. I really think PHP evolution should do more to cleanup garbage and push for evolution, otherwise PHP 5 practices just get carried over and help preserve that bad reputation of the language.
Yes, I think I got your view the first time around. I understand these concerns and know that many devs feel that "disabling the possibility for bad behavior" is the solution. And it's not that I necessarily disagree. As you said, especially when collaborating a more opinionated structure can avoid a lot. All I am saying is that the reason why this is not what happened in PHP8 is due to the fact that arguments from the "other side" prevailed. I think in a few years we'll be able to compare this better as e.g. Rust promised to never have a version 2 (so no breaking changes ever). After all, it seems to me that the internals team settled for "deprecation over time" concerning some of your points.
I remember a discussion regarding laravel a few years back where security concerns based on the misusage of model methods were addressed. I found myself thinking that a dev should be expected to know what usage of certain features implies, while the vast majority took a similar position as you and argued that the framework itself should make it impossible to produce this vulnerability. The problem I see with this notion is that I wouldn't know where to stop: after all, if you know what you are doing, then opinionated structure is just a limitation to innovation as you automatically set certain things in stone. And the necessity in many cases isn't there. It not that tooling like e.g. precommit hooks can't address many team based opinions.
"if you know what you are doing..." - well, it's a valid point, but I don't think there's an algorithm for it. It's valid to say it's a potential slippery slope but let's also consider that nobody's under any obligation here to set any hard thresholds. To me it's an issue when there's a sizable number of developers that build vulnerabilities using formerly valid practices. At some point it becomes hard to build enough conventions and practices (and hope that people will follow them under pressure) and it's easy to say "hey, that other platform/language is better because it prevents the things that make life hell for us". This is a lot of what cognitive load is about: I'm using language practices that are/were valid but they cause issues under a certain framework. I'd argue that either the platform OR the framework should prevent that. The number of things like this to keep in mind (in addition to all the gotchas and quirks) is much higher in PHP (for most of the very same things in JS, the TS platform actively fixes and deprecates stuff). Sure, as a PHP developer you should always know these (+ whatever framework you happen to use) but I'd argue that the platform and/or the framework should not be afraid to reduce the cognitive load.
"opinionated structure is just a limitation to innovation" - I've heard this before, and I know many people find joy in tooling as much as in the platform itself but IMHO innovation doesn't come from building often redundant tooling (sure, one static code tool is ok, but 10 is already too much) but from getting to code solutions.
Love the article. Frankly for all developers, regardless of language-allegiance:
You don't know, what you don't know. Learn this lesson and accept that no matter how much you've learned, someone else will always come by knowing something you don't. This is the nature of web development.
I see many newbies talk crap about PHP because they don't know how to use it.
I see "classical programmers" talk crap about PHP, but they can't build websites any better than the average PHP dev without a mountain of dependencies and compiling. God forbid they try frontend html/css.
I mean, sure, you can "write" html and css easy, anyone can. But you can't make it crossbrowser, responsive, seo-friendly, accessible and perform well without some serious experience doing it. The same goes for using PHP for websites.
A lot of people list WordPress as to why they hate PHP, and most often it's because they've had one or two experiences with badly written themes. Let's blame the most popular CMS in use by 1/3 of the internet because it gets constantly attacked by hackers while keeping the bar to entry so low that a dev with zero experience and use it in one day.
Note that a great many themes were created by designers, not developers, or outsourced to the cheapest bidder, the end result, a marketplace full of crap, this isn't the fault of PHP.
Again, you don't know what you don't know.
As for the security flaws in PHP....yea, there are some. Does anyone using PHP daily care? No. Do experienced devs know how to secure their code? Sometimes.
I have sites I built 15 years ago that still run perfectly fine. Some have been hacked over the years, and we patch em, rebuild 'em or just spin em back up from a backup. That's part of web development, we are literally under attack 24/7.
Anyone who hasn't experienced that can just drop the subject because you don't know what you don't know.
As with any language, the language is never the problem, it's the developer's skill level that determines if what they produce is crap or not.
Build me a website in brainfuck, then I'll accept that claim.
Just because you and I, and probably everyone, are bad at Brainfuck doesn't make the language the problem.
Programming languages are built for people to use them; if everyone is bad at using them, than yes, that's the languages fault. If your hammer has no head, it's not your fault for not swinging the stick hard enough.
Lol, it still comes down to the users. If a language really is so "terrible" then people shouldn't use it. Brainfuck was created as a joke, as a proof of concept, and some hardcore nerds decided to actually use it, but no one in their right mind uses it for real world applications.
And really most discussions about whether a language is good or bad revolve around .NET, PHP, and JavaScript or the C, C++, C#, Java arguments.
These are all languages uses by hundreds of thousands of devs globally. And in each of them, the language is not the problem. The devs understanding of the language is.
PHP
Well said, all of this about the security, experience, and the "what you don't know, you don't know" phrase :)
Oh, and in anticipation of some backlash: please state your
in your feedback. It helps me and others to filter through potential "fan-boy" responses and get to real arguments. Thank you!
There's a lot of misunderstanding around what PHP even is and what it's capable of. I agree that bashing it is uncalled for. I write a lot of PHP and have built a ton of applications with it that did and are still doing very well.
People should at least be informed before hating on it.
But that doesn't mean it doesn't have shortcomings.
For some people, the fact that PHP isn't a threaded language and likely never will be is a big deal breaker.
The way PHP applications spawn new processes with each request life cycle gives it a pretty significant hit against requests/second when benchmarked with other languages.
The fact that the same line of code can do more than one thing depending on the
php.inisettings is pretty crazy to people coming from other languages. It's annoying at best. It's catastrophic at worst.Or the fact that shallow comparison is rendered useless due to it's arcane inconsistencies and completely unpredictable behaviour. So why even have it?
It's type system is incomplete. Good luck auto-generating Swagger docs ever (and I don't mean hand writing annotations i.e docblocks).
Also, more of an ecosystem issue than a language issue but the fact that Type-Hints will coerce primitive arguments unless a script is in "strict mode" really sucks (in my opinion). For people coming from strongly typed languages especially, this is vomit inducing. But AFIK even loosely typed languages that support type annotations won't coerce types on you if you use annotations. Tooling could automate setting strict mode either through linting or a transpilation step but things like Hack never really went anywhere and most PHP devs don't bother with "strict".
Also, the most popular PHP framework is basically impossible to run in "strict mode" anyway so if you want true static analysis and type checking you have to use less popular choices (not the end of the world but still).
Until very recently error handling has been a mess. The fact that not all errors can be caught in a try..catch is asinine. I guess this is finally fixed in version 8 though? But how many people are even using 8 yet?
Language extensions are interesting but overall a PITA to work with and really just makes PHP impossible to use without VM's or Containers.
The core is complicated and maintained by volunteers with no backing from any major company. This could seem as a plus too but overall it means PHP is in kind of a tough spot. It's extremely difficult to contribute to, and few people really understand it. AFIK there's been a scent of burn out from some of the core contributors which is totally understandable but a little scary.
Another issue I see, although nit picky, is that for a new comer who is already an experienced programmer in another language it's probably pretty confusing. PHP doesn't look very "OOP" without 3rd party tooling. Autoloading is essentially like "linking" I guess? Only it's not handled by the language itself? Kinda weird. Plus installing and configuring PHP is quite the hurdle compared to other languages.
That said, I still have a distaste for the discouraging of new developers from learning PHP. That kinda seems like the trend for educational content now days. There's this weird lie (or denial?) that gets thrown around to aspiring devs that "PHP is a dead language".
Thanks for writing this article. I'm a MERN stack and PHP developer. In general, anyone who criticize a language like this isn't a mature developer. React/Node aren't the ultimate answer. Choose the right tool for the right task.
I 100% agree
PHP still deserves bashing though. It's just a very bad programming language that has outgrown its niche to fill the void of a simple server-side language for content generation, and now than other (better designed) languages have also made it there, PHP can't keep up with its newfound competition.
I still consider php a template framework and I mean this positive, looking at php you see a lot of similarities with React which I love.
Actually in past few years, It is almost as good a programming language as Java or c#. It was a template language in php 5 days, but now it actually feels like a proper programming language.
I contracted for a company last year which had a barebone custom framework actively maintained ( they upgraded 7.3 to 7.4 while we were working. ). Their CTO was experienced Java Architect, so our coding style, Module organization, OOP implementation etc were all inspired by Java. It was surprising even for me. He taught us all a lot about structuring code.
This year, I am working with PHP 8.0 API, Kotlin and VueJS. So far I am loving the stack. It is much better than my spring-mvc days.
Uff, I don't know. One one hand, I see what you mean by similarities to React, on the other hand, clean PHP usually leverages an MVC which React implementations usually don't use. Lastly, given the fact that modern PHP is often a pure API, I cannot agree with the template statement at all.
Well even the creator agrees with the template statement, because it was created as template engine and not a programming language, of course this changed now but you still see the templating features React took as inspiration.
Yes, I guess phrased like that I come to the same conclusion
That is my experience as well, and flaws based on "why does PHP allow such a mess" is a complete topic in itself. But here I am focusing on "opinion" that isn't based on any real-life experience but sheer "trend"
I think really the problem with PHP is that it is so easy to get started with the basics that people who have no programming experience or training can jump in and start making something. PHP is really good at what it does and in the hands of someone who knows what they are doing can be hugely successful. On the flip side it allows people with no concept of security, maintainability, usability etc etc can create all kinds of crap.
So essentially its ease of use has created an atmosphere where professionals have to go in and clean up after people who shouldn't have been writing a program in the first place. This leads to the design of PHP being directly correlated to its perceptions by developers.
Yes, I think that is certainly a factor
People has bashed Perl also a lot. I started Perl in 2012 and with all these years passed I am still not able to understand why people hate it so much. Yes constructive criticism are welcomed by everyone. But to form an opinion about something you have to use that thing for some time. Perl has evolved over time and Modern::Perl(> v5.10) is quite better.
A bad programmer can write bad code in any language.
P.S. Before Perl I used PHP also till 2011. :P
As we know PHP is a programming language designed specifically for web development. It always had major designing flaws and for many years there were also
performance issues. However after that PHP became popular in late 90s despite its flaws and even was a standard for web development for many years,
Because its competitors of that era (Java, C/C++, Perl) were less suitable for web development.
Nowadays (25 years later) server-side web development technological landscape is extremely competitive and now we have few strong languages or platforms,
that are as good or even better than PHP for web development, while lacking its major flaws. PHP became stupid to catch. That is why PHP is going down by modern web developers.
I don't share this assessment. First, I don't think that Perl or Java were less suitable for the web. The developers using these languages simply didn't "adopt" web early on. Secondly, while there are many solutions addressing structural issues of PHP (for example GO), these aren't the popular alternatives. Instead, node "rules" the backends when it comes to sheer numbers, and that certainly doesn't produce an advantageous outcome. Lastly, especially with the rise of Laravel, PHP isn't "going down" either. It's still the most used language despite all the diversity we have today.