9 ms·

The Thing About PHP

44 points by askonomm 3y ago

phendrenad2 3y ago
There was never anything really wrong with PHP, just things that - to a computer science student, who just wrote some recursive-descent parser for C++ in OCaML - will seem inelegant to an embarrassing degree. But that doesn't actually matter. The benefits of PHP easily overruled those inelegancies. When you look at the average Ruby/Python/NodeJS project that's been around for more than 10 years, you'll see horrors beyond human comprehension, just like PHP.
- naiv 3y ago
  Absolutely true. Especially for javascript and people who do not understand typescript. I think op is having more of a problem with languages that are not fully typed than php per se.
  - somewhereoutth 3y ago
    Typing is no protection against metastasizing complexity - indeed it adds another layer of code-like 'agar' for such complexity to inevitably grow in.
    - lioeters 3y ago
      Complexity as a kind of mold culture, growing on the substrate of code and code-like typing, suggests the importance of sterile practice and hygiene, like testing.
  - askonomm 3y ago
    I think my problem is not entirely in languages that are not fully typed (although I do prefer them), but rather in languages that are half typed. Either be dynamic or static, not some awkward middle point. Perhaps PHP will get there eventually, but as it is right now is a bit strange to me.
- deleted 3y ago
  [deleted]
aspyct 3y ago
PHP is great for low maintenance web projects. It runs everywhere and it's cheap. It's essentially serverless without the expensive, no-cost-limit cloud providers. I've made a ton of personal projects in php, and I will continue doing so. They're great, they just keep running even when I don't look at them for a long time. Which is exactly what I need.
tacker2000 3y ago
I think we need to stop with all this PHP hate. Sure, 10-20 years ago the language was more hacky than anything, but nowadays its a solid choice for backend stuff, with lots of activity, new innovations, good, proven frameworks (Symfony, Laravel) and also lots of people who have experience in it. I have a few projects running a PHP API with a JS frontend (Vue in my case) and it works pretty nicely. Best of both worlds!
- deprecative 3y ago
  People love to hate on PHP then love to love JavaScript. It's bonkers. PHP is clearly better than JavaScript, it's just that we're all forced to use JS.
  - scq 3y ago
    I really do not understand this take and have to assume people who say this have not deeply used PHP. It has a large variety of bizzare language features that make JavaScript look downright well-designed. Examples off the top of my head: * Lists and dictionaries being the same data type ("array"). This makes it impossible to distinguish between an empty list and an empty dictionary, good luck encoding that JSON. * Arrays are pass-by-value * '123' == '+123' evaluates to true * '0' == '0.000' evaluates to true * `$a = true; $b = false; $c = $a and $b;`, $c evaluates to `true` * Closures requiring you to explicitly list every variable from the parent scope you want to use * References (&$var) have a lot of footguns * array_key_exists and property_exists taking opposite parameter orders * stdlib naming in general being pretty bad, with the stated justification being that strlen() was used as a hash function in early PHP versions, so functions were named to achieve an even distribution: http://news.php.net/php.internals/70691 http://news.php.net/php.internals/70691
    - rafark 3y ago
      Are you serious? https://gist.github.com/shapkarin/b3fbeaca95ef69df177b https://gist.github.com/shapkarin/b3fbeaca95ef69df177b
    - blueflow 3y ago
anonymous344 3y ago
i've been freelancer and app creator for more than 10 years. what's great with php(was) that it just worked. The apps just worked in virtual server for 10 years. Not anymore. with packet system (composer) +php 7.4...8 and need to have js-frontend everything nothing works anymore. Need to use my time instead of new features to fix build and packet manager problems and these are really difficult to explain to customers. aahh those easy days with php 5.6 and jquery
- lucideer 3y ago
  It still just works. Every single thing you could do without a package manager in 2009 still works fine without composer in 2023. All composer adds is the ability to easily use other people's code in your app. And that's not a new thing: people did that in one of two ways pre-2010: 1. They used PEAR/PECL, upon which composer is a massive improvement 2. They copied it from experts exchange, some spammy site like hotscripts.com, or - most often - from the comments section on php.net. The latter was a surprisingly good source but none of this was ever sustainable.
  - KronisLV 3y ago
    > ...from the comments section on php.net. The latter was a surprisingly good source but none of this was ever sustainable. Honestly, I wish more documentation out there had comments/discussion at the bottom. For example, what if would be like to find myself reading about setting up OpenID Connect and having the first (most upvoted) comments on the first page explain things that might not be clear in the docs, analogies that make things easier to understand, or code/configuration snippets for a particular technology. Somehow the comments in PHP docs were usually like: "after reading the docs, here's what you might want to really know", a bit like those tl;dr apps for manpages: https://tldr.sh/ https://tldr.sh/
    - WesolyKubeczek 3y ago
      I don’t know how they kept the comments section free from shitposting and actually useful.
samsquire 3y ago
PHP solves so many problems to do with deployments and scalability automatically. - You don't need to explicitly install your replacement code and start that server (java -jar .... / node server.js ) - You don't need a systemd unit to keep your server running ( you can deploy as many PHP files as you like and they'll all be "running" ) - You don't have to worry about keeping your server up (the php file). - You don't need to use Docker because PHP is pretty stable target. - You're not forced to deploy Kubernetes or Docker swarm to deploy code infront of users. - You could use Ansible to deploy your PHP but you can probably just use git. - You can spin up multiple servers and deploy the same file to them all and nginx and php-fpm shall handle concurrency and parallelism for you since each PHP session is independent and stateless.
- Nextgrid 3y ago
  > You don't need to explicitly install your replacement code and start that server This is a double-edged sword though. Let's say I have a PHP file that "include"s another one and a request arrives in the middle of such a deployment where the first PHP file has been replaced but the second has yet to be - you now have undefined behavior. Filesystem-based URL routing is one of the "features" I hate the most in PHP as it leads to countless security issues - simply uploading a file in the wrong place (or sometimes merely with a wrong extension) immediately turns into an RCE.
  - janosdebugs 3y ago
    That's why you do symlink-based deployments with PHP. It works just fine and is also not a problem unique to PHP. PHP itself doesn't follow filesystem-based routing, your webserver config does. PHP just executes what th webserver tells it to. Most PHP applications written in the last 10 years use a single entry point and are no longer prone to the attacks you are describing.
    - Nextgrid 3y ago
      Yes it's true that proper config can make this problem go away, but the fact that some of the advantages of PHP such as ease of deployment (drop a .php file -> you have a webapp) is a double-edged sword as it encourages a lot of bad practices (that large legacy projects such as Wordpress continue promoting). It's indeed possible (and quite pleasant) to do proper PHP with a good framework, sane web server config & modern development practices. The problem is that a sizeable chunk of the PHP ecosystem (and very popular projects such as Wordpress) are not doing that.
donatj 3y ago
> There are no generics, and from what I understand for some odd reason will never be even though Hack forked from PHP and managed to add them? The reason is pretty simple. Hack has a compilation step. PHP does not. Generics in an interpreted language means runtime errors, which are far less valuable and more troubling than compilation errors. PHP’s loose typing + an offline static analyzer like phpstan will get you roughly the same result without the runtime errors.
- hu3 3y ago
  What a coincidence. There's a video about generics in PHP, posted 2 hours ago: https://youtu.be/JtmRG5lCENA https://youtu.be/JtmRG5lCENA
- Ciantic 3y ago
  PHP doesn't have loose typing anymore, if you make a function parameter with a specific type: function test(bool $param) {} You will get an runtime error if you call it with wrong type: Fatal error: Uncaught TypeError: test(): Argument #1 ($param) must be of type boolean However generics are probably costly to typecheck runtime? I haven't studied the reason why there is not generics planned.
  - WesolyKubeczek 3y ago
    In a dynamic interpreted language there is no value of having generics over duck typing or omitting types altogether (and you can narrow down by specifying interfaces). Compiled languages generate a version of your function<T> for every T encountered in the codebase.
    - usrusr 3y ago
      For completeness: other compiled languages elide that T and use the types in angulars only to emit errors during compilation. Also perfectly fine, but certainly not any help in absence of static compilation.
gumballindie 3y ago
PHP as a language and ecosystem is great. Far more suitable for web development than python and trivially easy to scale. But PHP developers, boy oh boy, are a different story. My favourite is how they all still debate setter and getters and almost none know the language but only the framework they use and code usually turns into a huge pile of unmaintainable crap. But hey they use ORMs just in case they’ll swap database engines (happens so rarely not even worth mentioning).
- JamesonNetworks 3y ago
  The Venn diagram of developers who can't successfully use an ORM, but can write their own sane, well formed, normalized data access layer from scratch using just SQL are two entirely separated circles
  - gumballindie 3y ago
    Normal people write queries in a bunch of specialised classes. Data access in php is a pdo method call away anyway. But no, php devs need ddd dtos hydration models yml file configs goat sacrifices and a heated religious debate over why php is the belly bottom of web development and indeed the world. Tabs vs spaces. Such a nice language bastardised by over engineering and reinventing the wheel. Sad.
- pavel_lishin 3y ago
  Yup. If I were picking up side work, I'd be very wary of PHP projects - not because of the language, but because I'd be afraid of inheriting a tremendous, unreadable, unmaintainable mess. That's not to say that it doesn't happen in other languages, but I've never seen PHP code written by a stranger that didn't make me squirm.
  - gumballindie 3y ago
    And the odd part is that frameworks were meant to provide structure and make code easier to maintain. Last time, long time ago, when i touched a php symfony project i ended coding yml instead of actual php because _everything_ was in a config file - hundreds of packages and libraries just because the dev couldn't be bothered to issue calls to native php functions. Hilarious. However i did make a killing in training teams in design patterns and coding practices to help them maintain quality. And almost always my advice was to write framework agnostic code (treat the framework as if it were just a dependency). Worked nice. Clean little specialised classes, no config maintenance madness, i also enforced running code linters and smell detectors on each commit and push. Gave up on the language when i noticed that _literarily_ all teams had the exact same issues, the exact same topics of debate and the exact same flamewars.
stef-13013 3y ago
Really interesting... And 100% right about the "over-engineered" part. The "real" danger for PHP is to end up like Java (not the JVM, Java)
xnx 3y ago
Things have definitely taken a step back (or at best sideways) since the days of peak PHP popularity in terms of accessibility to new coders wanting to make something simple online. I'd love to see something as simple and portable as Google Docs for coding. There are plenty of proprietary low-code platforms for this, but nothing I know of where you can code with a real language in the browser, but still export the code (like you would export a .doc from Google Docs) to easily run at another cloud location or locally.

44 points by askonomm 3y ago

There was never anything really wrong with PHP, just things that - to a computer science student, who just wrote some recursive-descent parser for C++ in OCaML - will seem inelegant to an embarrassing degree. But that doesn't actually matter. The benefits of PHP easily overruled those inelegancies. When you look at the average Ruby/Python/NodeJS project that's been around for more than 10 years, you'll see horrors beyond human comprehension, just like PHP.

naiv 3y ago
Absolutely true. Especially for javascript and people who do not understand typescript. I think op is having more of a problem with languages that are not fully typed than php per se.
- somewhereoutth 3y ago
  Typing is no protection against metastasizing complexity - indeed it adds another layer of code-like 'agar' for such complexity to inevitably grow in.
  - lioeters 3y ago
    Complexity as a kind of mold culture, growing on the substrate of code and code-like typing, suggests the importance of sterile practice and hygiene, like testing.
- askonomm 3y ago
  I think my problem is not entirely in languages that are not fully typed (although I do prefer them), but rather in languages that are half typed. Either be dynamic or static, not some awkward middle point. Perhaps PHP will get there eventually, but as it is right now is a bit strange to me.
deleted 3y ago
[deleted]

aspyct 3y ago

PHP is great for low maintenance web projects. It runs everywhere and it's cheap. It's essentially serverless without the expensive, no-cost-limit cloud providers. I've made a ton of personal projects in php, and I will continue doing so. They're great, they just keep running even when I don't look at them for a long time. Which is exactly what I need.

tacker2000 3y ago

I think we need to stop with all this PHP hate. Sure, 10-20 years ago the language was more hacky than anything, but nowadays its a solid choice for backend stuff, with lots of activity, new innovations, good, proven frameworks (Symfony, Laravel) and also lots of people who have experience in it. I have a few projects running a PHP API with a JS frontend (Vue in my case) and it works pretty nicely. Best of both worlds!

deprecative 3y ago
People love to hate on PHP then love to love JavaScript. It's bonkers. PHP is clearly better than JavaScript, it's just that we're all forced to use JS.
- scq 3y ago
  I really do not understand this take and have to assume people who say this have not deeply used PHP. It has a large variety of bizzare language features that make JavaScript look downright well-designed. Examples off the top of my head: * Lists and dictionaries being the same data type ("array"). This makes it impossible to distinguish between an empty list and an empty dictionary, good luck encoding that JSON. * Arrays are pass-by-value * '123' == '+123' evaluates to true * '0' == '0.000' evaluates to true * `$a = true; $b = false; $c = $a and $b;`, $c evaluates to `true` * Closures requiring you to explicitly list every variable from the parent scope you want to use * References (&$var) have a lot of footguns * array_key_exists and property_exists taking opposite parameter orders * stdlib naming in general being pretty bad, with the stated justification being that strlen() was used as a hash function in early PHP versions, so functions were named to achieve an even distribution: http://news.php.net/php.internals/70691 http://news.php.net/php.internals/70691
  - rafark 3y ago
    Are you serious? https://gist.github.com/shapkarin/b3fbeaca95ef69df177b https://gist.github.com/shapkarin/b3fbeaca95ef69df177b
  - blueflow 3y ago

anonymous344 3y ago

i've been freelancer and app creator for more than 10 years. what's great with php(was) that it just worked. The apps just worked in virtual server for 10 years. Not anymore. with packet system (composer) +php 7.4...8 and need to have js-frontend everything nothing works anymore. Need to use my time instead of new features to fix build and packet manager problems and these are really difficult to explain to customers. aahh those easy days with php 5.6 and jquery

lucideer 3y ago
It still just works. Every single thing you could do without a package manager in 2009 still works fine without composer in 2023. All composer adds is the ability to easily use other people's code in your app. And that's not a new thing: people did that in one of two ways pre-2010: 1. They used PEAR/PECL, upon which composer is a massive improvement 2. They copied it from experts exchange, some spammy site like hotscripts.com, or - most often - from the comments section on php.net. The latter was a surprisingly good source but none of this was ever sustainable.
- KronisLV 3y ago
  > ...from the comments section on php.net. The latter was a surprisingly good source but none of this was ever sustainable. Honestly, I wish more documentation out there had comments/discussion at the bottom. For example, what if would be like to find myself reading about setting up OpenID Connect and having the first (most upvoted) comments on the first page explain things that might not be clear in the docs, analogies that make things easier to understand, or code/configuration snippets for a particular technology. Somehow the comments in PHP docs were usually like: "after reading the docs, here's what you might want to really know", a bit like those tl;dr apps for manpages: https://tldr.sh/ https://tldr.sh/
  - WesolyKubeczek 3y ago
    I don’t know how they kept the comments section free from shitposting and actually useful.

samsquire 3y ago

PHP solves so many problems to do with deployments and scalability automatically. - You don't need to explicitly install your replacement code and start that server (java -jar .... / node server.js ) - You don't need a systemd unit to keep your server running ( you can deploy as many PHP files as you like and they'll all be "running" ) - You don't have to worry about keeping your server up (the php file). - You don't need to use Docker because PHP is pretty stable target. - You're not forced to deploy Kubernetes or Docker swarm to deploy code infront of users. - You could use Ansible to deploy your PHP but you can probably just use git. - You can spin up multiple servers and deploy the same file to them all and nginx and php-fpm shall handle concurrency and parallelism for you since each PHP session is independent and stateless.

Nextgrid 3y ago
> You don't need to explicitly install your replacement code and start that server This is a double-edged sword though. Let's say I have a PHP file that "include"s another one and a request arrives in the middle of such a deployment where the first PHP file has been replaced but the second has yet to be - you now have undefined behavior. Filesystem-based URL routing is one of the "features" I hate the most in PHP as it leads to countless security issues - simply uploading a file in the wrong place (or sometimes merely with a wrong extension) immediately turns into an RCE.
- janosdebugs 3y ago
  That's why you do symlink-based deployments with PHP. It works just fine and is also not a problem unique to PHP. PHP itself doesn't follow filesystem-based routing, your webserver config does. PHP just executes what th webserver tells it to. Most PHP applications written in the last 10 years use a single entry point and are no longer prone to the attacks you are describing.
  - Nextgrid 3y ago
    Yes it's true that proper config can make this problem go away, but the fact that some of the advantages of PHP such as ease of deployment (drop a .php file -> you have a webapp) is a double-edged sword as it encourages a lot of bad practices (that large legacy projects such as Wordpress continue promoting). It's indeed possible (and quite pleasant) to do proper PHP with a good framework, sane web server config & modern development practices. The problem is that a sizeable chunk of the PHP ecosystem (and very popular projects such as Wordpress) are not doing that.

donatj 3y ago

> There are no generics, and from what I understand for some odd reason will never be even though Hack forked from PHP and managed to add them? The reason is pretty simple. Hack has a compilation step. PHP does not. Generics in an interpreted language means runtime errors, which are far less valuable and more troubling than compilation errors. PHP’s loose typing + an offline static analyzer like phpstan will get you roughly the same result without the runtime errors.

hu3 3y ago
What a coincidence. There's a video about generics in PHP, posted 2 hours ago: https://youtu.be/JtmRG5lCENA https://youtu.be/JtmRG5lCENA
Ciantic 3y ago
PHP doesn't have loose typing anymore, if you make a function parameter with a specific type: function test(bool $param) {} You will get an runtime error if you call it with wrong type: Fatal error: Uncaught TypeError: test(): Argument #1 ($param) must be of type boolean However generics are probably costly to typecheck runtime? I haven't studied the reason why there is not generics planned.
- WesolyKubeczek 3y ago
  In a dynamic interpreted language there is no value of having generics over duck typing or omitting types altogether (and you can narrow down by specifying interfaces). Compiled languages generate a version of your function<T> for every T encountered in the codebase.
  - usrusr 3y ago
    For completeness: other compiled languages elide that T and use the types in angulars only to emit errors during compilation. Also perfectly fine, but certainly not any help in absence of static compilation.

gumballindie 3y ago

PHP as a language and ecosystem is great. Far more suitable for web development than python and trivially easy to scale. But PHP developers, boy oh boy, are a different story. My favourite is how they all still debate setter and getters and almost none know the language but only the framework they use and code usually turns into a huge pile of unmaintainable crap. But hey they use ORMs just in case they’ll swap database engines (happens so rarely not even worth mentioning).

JamesonNetworks 3y ago
The Venn diagram of developers who can't successfully use an ORM, but can write their own sane, well formed, normalized data access layer from scratch using just SQL are two entirely separated circles
- gumballindie 3y ago
  Normal people write queries in a bunch of specialised classes. Data access in php is a pdo method call away anyway. But no, php devs need ddd dtos hydration models yml file configs goat sacrifices and a heated religious debate over why php is the belly bottom of web development and indeed the world. Tabs vs spaces. Such a nice language bastardised by over engineering and reinventing the wheel. Sad.
pavel_lishin 3y ago
Yup. If I were picking up side work, I'd be very wary of PHP projects - not because of the language, but because I'd be afraid of inheriting a tremendous, unreadable, unmaintainable mess. That's not to say that it doesn't happen in other languages, but I've never seen PHP code written by a stranger that didn't make me squirm.
- gumballindie 3y ago
  And the odd part is that frameworks were meant to provide structure and make code easier to maintain. Last time, long time ago, when i touched a php symfony project i ended coding yml instead of actual php because _everything_ was in a config file - hundreds of packages and libraries just because the dev couldn't be bothered to issue calls to native php functions. Hilarious. However i did make a killing in training teams in design patterns and coding practices to help them maintain quality. And almost always my advice was to write framework agnostic code (treat the framework as if it were just a dependency). Worked nice. Clean little specialised classes, no config maintenance madness, i also enforced running code linters and smell detectors on each commit and push. Gave up on the language when i noticed that _literarily_ all teams had the exact same issues, the exact same topics of debate and the exact same flamewars.

stef-13013 3y ago

Really interesting... And 100% right about the "over-engineered" part. The "real" danger for PHP is to end up like Java (not the JVM, Java)

xnx 3y ago

Things have definitely taken a step back (or at best sideways) since the days of peak PHP popularity in terms of accessibility to new coders wanting to make something simple online. I'd love to see something as simple and portable as Google Docs for coding. There are plenty of proprietary low-code platforms for this, but nothing I know of where you can code with a real language in the browser, but still export the code (like you would export a .doc from Google Docs) to easily run at another cloud location or locally.