Having been in and since “passed out” of the PHP ecosystem (and admittedly, the last version I used was now 7.2), I found that my biggest productivity and quality of life issues with PHP lie in an area which is difficult to reform - its standard library.
PHP has a very nice documentation of it’s standard library - and that’s great, because you need to consult it frequently. There’s so much power there, but a lot of it is hard to wield.
Everything exists in the ‘prelude’. There’s no real organisation or filtering of the functions the runtime provides except for extensions, which are at least compartmentalised in the documentation, but still exist in one flat namespace. PHP does have namespaces, but they are really provided for the sake of user defined code and the runtime makes little (no?) use of them.
There’s a real usability issue which has arisen from the through-line of the original PHP language, which represented almost a shell script over C libraries, to the modern language, which means that the built-in functions tend to very closely resemble C counterparts in a way that often doesn’t make much sense or feels unwieldy, which has a few knock-on effects:
PHP has a system for “reference variables” which basically makes them permanently pass-by-reference when passed to functions; this is an inherent property of the binding and (as of 7.2 at least) you can never remove this property from a binding, and you can never tell if a variable is a reference or not. It seems this was largely implemented to mimic how C achieves mutating and returning non-trivial values, but it’s not always clear that careful thought went into whether other mechanisms in PHP are more suited.
Finding or remembering functions you want for common operations can be difficult because they use the difficult to interrogate names of their C peers (particularly for strings), and not just ones like strftime which at least will be familiar from a few other languages - strtr, strstr, strpbrk, ftell, may be unfamiliar and unintuitive even if you are a trained programmer coming from another language.
The requirements of binding native functions mean that pre-7.0, these functions were the only place where typing enforcement would pop up, which is part of the reason that so many sites with poor configuration would spew massive amounts of PHP warnings.
The additions that PHP has made in these areas over the years have many consistency issues in the design and conventions of the functions (inconsistent ordering of items and collections in the arguments to collection operations, inconsistent use of _ to break up function names, mixing ‘2’ and ‘to’, having a separate camelCase naming convention for object methods)
It’s been more than a decade since I last dabbled with PHP and your criticisms match my memory. I wonder why they don’t add proper modules/namespaces to the standard library while leaving the old APIs in place for compatibility reasons. Push the new APIs as the way forward via culture and linters (using old APIs is a lint error and maybe eventually a glaring deprecation warning in the runtime).
This is hilarious because it has been a quarter of a century since PHP took the web by storm, and people still don’t get it. The reason can be summed up in one word. The long lost ancient engineering art of : Pragmatism.
Every 3 months or so, out comes an article claiming that the dark days of procedural PHP with its mysql_ functions on the main scope are gone. And that now it’s all symphony/laravel/whatever. No ofense to whomever writes these, I am sure they truly believe what they write. But this as misguided as it can get.
PHP nailed dynamic web pages challenge with such effectiveness that we can still observe the shockwave of it impact. Wanted a guestbook? No problem. A simple forum? A comment system? A simple order system for your videoclub? A simple way to share your game scores online?
Notice the repetitive use of the the word simple. Drop a php script on this folder, visit the url containing its path + server name, there you go, you were all set. From that point on your had templating, relational-database access, string manipulation, regex, an HTTP parser, a library of common data structures at your finger tips.
There was nothing like it. Not even close. It was so much simpler than anything else, that its rise was just metheoric. People forget what a PITA it was to actually serve HTTP reliably in other languages. It certainly is painless today, but it wasn’t so up to the mid-2000s. Before PHP, people used perl CGI scripts. But perl is arguably a much trickier language to use and learn. PHP add the array() constructor that would provide you with a list, a queue, a map, an array, a tree etc. And HTTP parsing was built right into the language. And it even had a high level cookie based session api that would just work. And a much more robust deploy model. And better performance.
All these examples keep show code that mimics java code, this is so silly. Heck by the time PHP was pulverizing the competition, Java didn’t even had support for generics. This meant that you would get the worse fromofboth worlds: lots of verbosity and no type safety whatsoever on any sort of data structure.
We see it in the article and already in sibling comments, people pointing out small details. Parameter order and function naming inconsistencies, syntax warts, type juggling, etc. None of those matter. Any good programmer will learn the language and use it reasonably/defensively enough to be completely undisturbed by such insignificances. What matters is what the language can do and how effectively.
I think the real limitations are things like lack of standard general purpose language execution mode rather than still just embracing usage in the context of HTTP requests. Lack of official support for basic concurrency primitives and constructs such as threads, processes, semaphores, etc. Or lack of proper data structures. As handy as its ‘arrays’ are, they are not really suited for anything other than a couple of kilobytes of data.
The whole creation of a package register, and dependency injection as primary way of loading code, are ultimately useless gimmicks. People were perfectly fine with downloading a source and include it as a library. It was never intended to be sexy, fancy or corporate. It just solved a problem.
I don’t have so much use for it anymore. Writing an HTTP service in, say python, is trivial these days.From that point on, PHP doesn’t offer me any advantage. Unless of course, there is existing PHP code I can re-use. Which is what is happening to me in the project I am currently working on.
Some food for thought: is python todays PHP of general programming?
It wasn’t only that it was simple; it was cheap because it supported shared hosting. When your page wasn’t receiving traffic, it only consumed disk space.
In the early-mid 2000s I wanted to run some basic pages. Shared-hosting for PHP was several hundred times cheaper per month than getting a box to host perl (not a typo).
When your page wasn’t receiving traffic, it only consumed disk space.
This was also true of CGI scripts. The real cost difference was when they were in use. Apache mod_php ran in-process and ran the PHP interpreter with your script much more cheaply than spawning a new process to run the CGI program and it came with resource limits so that it could easily kill a PHP script that ran too long or used too much memory (you could do this with rlimits with CGI, but it was more setup - mod_php had mostly sane defaults).
This advantage went away once people realised what an unmitigated security disaster it was. Any script run by mod_php ran as the Apache user and so could read any file Apache could read, including the .php files containing database passwords in other users’ home directories. It was trivial to write a PHP script that would dump every other user’s PHP files from the same system back in those days but by the time anyone cared PHP was entrenched and computers were fast enough that running PHP in FastCGI mode with one process per user (which could be started on demand and killed after some inactivity) was not too much overhead.
True. Another notorious group of users were universities teachers and students. Most universities would install apache and enable user directories. Many teachers would have a script to list grades for example, or a minimal CMS to manage upcoming lectures notes and the like. It was a simple matter of droping a php file in ~/public_html
I think my thoughts on PHP retroactively are: PHP kind of successfully reproduced the sort of mass market availability of programming as an accessible and useful product that BASIC saw in the 80s on home micros for the web, which is really quite an important and potentially useful. In fact, having grown up after the home micro revolution, it’s really how I got my start in programming when programming a Windows computer felt complicated and inaccessible.
However, it quickly became apparent that the nature of the web, particularly around access and trust, is so markedly different to the model of “it’s your computer and you’re writing and running code just for you”. PHP generally embraced insecurity for good ease of use, and it very quickly turned out to be a quite bad mistake. People had to learn the hard way that not everyone on the internet is friendly, and that not understanding what your code really did or how the web really work makes it very difficult to defend against unfriendly parties.
I’m not saying PHP is Satan… but there’s nothing that it can do that you can’t do better, faster, and more maintainably in another language. And that “your app gets initialized and torn down for every request” starts to become a real pain when you do anything at scale (we push 20k RPS through PHP. The amount of wastage is saddening.)
Well it’s certainly not PHP’s fault if people are actively averse to learning how to properly use it.
It’s been a while, but even 10 years ago we would have never accepted someone saying “well 0 and 0 are somehow equal” like one person in the moved bug tracker link does. It’s either a string or an int, otherwise it’s a bug. Just because the language is not strongly typed that doesn’t mean you shouldn’t know with what you’re working inside your application (and not where any input enters the system).
Backwards Compatibility. The thing that everyone outside PHP decries so much - e.g. fixing all the needle/haystack and 90% of other “oh if only it were different” things. Because old PHP code is actually really easy to run on modern versions.
I honestly don’t have a horse in this race. But even just at a glance I don’t think it’s an “outsider” vs. “insider” matter. It doesn’t have to be so partisan. Both have upsides & downsides.
It would be nice, for instance, if there were an option like PHP, but with a balance between BC and solid interface design. Maybe Python or Go represent this, who knows.
I’m open to other perspectives, but my point is as follows: a decent interface doesn’t have to be made great, but a trashfire interface should definitely be made at least decent before it’s “frozen”.
I think that’s a valid standpoint, but there’s a reason people today usually make a big fuzz about a 1.0 release from which point on it’s declared stable/non-breaking.
But if we ignore PHP 1+2 and only look at 4.0 which was released in May 2000 - that’s when the “we don’t break BC” decision was made and it’s been held up since. So that’s why I think “they should’ve” is not so helpful. They didn’t and there are always good reasons for and against.
In case you’re not so familiar with the history, there historically was a huge problem of getting the web hosts to upgrade DESPITE the massive efforts to keep BC. IIRC on August 8th 2008 there was a huge effort to promote this deadline (4.4.9 was the last PHP 4 version that was released) to get the people to finally move to PHP5, which was released 4 years earlier in summer 2004 and AGAIN so many people didn’t upgrade (webhosts and wordpress was a big factor here).
I personally would also agree that there was a point (maybe 7.0) where it should’ve been done, but on the other hand I am personally guilty of being one of the people going “our dependency libraries are not available for Python 3, let’s start this massive new project in Python 2 in the year 2014”.
I think there are two primary reasons to learn and use a language, library, paradigm, etc.
The first and most common is that it’s where the job market is. This might be why one chooses to learn JavaScript for example, particularly early in their career. Anecdotally, PHP roles in my city seem to be just about the worst paying, and if memory serves the Stack Overflow survey backs this up.
The second is for enjoyment and/or intellectual intrigue. I don’t think this can apply to such a middle of the road, thoroughly mainstream language, though perhaps I’m wrong.
I don’t mean to be rude to anyone who does like PHP by the way, I’d just advise against learning it in favour of almost any alternative for either of the above reasons.
As someone who doesn’t know PHP, I have noticed that open source self-hostable projects that are written in PHP always seem to be the simplest to setup and run. That is always something that has made me want to get into PHP. Does anyone why so many PHP projects are so easy to host?
PHP traditionally doesn’t use application servers, but instead the CGI model (occasionally aided by either FPM/FastCGI style things or mod_php), so everything is stateless, and easy to just FTP to your shared host. Now that VPSes and Lambda-style things have outstripped shared hosts combined with the rise of Docker, the benefit of the CGI model for deployment is a lot less.
I wouldn’t quite say that PHP things are stateless, more that their state is external. In my experience this makes them harder to deploy than the alternatives because they pull in a dependency on a database server being configured to hold the state (with shared hosting, there was typically a MySQL instance, a PostgreSQL instance if you were lucky, configured and shared between all users so the effort was amortised). This has some nice properties with respect to scaling (the database is a bottleneck, the front end might not be, and it’s generally easier to scale up a database until you start being the size of Twitter than it is to rewrite the front end in a scalable way).
FaaS things are closer to the PHP model: the state is stored in something else (typically Cosmos DB on Azure, not sure what the AWS equivalent is), so the front end can scale up as much as it needs to and someone else is responsible for scaling the back end.
Working in an office full of PHP devs as a non-PHP dev, it seems just as fine as any other language for writing a web application After all, most of the stuff you’ll do with PHP is just patterns you can write in any language. But then again, working in an office full of PHP devs, hearing about the features they’re excited for really discourages me from wanting to start a new project in PHP,, like the language is playing catchup. It just sounds easier in 2021 to use Python with Flask or such to get something up fast, Elixir to get something written safely, or (sigh) Go, to do both of those things.
IMHO the best thing about the PHP ecosystem is that you have a large variety of hosting providers that will do your PHP hosting, and due to PHPs nature it is very easy to switch providers, should you be unhappy, …
In practice I’ve found the opposite to be true (sometimes). PHP’s “just copy those files, Yolo” means the dependencies story is still rather poor. Want some db client? You need to find hosting which has that extension installed/enabled. Same for caching / opcode speedups. Same for format parsers. Maybe you get cPanel where you can install some of them, but it’s very rarely code driven. If you have pure-php code, it’s easier.
In comparison ruby / node / even python have an easy way to install those at deploy time in most PaaS environments.
There was that one particular feature of the language that impressed me back then and that was the day I acknowledged the flexibility of the PHP language, you can create an instance of a class and call a static method using an array!
<?php
class Foo {
public static function run($message) {
print($message);
}
}
["Foo", "run"]("BAR");
For anybody as bewildered as I was (and still am), this is not some bizarre artifact of PHP implicit type conversions or weird object system; the “Callable array” syntax was explicitly introduced as a way of dynamically invoking static methods.
You’re correct, this is a static method invocation. But this convention does also work for instance methods if you supply an object in the first array item instead of the class name.
Having been in and since “passed out” of the PHP ecosystem (and admittedly, the last version I used was now 7.2), I found that my biggest productivity and quality of life issues with PHP lie in an area which is difficult to reform - its standard library.
PHP has a very nice documentation of it’s standard library - and that’s great, because you need to consult it frequently. There’s so much power there, but a lot of it is hard to wield.
Everything exists in the ‘prelude’. There’s no real organisation or filtering of the functions the runtime provides except for extensions, which are at least compartmentalised in the documentation, but still exist in one flat namespace. PHP does have namespaces, but they are really provided for the sake of user defined code and the runtime makes little (no?) use of them.
There’s a real usability issue which has arisen from the through-line of the original PHP language, which represented almost a shell script over C libraries, to the modern language, which means that the built-in functions tend to very closely resemble C counterparts in a way that often doesn’t make much sense or feels unwieldy, which has a few knock-on effects:
PHP has a system for “reference variables” which basically makes them permanently pass-by-reference when passed to functions; this is an inherent property of the binding and (as of 7.2 at least) you can never remove this property from a binding, and you can never tell if a variable is a reference or not. It seems this was largely implemented to mimic how C achieves mutating and returning non-trivial values, but it’s not always clear that careful thought went into whether other mechanisms in PHP are more suited.
Finding or remembering functions you want for common operations can be difficult because they use the difficult to interrogate names of their C peers (particularly for strings), and not just ones like
strftimewhich at least will be familiar from a few other languages -strtr,strstr,strpbrk,ftell, may be unfamiliar and unintuitive even if you are a trained programmer coming from another language.The requirements of binding native functions mean that pre-7.0, these functions were the only place where typing enforcement would pop up, which is part of the reason that so many sites with poor configuration would spew massive amounts of PHP warnings.
The additions that PHP has made in these areas over the years have many consistency issues in the design and conventions of the functions (inconsistent ordering of items and collections in the arguments to collection operations, inconsistent use of
_to break up function names, mixing ‘2’ and ‘to’, having a separate camelCase naming convention for object methods)It’s been more than a decade since I last dabbled with PHP and your criticisms match my memory. I wonder why they don’t add proper modules/namespaces to the standard library while leaving the old APIs in place for compatibility reasons. Push the new APIs as the way forward via culture and linters (using old APIs is a lint error and maybe eventually a glaring deprecation warning in the runtime).
It’s going to happen for 8.1, albeit slowly.
One big issue with PHP is the whole “needle/haystack” argument order mess.
This is hilarious because it has been a quarter of a century since PHP took the web by storm, and people still don’t get it. The reason can be summed up in one word. The long lost ancient engineering art of : Pragmatism.
Every 3 months or so, out comes an article claiming that the dark days of procedural PHP with its mysql_ functions on the main scope are gone. And that now it’s all symphony/laravel/whatever. No ofense to whomever writes these, I am sure they truly believe what they write. But this as misguided as it can get.
PHP nailed dynamic web pages challenge with such effectiveness that we can still observe the shockwave of it impact. Wanted a guestbook? No problem. A simple forum? A comment system? A simple order system for your videoclub? A simple way to share your game scores online? Notice the repetitive use of the the word simple. Drop a php script on this folder, visit the url containing its path + server name, there you go, you were all set. From that point on your had templating, relational-database access, string manipulation, regex, an HTTP parser, a library of common data structures at your finger tips.
There was nothing like it. Not even close. It was so much simpler than anything else, that its rise was just metheoric. People forget what a PITA it was to actually serve HTTP reliably in other languages. It certainly is painless today, but it wasn’t so up to the mid-2000s. Before PHP, people used perl CGI scripts. But perl is arguably a much trickier language to use and learn. PHP add the array() constructor that would provide you with a list, a queue, a map, an array, a tree etc. And HTTP parsing was built right into the language. And it even had a high level cookie based session api that would just work. And a much more robust deploy model. And better performance. All these examples keep show code that mimics java code, this is so silly. Heck by the time PHP was pulverizing the competition, Java didn’t even had support for generics. This meant that you would get the worse fromofboth worlds: lots of verbosity and no type safety whatsoever on any sort of data structure.
We see it in the article and already in sibling comments, people pointing out small details. Parameter order and function naming inconsistencies, syntax warts, type juggling, etc. None of those matter. Any good programmer will learn the language and use it reasonably/defensively enough to be completely undisturbed by such insignificances. What matters is what the language can do and how effectively.
I think the real limitations are things like lack of standard general purpose language execution mode rather than still just embracing usage in the context of HTTP requests. Lack of official support for basic concurrency primitives and constructs such as threads, processes, semaphores, etc. Or lack of proper data structures. As handy as its ‘arrays’ are, they are not really suited for anything other than a couple of kilobytes of data.
The whole creation of a package register, and dependency injection as primary way of loading code, are ultimately useless gimmicks. People were perfectly fine with downloading a source and include it as a library. It was never intended to be sexy, fancy or corporate. It just solved a problem.
I don’t have so much use for it anymore. Writing an HTTP service in, say python, is trivial these days.From that point on, PHP doesn’t offer me any advantage. Unless of course, there is existing PHP code I can re-use. Which is what is happening to me in the project I am currently working on.
Some food for thought: is python todays PHP of general programming?
It wasn’t only that it was simple; it was cheap because it supported shared hosting. When your page wasn’t receiving traffic, it only consumed disk space.
In the early-mid 2000s I wanted to run some basic pages. Shared-hosting for PHP was several hundred times cheaper per month than getting a box to host perl (not a typo).
This was also true of CGI scripts. The real cost difference was when they were in use. Apache
mod_phpran in-process and ran the PHP interpreter with your script much more cheaply than spawning a new process to run the CGI program and it came with resource limits so that it could easily kill a PHP script that ran too long or used too much memory (you could do this with rlimits with CGI, but it was more setup -mod_phphad mostly sane defaults).This advantage went away once people realised what an unmitigated security disaster it was. Any script run by
mod_phpran as the Apache user and so could read any file Apache could read, including the .php files containing database passwords in other users’ home directories. It was trivial to write a PHP script that would dump every other user’s PHP files from the same system back in those days but by the time anyone cared PHP was entrenched and computers were fast enough that running PHP in FastCGI mode with one process per user (which could be started on demand and killed after some inactivity) was not too much overhead.True. Another notorious group of users were universities teachers and students. Most universities would install apache and enable user directories. Many teachers would have a script to list grades for example, or a minimal CMS to manage upcoming lectures notes and the like. It was a simple matter of droping a php file in ~/public_html
I think my thoughts on PHP retroactively are: PHP kind of successfully reproduced the sort of mass market availability of programming as an accessible and useful product that BASIC saw in the 80s on home micros for the web, which is really quite an important and potentially useful. In fact, having grown up after the home micro revolution, it’s really how I got my start in programming when programming a Windows computer felt complicated and inaccessible.
However, it quickly became apparent that the nature of the web, particularly around access and trust, is so markedly different to the model of “it’s your computer and you’re writing and running code just for you”. PHP generally embraced insecurity for good ease of use, and it very quickly turned out to be a quite bad mistake. People had to learn the hard way that not everyone on the internet is friendly, and that not understanding what your code really did or how the web really work makes it very difficult to defend against unfriendly parties.
I’m not saying PHP is Satan… but there’s nothing that it can do that you can’t do better, faster, and more maintainably in another language. And that “your app gets initialized and torn down for every request” starts to become a real pain when you do anything at scale (we push 20k RPS through PHP. The amount of wastage is saddening.)
As far as I know “0e4” == “0e5” us still true
Confirmed:
This is a case where you need the dreaded
===(which should be defacto default for most devs these days anyways)I tries to explain the problem to lavarel dev and did not succed to explain the problem see https://github.com/laravel/framework/issues/20141
Well it’s certainly not PHP’s fault if people are actively averse to learning how to properly use it.
It’s been a while, but even 10 years ago we would have never accepted someone saying “well
0and 0 are somehow equal” like one person in the moved bug tracker link does. It’s either a string or an int, otherwise it’s a bug. Just because the language is not strongly typed that doesn’t mean you shouldn’t know with what you’re working inside your application (and not where any input enters the system).Oh wow, did not expect people to not use strict comparisons.
And it will never be changed, which is a good thing if you value BC.
I mean that == should be deprecated somehow. with a big enough warning
BC?
Backwards compatibility.
Backwards Compatibility. The thing that everyone outside PHP decries so much - e.g. fixing all the needle/haystack and 90% of other “oh if only it were different” things. Because old PHP code is actually really easy to run on modern versions.
I honestly don’t have a horse in this race. But even just at a glance I don’t think it’s an “outsider” vs. “insider” matter. It doesn’t have to be so partisan. Both have upsides & downsides.
It would be nice, for instance, if there were an option like PHP, but with a balance between BC and solid interface design. Maybe Python or Go represent this, who knows.
I’m open to other perspectives, but my point is as follows: a decent interface doesn’t have to be made great, but a trashfire interface should definitely be made at least decent before it’s “frozen”.
I think that’s a valid standpoint, but there’s a reason people today usually make a big fuzz about a 1.0 release from which point on it’s declared stable/non-breaking.
But if we ignore PHP 1+2 and only look at 4.0 which was released in May 2000 - that’s when the “we don’t break BC” decision was made and it’s been held up since. So that’s why I think “they should’ve” is not so helpful. They didn’t and there are always good reasons for and against.
In case you’re not so familiar with the history, there historically was a huge problem of getting the web hosts to upgrade DESPITE the massive efforts to keep BC. IIRC on August 8th 2008 there was a huge effort to promote this deadline (4.4.9 was the last PHP 4 version that was released) to get the people to finally move to PHP5, which was released 4 years earlier in summer 2004 and AGAIN so many people didn’t upgrade (webhosts and wordpress was a big factor here).
I personally would also agree that there was a point (maybe 7.0) where it should’ve been done, but on the other hand I am personally guilty of being one of the people going “our dependency libraries are not available for Python 3, let’s start this massive new project in Python 2 in the year 2014”.
I think there are two primary reasons to learn and use a language, library, paradigm, etc.
The first and most common is that it’s where the job market is. This might be why one chooses to learn JavaScript for example, particularly early in their career. Anecdotally, PHP roles in my city seem to be just about the worst paying, and if memory serves the Stack Overflow survey backs this up.
The second is for enjoyment and/or intellectual intrigue. I don’t think this can apply to such a middle of the road, thoroughly mainstream language, though perhaps I’m wrong.
I don’t mean to be rude to anyone who does like PHP by the way, I’d just advise against learning it in favour of almost any alternative for either of the above reasons.
As someone who doesn’t know PHP, I have noticed that open source self-hostable projects that are written in PHP always seem to be the simplest to setup and run. That is always something that has made me want to get into PHP. Does anyone why so many PHP projects are so easy to host?
PHP traditionally doesn’t use application servers, but instead the CGI model (occasionally aided by either FPM/FastCGI style things or mod_php), so everything is stateless, and easy to just FTP to your shared host. Now that VPSes and Lambda-style things have outstripped shared hosts combined with the rise of Docker, the benefit of the CGI model for deployment is a lot less.
I wouldn’t quite say that PHP things are stateless, more that their state is external. In my experience this makes them harder to deploy than the alternatives because they pull in a dependency on a database server being configured to hold the state (with shared hosting, there was typically a MySQL instance, a PostgreSQL instance if you were lucky, configured and shared between all users so the effort was amortised). This has some nice properties with respect to scaling (the database is a bottleneck, the front end might not be, and it’s generally easier to scale up a database until you start being the size of Twitter than it is to rewrite the front end in a scalable way).
FaaS things are closer to the PHP model: the state is stored in something else (typically Cosmos DB on Azure, not sure what the AWS equivalent is), so the front end can scale up as much as it needs to and someone else is responsible for scaling the back end.
Working in an office full of PHP devs as a non-PHP dev, it seems just as fine as any other language for writing a web application After all, most of the stuff you’ll do with PHP is just patterns you can write in any language. But then again, working in an office full of PHP devs, hearing about the features they’re excited for really discourages me from wanting to start a new project in PHP,, like the language is playing catchup. It just sounds easier in 2021 to use Python with Flask or such to get something up fast, Elixir to get something written safely, or (sigh) Go, to do both of those things.
Wow. This article is spot on on the need to expose new features of the languages to those whose knowledge about it is outdated.
I stopped touching PHP more than 15 years ago, maybe 20, and… boy did it change!
Brings back memories from my youth… https://bugs.php.net/bug.php?id=38128
“Hey fellas, you’ve added the array type hint. That’s cool. Why can’t I hint the opposite?”
“There is no need to do that.”
15 years pass…
“We bring you scalar type hints and union types! PHP is great!”
IMHO the best thing about the PHP ecosystem is that you have a large variety of hosting providers that will do your PHP hosting, and due to PHPs nature it is very easy to switch providers, should you be unhappy, …
In practice I’ve found the opposite to be true (sometimes). PHP’s “just copy those files, Yolo” means the dependencies story is still rather poor. Want some db client? You need to find hosting which has that extension installed/enabled. Same for caching / opcode speedups. Same for format parsers. Maybe you get cPanel where you can install some of them, but it’s very rarely code driven. If you have pure-php code, it’s easier.
In comparison ruby / node / even python have an easy way to install those at deploy time in most PaaS environments.
There was that one particular feature of the language that impressed me back then and that was the day I acknowledged the flexibility of the PHP language, you can create an instance of a class and call a static method using an array!
For anybody as bewildered as I was (and still am), this is not some bizarre artifact of PHP implicit type conversions or weird object system; the “Callable array” syntax was explicitly introduced as a way of dynamically invoking static methods.
In 8.1, releasing next week, there’s finally first-class callable supports, so strings and arrays aren’t necessary. https://wiki.php.net/rfc/first_class_callable_syntax
Static methods don’t require instantiation. Are you sure instantiation is happening here?
Also, wouldn’t it be better to be able to write something like
Foo.run("BAR")?You’re correct, this is a static method invocation. But this convention does also work for instance methods if you supply an object in the first array item instead of the class name.
[Comment removed by moderator pushcx: Don’t post dismissive insults. ]