A lot of the problems in PHP are really fundamental without easy fixes, not without the “Python 3 of PHP”. Slapping on a few features and syntax sugar is nice and all, but it won’t fix any of that.
There are still countless “wtf?!“s left. There is no easy fix for this, but PHP’s stdlib is a complete mess and liability.
I don’t strictly disagree you can write good software with it, but on the other hand a lot of things are also much harder than they need to be. A certain subset of problems is impossible to solve. For example, a function to generate a temporary name with a fixed file extension (fooXXXXXXX.html) is impossible to implement in a guaranteed race-free way as far as I know (solving this problem inspired my fopen() post above; but I’ll gladly be shown wrong on this).
Of course, it’s “probably good enough”, but why settle for that when you can have “guaranteed correct” with literally every other mainstream language?
The value of PHP was in that it ran really well on shared hosting, and I think it was a stroke of great insight back in the day. Things that are “wtf”s now – like the php.ini – made a lot of sense in that context, too, but now we’re stuck with it. I don’t see the value PHP gives us. I don’t want to tell other people what language they “should” be using, but it just seems like a sunk-cost thing to me to be honest. As an industry, we would probably be better off without it in the long run IMHO.
PHP’s strengths are how easy it is to make quick hacks quickly (similar to Perl) and get it running without any ceremony (if you have a web server with PHP, you can just upload it somewhere and it Just Works, no application server with reverse proxy needed). This is why it survives; I agree that the language’s warts pull you to writing flawed code though, especially once you need to start scaling.
Isn’t Python, Ruby, or Perl just as good for that? I mean, you can point at “but I don’t like X or Y” and okay fair enough, but is it really “better” in any meaningful way?
Admittedly, I’ve been out of the loop of PHP for a few years, but I often found it quite hard to get running due to the massive php.ini file which controls a lot of deep aspects of PHP. At least you no longer have to set the bloody timezone in there any more.
For the “just copy the file to htdocs” workflow, I think only Perl comes close to that use case; Ruby is so Rails oriented nowadays. I’m not confident to say much about Python web stuff since I don’t know it though.
You don’t need to use Rails with Ruby, just like you don’t need to use Laravel with PHP. It’s just common (in both cases) because it works well. Sinatra is a much small web framework that also works quite well for many cases (about 2k lines of code, IIRC).
I do agree that using PHP can have a lower ramp-up time in some common “quick scripts” cases, but on the other hand, some of those cases are also rather hard to get right with PHP (specifically, I’m thinking of mail() being rather hard to use securely so that your contact form won’t be abused to send out spam). I’m not entirely sure just how much value there is in that (and it’s also not exactly what this article is talking about, either).
Is that nowadays a common case still? mod_php was an Apache thing and even Apache has been declining over the years so it might actually be easier to find a server that can run Perl or Python as CGI since at least the latter is nearly guaranteed to be installed in any case.
I don’t have any numbers though, so if anyone has recent information on how common it is to have PHP hosting, I’m all ears.
Wordpress is still going strong, and I think every el cheapo hosting provider that offers some sort of shared hosting is still using Apache with PHP (think DirectAdmin or CPanel)
I agree with this. When my employer gave me an opportunity to do a Greenfield PHP project, I accepted it with the thought that “hey, it’s 2019, and I’ve heard of many good developments in PHP recently, so maybe it’s not so bad anymore.”
I did everything right (as far as I could tell), followed modern best practises, etc. PHP is still so bad for the reasons you mention.
So while the language definitely has its drawbacks and 20 years of legacy to carry with it; I can say in confidence that I enjoy working with it.
25 ;)
Good overview though and I agree with most of the points, except that I find the intro a little disheartening because except for the speed (huge difference) and the types (I’m not sure PHP needed them, really) the developer experience has been just as fine since 5.3.
My main gripe is that development in PHP had become less fun the more Symfony 2 gained traction. I suppose it’s objectively not a bad framework, but to me it seems they copied the “convention over configuration” from Rails, but badly. Bugs weren’t usually in your code, but hidden deeply hidden in some XML or YAML file. I’d rather solve a problem with code or using a library than learning every single config option by heart or managing to find it in the docs. But I haven’t written a lot of PHP the last years, maybe I should look at Laravel again, my last hobby project in Slim also had some hiccups, none of which were PHP’s fault.
Symfony took its inspiration from Java’s Spring Framework and only got more railsish (or laravelesque) in later versions, so there were some rough edges during the transition. With version 5 Symfony got to a place I personally am quite happy with.
My hands-on experience stopped in 2014-15, but I didn’t see that they reverted the horrible mess of XML/YML for important behavioral criteria of the framework. From what people told me 5.0 was pretty much a smooth transition from 2.x, no hard break like 1->2.
Also I don’t really know what you mean, both Symfony 2 and Laravel were released in 2011, and Symfony 1 was quite different and I didn’t see the above mentioned problem there. And what I described was absolutely a problem in 2.x already. I would really love to know which phase you as the transition phase, maybe our timeline is really so different.
And yes, this sounds bad, but I don’t see it as an objectively bad framework, it just puzzles me why they went this direction.
For example auto resolving and configuring of services/classes was added to the DI container, the AppBundle got removed. There’s still a lot of configuration going on, but the boilerplate was significantly reduced.
(For the record: I worked with Symfony 1 only on one project then got back into the framework at 2.8 or something.)
A lot of the problems in PHP are really fundamental without easy fixes, not without the “Python 3 of PHP”. Slapping on a few features and syntax sugar is nice and all, but it won’t fix any of that.
I’ve seen countless bugs because of magic conversion between associative and indexed arrays, extremely basic error checking and functions are still broken, it’s still very easy to add critical security bugs, and so forth, and so forth.
There are still countless “wtf?!“s left. There is no easy fix for this, but PHP’s stdlib is a complete mess and liability.
I don’t strictly disagree you can write good software with it, but on the other hand a lot of things are also much harder than they need to be. A certain subset of problems is impossible to solve. For example, a function to generate a temporary name with a fixed file extension (
fooXXXXXXX.html) is impossible to implement in a guaranteed race-free way as far as I know (solving this problem inspired my fopen() post above; but I’ll gladly be shown wrong on this).Of course, it’s “probably good enough”, but why settle for that when you can have “guaranteed correct” with literally every other mainstream language?
The value of PHP was in that it ran really well on shared hosting, and I think it was a stroke of great insight back in the day. Things that are “wtf”s now – like the php.ini – made a lot of sense in that context, too, but now we’re stuck with it. I don’t see the value PHP gives us. I don’t want to tell other people what language they “should” be using, but it just seems like a sunk-cost thing to me to be honest. As an industry, we would probably be better off without it in the long run IMHO.
PHP’s strengths are how easy it is to make quick hacks quickly (similar to Perl) and get it running without any ceremony (if you have a web server with PHP, you can just upload it somewhere and it Just Works, no application server with reverse proxy needed). This is why it survives; I agree that the language’s warts pull you to writing flawed code though, especially once you need to start scaling.
Isn’t Python, Ruby, or Perl just as good for that? I mean, you can point at “but I don’t like X or Y” and okay fair enough, but is it really “better” in any meaningful way?
Admittedly, I’ve been out of the loop of PHP for a few years, but I often found it quite hard to get running due to the massive php.ini file which controls a lot of deep aspects of PHP. At least you no longer have to set the bloody timezone in there any more.
For the “just copy the file to htdocs” workflow, I think only Perl comes close to that use case; Ruby is so Rails oriented nowadays. I’m not confident to say much about Python web stuff since I don’t know it though.
You don’t need to use Rails with Ruby, just like you don’t need to use Laravel with PHP. It’s just common (in both cases) because it works well. Sinatra is a much small web framework that also works quite well for many cases (about 2k lines of code, IIRC).
I do agree that using PHP can have a lower ramp-up time in some common “quick scripts” cases, but on the other hand, some of those cases are also rather hard to get right with PHP (specifically, I’m thinking of
mail()being rather hard to use securely so that your contact form won’t be abused to send out spam). I’m not entirely sure just how much value there is in that (and it’s also not exactly what this article is talking about, either).For python you mostly can’t but there is a cgi module in the standard library (probably a bit painful to use cleanly)
Is that nowadays a common case still?
mod_phpwas an Apache thing and even Apache has been declining over the years so it might actually be easier to find a server that can run Perl or Python as CGI since at least the latter is nearly guaranteed to be installed in any case.I don’t have any numbers though, so if anyone has recent information on how common it is to have PHP hosting, I’m all ears.
Wordpress is still going strong, and I think every el cheapo hosting provider that offers some sort of shared hosting is still using Apache with PHP (think DirectAdmin or CPanel)
I agree with this. When my employer gave me an opportunity to do a Greenfield PHP project, I accepted it with the thought that “hey, it’s 2019, and I’ve heard of many good developments in PHP recently, so maybe it’s not so bad anymore.”
I did everything right (as far as I could tell), followed modern best practises, etc. PHP is still so bad for the reasons you mention.
::bitter laughter::
25 ;)
Good overview though and I agree with most of the points, except that I find the intro a little disheartening because except for the speed (huge difference) and the types (I’m not sure PHP needed them, really) the developer experience has been just as fine since 5.3.
My main gripe is that development in PHP had become less fun the more Symfony 2 gained traction. I suppose it’s objectively not a bad framework, but to me it seems they copied the “convention over configuration” from Rails, but badly. Bugs weren’t usually in your code, but hidden deeply hidden in some XML or YAML file. I’d rather solve a problem with code or using a library than learning every single config option by heart or managing to find it in the docs. But I haven’t written a lot of PHP the last years, maybe I should look at Laravel again, my last hobby project in Slim also had some hiccups, none of which were PHP’s fault.
Symfony took its inspiration from Java’s Spring Framework and only got more railsish (or laravelesque) in later versions, so there were some rough edges during the transition. With version 5 Symfony got to a place I personally am quite happy with.
My hands-on experience stopped in 2014-15, but I didn’t see that they reverted the horrible mess of XML/YML for important behavioral criteria of the framework. From what people told me 5.0 was pretty much a smooth transition from 2.x, no hard break like 1->2.
Also I don’t really know what you mean, both Symfony 2 and Laravel were released in 2011, and Symfony 1 was quite different and I didn’t see the above mentioned problem there. And what I described was absolutely a problem in 2.x already. I would really love to know which phase you as the transition phase, maybe our timeline is really so different.
And yes, this sounds bad, but I don’t see it as an objectively bad framework, it just puzzles me why they went this direction.
For example auto resolving and configuring of services/classes was added to the DI container, the AppBundle got removed. There’s still a lot of configuration going on, but the boilerplate was significantly reduced.
(For the record: I worked with Symfony 1 only on one project then got back into the framework at 2.8 or something.)
Oof. I just went and looked at my oldest PHP code. It will turn 25 this fall.
I’m sure that is not the reaction the article was trying to inspire, but it struck me funny.
Thanks! I didnt know about the arrow functions
https://stitcher.io/blog/short-closures-in-php