Not to take anything away from this post because PHP is a mess, but yesterday I dragged and dropped some PHP files onto a server with FileZilla, opened the right URL in a browser and it worked. No bundler, no docker, no kubernetes.
I also like the single-threaded, shared-nothing architecture that PHP inherited straight from the CGI days. Every request is guaranteed to start in a clean state. It's amazing that PHP 7 is as fast as it is even while sticking to the execution model of a shell script.
I wish I could run Python or JavaScript this way without losing too much performance.
It's almost 2019 and it's pretty amazing that no other language among the dozens available for web development feature easy server-side deployment.
It's frustrating and baffling for anyone who wants to provide users with an easy way to self-install or self-host.
Easy server deployment of apps simply doesn't exist (unless you're Wordpress with one-click installs available everywhere). Many developers consider easy deployment a non-issue.
Yeah, and that simplicity is also why systems like WordPress, Drupal, etc aren't going anywhere any time soon either. Yes they require an install process and a database setup, but compared to their newer competitors like Ghost, that's a lot more viable for someone with little computer experience than figuring out the command line or what not.
Like it or not, PHP and many applications written in it are more user friendly than many of their alternatives, which is worth a lot more to average Joes than security or code quality.
Unfortunately, the ease of deployment often means lower security. Lots of popular packages expect regular web user to be able to update source code (!), totally defeating any protection OS may provide: https://www.drupal.org/docs/7/install/step-4-run-the-install...
PHP is really nice and easy to deploy, and it would be my first choice for trivial one-file scripts, but I wish people did not use those simple deploy methods on the big internet. The net is not a nice place it used to be 10 years ago, and today, deploying scripts without any OS-based security protection is just irresponsible.
(And yes, it is possible to deploy PHP in the secure way with proper privilege separation, but most of the large, existing projects recommend doing it insecurely)
Well you could say that for anything that doesn't
a) Require 'compose' (as you say, no bundler) - so no dependency management (not ideal) or your code is so minimal it doesn't need any, which isn't the case for large projects
b) Require any infrastructure that's hosting the PHP app needing to be configured in the first place. That was conveniently overlooked. i.e. You don't even need to SFTP any files with something like Heroku or PaaS. It's an apples and oranges comparison imho
To me it's amazing how many of these things have been fixed in the last couple releases of PHP. They worked really hard to fix the flaws, and still there's more coming, like property types.
One thing I'm particular exited about is the "Preloading" RFC (https://wiki.php.net/rfc/preload), which fixes one of PHP's oldest weaknesses: That code that is used on every request has to be loaded everytime a request comes in. Sure, thanks to Opcache a file only has to be compiled once, but the loading of the compiled classes into memory still makes for some overhead. With Preloading, if you use a framework like Laravel or Symfony, all core framework classes could be loaded once on PHP startup.
> The point of private methods is to prevent what other code can call them. However, in PHP, you also cannot override private methods in a subclass. This is especially important when, for example, trying to build mocks in unit tests.
You may not be testing the right things if you have to override your methods just for your tests.
Yeah you shouldnt override any existing code when doing unit testing, only updating properties if anything... Otherwise you are taking the code beyond its scope, if you need output from a method to be something specific... Just set the variable you are storing that methods return value into to what you need that output to be.
To be honest, for a 23 year old language, that isn't a large list. With python 2vs3 I could write a book.
One issue:
"The point of private methods is to prevent what other code can call them. However, in PHP, you also cannot override private methods in a subclass. This is especially important when, for example, trying to build mocks in unit tests."
That is called "protected". With protected you can override the method. "private" means it is private to that class overriding - I believe this was concept was extracted from C++.
"In general, you don't want to break any encapsulation for the sake of testing (or as Mom used to say, "don't expose your privates!"). Most of the time, you should be able to test a class by exercising its public methods. If there is significant functionality that is hidden behind private or protected access, that might be a warning sign that there's another class in there struggling to get out."
For me the biggest stumbling block is always the inconsistency in the standard library of function calls.
Without an IDE, I'd be constantly looking up function names and parameter order.
Also, knowing which functions return a result and which modify a passed parameter is also problematic.
I wonder if a case couldn't be made for creating a new "standard library" that would operate alongside the existing one (for backwards compatibility).. A bit like mysql and mysqli....
Nowadays I do mainly PHP7.x / Symfony projects and of all this list I would say only "ternary operator associativity" could potentially be a day to day concern, and yes, empty() has gotchas.
Nothing listed is false, sure, and I'm sure there's people doing complicated things with clever code like "declaring a function called __lambda_func() (which) completely breaks create_function()" but I have not encountered it in the wild, or not for a long time.
Frankly I have more problems with Composer memory allocation in VM/containers than anything on this list.
Yeah, yeah, more PHP bashing. But PHP has very nicely cleaned up since oh 5.3 or so and with every release it's getting better. For example, to bemoan "Declaring a function called __lambda_func() completely breaks create_function()" completely ignores the fact noone should (or does) use create_function() since the introduction of proper closures. http://phpsadness.com/sad/2 is made up too, just use a constructor. There truly is no problem with PHP any more if properly used. Yeah we can rehash the arguments from the last twenty years but instead -- have you seen the language where the community and culture is so fractured someone could sneak in a bitcoin wallet stealer without anyone detecting it? The language which insists that the completely different concerns of backend and frontend development should be done in the same language? Now, that's what ridiculous!
Not sure if that's intentional, but take notice of how you're fighting for credibility for a language with bad reputation by comparing it to the one other language with similarly bad reputation :P
Generally speaking, if you expect the world to (as a first class principle) cater to your personal desires you will always be sad.
I didn't read the whole thing, but I'd be interested if anyone found any issue that doesn't have a workaround or can't be polyfilled to cater to this guy's expectations.
Edit: "reasonable" expectations. Requiring semicolon at end of line? smh Write your own editor plugin that inserts your semicolon (or write a preparser). PHP folks only wrote an entire language for the world to use for free. The least you could do (if it's really that big of a deal) is write a preparser.
Some of these are good points, but the error reporting ones are a bit pedantic.
Sure stuff like "T_PAAMAYIM_NEKUDOTAYIM" is confusing the first time you encounter it, but after your first week of PHP you're going to have seen it and know what it means. PHP has many flaws, but for me, error reporting isn't one of them.
I recommended Python with a math library to my friend to try as a replacement for R (and for server code running a project's backend data processing). The amount of effort and time spent trying to get it up and running was ridiculous.
R's syntax is very unpleasant for both of us, but it really gets the job done. Php isn't nearly as bad as R, and I've seen this kind of criticism of php for years.
What is the perfect language I should use then? Can't a list of "bad things" be made of any language? (maybe not the same problems, but there's always something)
It’s true that deployment is more difficult on Python.
Comparing R to PHP seems kind of inappropriate since what they are appropriate for rarely overlaps. I wouldn’t use PHP for statistics and I sure wouldn’t use R for a website.
As far as whether other languages could have similar criticism, no. This is an analysis of sloppy design at the core of PHP. The types of problems listed aren’t found in Python or Ruby because they planned the language better in the first place and have a better process for dealing with intelligent changes. It’s maddening for me to read what PHP developers think about changes to the language. If you want to use PHP, go ahead, but I don’t think that’s the point of this article.
Well to be fair, R has always had a good installation story (and CRAN is super-stable), while Python is notorious for issues with packaging (easy_install, pip etc).
The saddest part is that there is so much PHP code out there and it's mostly really bad code. Even Rasmus isn't happy about it, you can watch his presentations on state of PHP on youtube. PHP was meant to be a simple templating language for HTML, and it failed miserably at that, which is why almost every PHP framework out there invents another one.
>PHP was meant to be a simple templating language for HTML, and it failed miserably at that
I would argue that it was too good at that, instead. It was so good at being a real language that people didn't just use it as a templating language and it grew way, way bigger than initially intended.
When I see PHP templating libraries, they are all focused on restricting the programmer from doing supposedly stupid things. They try to prevent logic from leaking into the templates and utterly fail at it.
I used to be in contact with a licensed/bought piece of software written in C++, PHP and Perl, using Mongodb as a database. It was about as much fun as it sounds. Segfaulted twice a week.
I suppose at some point they'll make a plug-in system written in brainfuck.
One that was missed is the change in the way that the count function operates on a null value, its breaking backwards compatibility.
The only way to solve it is to write your own count function and call it everywhere instead.
Another problem is, if for example you are checking for a url variable to see if it exists, there's more than one way to do it - and only one of those ways is performant. Why have a special function that checks if a key exists when its slower than just checking if the entire variable exists?
I've since moved on to C++ and go, but the ubiquity of php on web hosting will bring me back to it again.
One can sort out a lot of PHP parameter order inconsistencies remembering that if $haystack is an array then it's the second parameter after $needle. For string it's the opposite.
You're probably thinking of in_array() and strpos(). Yeah, the names themselves are confusing, not just the order of arguments.
I wish PHP was fully object-oriented so you could call a method on any array, string, or number like in JavaScript. $haystack->contains($needle) is so much more consistent! That would eliminate the need for most of those confusing global functions, which can then be safely deprecated.
[+] [-] skrebbel|7 years ago|reply
That was some PHP Happiness right there.
[+] [-] kijin|7 years ago|reply
I wish I could run Python or JavaScript this way without losing too much performance.
[+] [-] open-source-ux|7 years ago|reply
It's frustrating and baffling for anyone who wants to provide users with an easy way to self-install or self-host.
Easy server deployment of apps simply doesn't exist (unless you're Wordpress with one-click installs available everywhere). Many developers consider easy deployment a non-issue.
Here's a previous question I asked on the topic:
https://news.ycombinator.com/item?id=14781420
[+] [-] CM30|7 years ago|reply
Like it or not, PHP and many applications written in it are more user friendly than many of their alternatives, which is worth a lot more to average Joes than security or code quality.
[+] [-] theamk|7 years ago|reply
PHP is really nice and easy to deploy, and it would be my first choice for trivial one-file scripts, but I wish people did not use those simple deploy methods on the big internet. The net is not a nice place it used to be 10 years ago, and today, deploying scripts without any OS-based security protection is just irresponsible.
(And yes, it is possible to deploy PHP in the secure way with proper privilege separation, but most of the large, existing projects recommend doing it insecurely)
[+] [-] code_duck|7 years ago|reply
[+] [-] GrumpyNl|7 years ago|reply
[+] [-] newaccoutnas|7 years ago|reply
[+] [-] hochchristoph|7 years ago|reply
One thing I'm particular exited about is the "Preloading" RFC (https://wiki.php.net/rfc/preload), which fixes one of PHP's oldest weaknesses: That code that is used on every request has to be loaded everytime a request comes in. Sure, thanks to Opcache a file only has to be compiled once, but the loading of the compiled classes into memory still makes for some overhead. With Preloading, if you use a framework like Laravel or Symfony, all core framework classes could be loaded once on PHP startup.
[+] [-] arkh|7 years ago|reply
You may not be testing the right things if you have to override your methods just for your tests.
[+] [-] josteink|7 years ago|reply
If you need derives classes-only to have access, you should typically use the “protected”-modifier.
Doesn’t php have that?
[+] [-] wnevets|7 years ago|reply
[+] [-] giancarlostoro|7 years ago|reply
[+] [-] ransom1538|7 years ago|reply
One issue:
"The point of private methods is to prevent what other code can call them. However, in PHP, you also cannot override private methods in a subclass. This is especially important when, for example, trying to build mocks in unit tests."
That is called "protected". With protected you can override the method. "private" means it is private to that class overriding - I believe this was concept was extracted from C++.
"In general, you don't want to break any encapsulation for the sake of testing (or as Mom used to say, "don't expose your privates!"). Most of the time, you should be able to test a class by exercising its public methods. If there is significant functionality that is hidden behind private or protected access, that might be a warning sign that there's another class in there struggling to get out."
[+] [-] mrunkel|7 years ago|reply
Without an IDE, I'd be constantly looking up function names and parameter order.
Also, knowing which functions return a result and which modify a passed parameter is also problematic.
I wonder if a case couldn't be made for creating a new "standard library" that would operate alongside the existing one (for backwards compatibility).. A bit like mysql and mysqli....
[+] [-] TheAceOfHearts|7 years ago|reply
[0] http://news.php.net/php.internals/70691
[+] [-] conradfr|7 years ago|reply
[+] [-] PunchTornado|7 years ago|reply
The same can be said about Java, nobody would write all that glutter without an IDE...
[+] [-] conradfr|7 years ago|reply
Nothing listed is false, sure, and I'm sure there's people doing complicated things with clever code like "declaring a function called __lambda_func() (which) completely breaks create_function()" but I have not encountered it in the wild, or not for a long time.
Frankly I have more problems with Composer memory allocation in VM/containers than anything on this list.
[+] [-] chx|7 years ago|reply
[+] [-] seba_dos1|7 years ago|reply
[+] [-] perpetualcrayon|7 years ago|reply
I didn't read the whole thing, but I'd be interested if anyone found any issue that doesn't have a workaround or can't be polyfilled to cater to this guy's expectations.
Edit: "reasonable" expectations. Requiring semicolon at end of line? smh Write your own editor plugin that inserts your semicolon (or write a preparser). PHP folks only wrote an entire language for the world to use for free. The least you could do (if it's really that big of a deal) is write a preparser.
[+] [-] invalidusernam3|7 years ago|reply
Sure stuff like "T_PAAMAYIM_NEKUDOTAYIM" is confusing the first time you encounter it, but after your first week of PHP you're going to have seen it and know what it means. PHP has many flaws, but for me, error reporting isn't one of them.
[+] [-] johannes1234321|7 years ago|reply
[+] [-] alphadevx|7 years ago|reply
[+] [-] Vanderson|7 years ago|reply
R's syntax is very unpleasant for both of us, but it really gets the job done. Php isn't nearly as bad as R, and I've seen this kind of criticism of php for years.
What is the perfect language I should use then? Can't a list of "bad things" be made of any language? (maybe not the same problems, but there's always something)
[+] [-] code_duck|7 years ago|reply
Comparing R to PHP seems kind of inappropriate since what they are appropriate for rarely overlaps. I wouldn’t use PHP for statistics and I sure wouldn’t use R for a website.
As far as whether other languages could have similar criticism, no. This is an analysis of sloppy design at the core of PHP. The types of problems listed aren’t found in Python or Ruby because they planned the language better in the first place and have a better process for dealing with intelligent changes. It’s maddening for me to read what PHP developers think about changes to the language. If you want to use PHP, go ahead, but I don’t think that’s the point of this article.
[+] [-] disgruntledphd2|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] dsego|7 years ago|reply
[+] [-] wccrawford|7 years ago|reply
I would argue that it was too good at that, instead. It was so good at being a real language that people didn't just use it as a templating language and it grew way, way bigger than initially intended.
When I see PHP templating libraries, they are all focused on restricting the programmer from doing supposedly stupid things. They try to prevent logic from leaking into the templates and utterly fail at it.
[+] [-] tormeh|7 years ago|reply
I suppose at some point they'll make a plug-in system written in brainfuck.
[+] [-] dana321|7 years ago|reply
The only way to solve it is to write your own count function and call it everywhere instead.
Another problem is, if for example you are checking for a url variable to see if it exists, there's more than one way to do it - and only one of those ways is performant. Why have a special function that checks if a key exists when its slower than just checking if the entire variable exists?
I've since moved on to C++ and go, but the ubiquity of php on web hosting will bring me back to it again.
[+] [-] hansott|7 years ago|reply
[+] [-] z92|7 years ago|reply
[+] [-] kijin|7 years ago|reply
I wish PHP was fully object-oriented so you could call a method on any array, string, or number like in JavaScript. $haystack->contains($needle) is so much more consistent! That would eliminate the need for most of those confusing global functions, which can then be safely deprecated.
[+] [-] mykeels|7 years ago|reply
[+] [-] stesch|7 years ago|reply
He even took the time tagging which sad points are solved in newer versions.
[+] [-] kraag22|7 years ago|reply
[+] [-] dsego|7 years ago|reply
[+] [-] bufferoverflow|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] buboard|7 years ago|reply