When PHP was first released it was dramatically better than the alternatives for it's intended purpose.
There were plenty of things to complain about, but none of them stopped you from doing useful things with it. It was never slow or inefficient compared to other scripting languages, it didn't lack functionality.
Over the decades the most popular complaints have been addressed as the language has matured.
That it's remained in active development for 25 years with no signs of that changing in the future is one of it's biggest selling points.
I don't blame people for having issues with aspects of PHP based on their personal preferences and experiences, I get that, but that doesn't make it a 'bad' language.
There's nothing wrong with purist perspectives on what programming languages should be and how they should work. That contributes to better design.
But in the real world the questions are simpler: can this tool be used to develop applications quickly? Is it reasonably efficient at runtime (in this case in the context of scripting)? Can we easily find affordable developers in the future? Is there community support?
PHP checks the boxes that people building things want checked as well as any language and better than many. Unless I'm missing something, 'bad' here is more of a philosophical stance.
I mean there are some quite uncontroversial languages. For instance Python. What surprises me the most, C is segfaulter #1 but literally nobody complains about that because it works good enough and the code is elegant. I think it still holds the position of most beloved systems programming language
Plenty of people complain about Python - about the language itself (significant whitespace, dynamic typing and excessive complexity), about the implementation (slow and limited by the GIL) and about the ecosystem (e.g. https://xkcd.com/1987/).
A self argument is on methods because then, from the inside, methods are identical to functions, rather than functions with additional implicit magic.
Also because it's a function member of the class with exactly that argument pattern; calling instance.method(...) is just syntax sugar for ClassOfInstance.method(instance, ...).
This also makes Python handling of unbound methods a lot cleaner than, say, Ruby.
Segfalter is a feature which prevents release of weak code by weak people. Granted such approach isn't suitable in enterprise where Java rules because any kitchen sink of staff thrown together in
Java still runs somehow, yet in systems you must meet orders of magnitude higher threshold.
Bad type coercion you can’t turn off with weird semantics. Powerful but confusing arrays/dictionaries. Inconsistently named stdlib functions with inconsistent parameters. Little to no support for threading or concurrency models outside of making event loops or running multiple processes. Memory management that allowed for leaky memory all the time. Lack of proper support for stand-alone daemon processes (you could make it work but it was clearly not the main way PHP was meant to be run). Lack of namespaces or modules with all variables being global.
This was PHP 5 and it sent me running for the hills (Python, ES6). I am sure PHP 8 is an improvement and I’ve worked with PHP versions past 5.3 but it left such a bad taste in my mouth that yes I will avoid it if I can. Fixing what shouldn’t have been broken may make this language almost as good as something like Python but why would I reach for PHP when better things exist unless that decision is not made by me?
> Little to no support for threading or concurrency models outside of making event loops or running multiple processes.
Having just started with programming, this is more feature than bug. It’s super easy to reason about PHP applications because the whole flow is linear from top to bottom.
Not sure what you mean about global variables. PHP 5 had the same scoping rules like it has now. You couldn't access global variables directly from anywhere but the toplevel execution context.
That’s a problem. Same with every function and class name. Oh and requiring/including a file is not idempotent because it’s just string concatenation because they are not modules. None of that should be a part of a modern language. If they haven’t fixed that in PHP 8, then it’s still broken.
There is an argument for judging programming languages based on the worst code possible within the language, due to the fact that with a wide enough ecosystem, you will regularly encounter lots of stuff in the median between that and your “just don’t do that” standard.
This is one of the reasons I love Go: the worst code possible in it is still pretty readable.
The worst code possible in PHP is scattered across thousands of files corresponding to individual routes, and isn’t indented at all.
But PHP makes it way too easy and provides few ways to guard against it. Well technically now it does with namespaces but that’s still less than ideal. And my point is that they are just now starting to catch up to more sane languages.
That’s a hack, not a solution. You still can’t import just class A out of A, B, and C that are all defined in the same file. And even if you require_once file x.php, you don’t have any guarantees that that file won’t require/include file y.php that you also intend to include. PHP files are treated as files, not modules and that’s fundamentally broken.
I guess you like modules. Someone else may like string inclusion, because it allows for some other forms of splitting the code that modules would not allow and fulfills the primary purpose of a PHP script, which is templating. Neither is fundamentally broken. You're just focusing on one aspect (organizing code), while ignoring the other.
Ah and there it is. PHP is fundamentally a templating system with a programming language built-in. Imagine using Handlebars.js to write your business logic.
I do think code organization is one of the primary jobs of a programming language/ecosystem. I want my tools to help me be better about that, not worse. Oh and given that most projects use a bunch of library code, I would very much prefer a system that has a consistent code organization pattern so I don’t have to guess how it all works. Take a look at the source code for something like WordPress or WooCommerce. These are mature projects. And yet it’s hard to shake the feeling that it’s all spaghetti inclusions.
> I do think code organization is one of the primary jobs of a programming language/ecosystem. I want my tools to help me be better about that, not worse.
Isn’t splitting up all your classes into separate files considered to be a good thing?
Considering how huge we can make files in JS I’m sort of inclined to consider that a problem instead of a feature.
I think any project that started around PHP 4/5 will look like Wordpress. Looking at more recent projects (after PSR’s became a thing) would be more representative.
It is but when you use third party code, what guarantees do you have that it didn’t do something stupid like declare a variable like $TIMEOUT? Whether on purpose or by accident. And of course any class or function become global even if you run include/require inside the body of a function or a method.
Include inside the body of an anonymous function if you care about toplevel $TIMEOUT=123 overriding some global variable.
Anyway you don't have any guarantees in JS either, for example. Imported module can just redefine Date object prototype or any global via globalThis. If you don't trust the libraries to not make a mess, don't use them is the only real solution. And it will be completely silent as opposed to PHP failing loudly when you try to redefine constant or class or function.
> When PHP was first released it was dramatically better than the alternatives for it's intended purpose.
I think that's going to depend to some degree on how you define that purpose. If it centers around having a low barrier to entry, then that's partly true, but some of the ways it achieved that involved making code written in it vulnerable to variable poisoning and SQL injection by default.
CGI didn't have register_globals, so yes on that count. I'm sure the quality of database access libraries varied, which is still a better situation than having a broken escape function built in to the language.
Well register_globals was a kind of uniquely php thing, but that's been gone for ages at this point. I generally agree though that lots of the hate for php is a bit over the top.
It is not possible to use language without documentation, should name include underscore? Where to put string? I've switched to ruby, it is predictable.
Mixed baggage of C, Perl, Java influences, no design. PHP 4 had design, PHP 5 made it total mess.
Borne shell good in gluing UNIX tools, AWK good in simple columnar data, PHP good in one page scripts.
When PHP was first released it was dramatically better than the alternatives for it's intended purpose.
There were plenty of things to complain about, but none of them stopped you from doing useful things with it. It was never slow or inefficient compared to other scripting languages, it didn't lack functionality.
Over the decades the most popular complaints have been addressed as the language has matured.
That it's remained in active development for 25 years with no signs of that changing in the future is one of it's biggest selling points.
I don't blame people for having issues with aspects of PHP based on their personal preferences and experiences, I get that, but that doesn't make it a 'bad' language.
There's nothing wrong with purist perspectives on what programming languages should be and how they should work. That contributes to better design.
But in the real world the questions are simpler: can this tool be used to develop applications quickly? Is it reasonably efficient at runtime (in this case in the context of scripting)? Can we easily find affordable developers in the future? Is there community support?
PHP checks the boxes that people building things want checked as well as any language and better than many. Unless I'm missing something, 'bad' here is more of a philosophical stance.