5 ms·

As somebody who loves PHP, some PHP mockery is deserved. The standard function naming and argument ordering is inconsistent and stupid. It throws errors written

by 542458 5y ago

As somebody who loves PHP, some PHP mockery is deserved. The standard function naming and argument ordering is inconsistent and stupid. It throws errors written in Hebrew. There were fundamental decisions made that harmed web security for years. Unicode wasn’t in PHP for a long time. Getting decent performance and/or scaling was/is a major challenge. The comparison tables are questionable at best. Etc. The language is bad, but... you can still write great code in a bad language. And you don’t need a good language, or even good code to build a great website. Facebook has made more money with questionable PHP code than any site built with elegant pearl webscripts that I know of. Wikipedia is PHP. So was Digg (RIP). Your users don’t give a darn how good your language or code is so long as it usually works. So tl;dr, PHP sucks, but I love PHP.

nkozyra 5y ago
> Getting decent performance and/or scaling was/is a major challenge. The rest of what you say I agree with, but the language was never a performance bottleneck over other scripting languages. It certainly scaled better than ruby or perl or python apps with the same logic. The fact that each request was fundamentally stateless and ephemeral helped this if you needed to distribute your app and made development faster as well. Back to V5 it outperformed its competition in benchmarks
- cutler 5y ago
  Paradoxically, PHP's stateless architecture is also what makes it dog-slow with large frameworks such as Laravel. Now you have to load the whole framework with every request.
  - aetherspawn 5y ago
    Sort of, but you don't need to parse it. Anyone using PHP in serious prod uses something like memcached/opcache to skip parsing, which speeds up TTFB typically by about 200x.
    - fogihujy 5y ago
      Even a bog standard LAMP setup has opcache enabled nowadays.
  - progforlyfe 5y ago
    > the whole framework Files are autoloaded lazily, meaning only classes that are touched are loaded on any given request. If the code is split into well sized, purposeful modules, it becomes a non issue.
- jeltz 5y ago
  It outperformed them in benchmarks but not in practice due to having to reload all libraries on every request.
ZephyrBlu 5y ago
You should watch this video: https://youtu.be/wCZ5TJCBWMg https://youtu.be/wCZ5TJCBWMg It's a talk by the creator of PHP about how PHP grew to what it is today. The entire thing is really interesting. There is actually a reason for things like 'inconsistent' argument ordering. They're ordered based on the C API, rather than being consistent in user land ;).
- cutler 5y ago
  I think the C roots are also why PHP arrays double as hash maps.
GongOfFour 5y ago
I started my career as a PHP dev in 2003 (mysql/smarty/adodb ftw) and I became a Rails dev around 06. Since then I have, for various reasons, switched back and forth between PHP and Ruby. The interesting thing that I've noticed in that time is that Ruby is, for the most part, the same language (and ecosystem!!) it was 15+ years ago and that is a good thing. PHP has tried hard to not be the language and ecosystem that it was 15-20 years ago and because of that it feels pulled in a lot of different directions. You encounter code that mixes 15/20 year old functions with more enterprisey OO conventions that came out of the post PHP5 era. It can feel weird to switch to that from a language like Ruby that more or less has had coherent approach since 2003. I'm sure it's nostalgia but I think the PHP 4 -> 5 transition was the best era of PHP. Codebases at that time mixed OO and C-ish function based programming in pragmatic and easy to understand ways. That weird shitshow of objects, functions that accept pass by reference or pass by value, request scoped global state, etc was fun and anarchic and, for whatever reason, totally made sense to a self-taught programmer like me at the time.
cutler 5y ago
Re Facebook, you can say that again. In August 2007 the source code of Facebook's index.php was exposed revealing a long list of global variables and not a single function definition in the whole 439 lines. Facebook engineer Steven Grimm commented 3 years later that similar, if not the same, code was still part of the codebase. So much for enterprise architecture.
kalleboo 5y ago
> Facebook has made more money with questionable PHP code than any site built with elegant pearl webscripts that I know of. Wasn't Amazon originally written in Perl?
- 542458 5y ago
  AKAIK Amazon was a hodgepodge, with the front end being mostly C with a custom templating engine that could (eventually) run a subset of pearl for scripting. More C/C++/Java/Pearl was using for backend and internal tooling. So kinda sorta, but definitely not in a way that seems elegant to me :)
ancarda 5y ago
> The standard function naming and argument ordering is inconsistent and stupid This is quite hard to fix, as it would break almost everything. So you'd end up with a Python 3 situation. However, as of PHP 8, it's less of an issue. If you can't remember the order for arguments, you can use named arguments <https://3v4l.org/cY1PB https://3v4l.org/cY1PB> like so: strpos(needle: "foo", haystack: "foobar") > It throws errors written in Hebrew If you're referring to T_PAAMAYIM_NEKUDOTAYIM, this is no longer true as of PHP 8: https://3v4l.org/2T8qQ https://3v4l.org/2T8qQ -- the error is just this: Parse error: syntax error, unexpected token "::", expecting end of file Internally, the token is still called T_PAAMAYIM_NEKUDOTAYIM, but you can also refer to it by T_DOUBLE_COLON: <https://www.php.net/manual/en/tokens.php https://www.php.net/manual/en/tokens.php> and I suspect eventually they'll phase out the Hebrew spelling.
- verelo 5y ago
  oh man, named arguments are great. I should have read the release notes sooner, i had no idea this change came out. Thanks for mentioning it!

by 542458 5y ago

nkozyra 5y ago

> Getting decent performance and/or scaling was/is a major challenge. The rest of what you say I agree with, but the language was never a performance bottleneck over other scripting languages. It certainly scaled better than ruby or perl or python apps with the same logic. The fact that each request was fundamentally stateless and ephemeral helped this if you needed to distribute your app and made development faster as well. Back to V5 it outperformed its competition in benchmarks

cutler 5y ago
Paradoxically, PHP's stateless architecture is also what makes it dog-slow with large frameworks such as Laravel. Now you have to load the whole framework with every request.
- aetherspawn 5y ago
  Sort of, but you don't need to parse it. Anyone using PHP in serious prod uses something like memcached/opcache to skip parsing, which speeds up TTFB typically by about 200x.
  - fogihujy 5y ago
    Even a bog standard LAMP setup has opcache enabled nowadays.
- progforlyfe 5y ago
  > the whole framework Files are autoloaded lazily, meaning only classes that are touched are loaded on any given request. If the code is split into well sized, purposeful modules, it becomes a non issue.
jeltz 5y ago
It outperformed them in benchmarks but not in practice due to having to reload all libraries on every request.

ZephyrBlu 5y ago

You should watch this video: https://youtu.be/wCZ5TJCBWMg https://youtu.be/wCZ5TJCBWMg It's a talk by the creator of PHP about how PHP grew to what it is today. The entire thing is really interesting. There is actually a reason for things like 'inconsistent' argument ordering. They're ordered based on the C API, rather than being consistent in user land ;).

cutler 5y ago
I think the C roots are also why PHP arrays double as hash maps.

GongOfFour 5y ago

I started my career as a PHP dev in 2003 (mysql/smarty/adodb ftw) and I became a Rails dev around 06. Since then I have, for various reasons, switched back and forth between PHP and Ruby. The interesting thing that I've noticed in that time is that Ruby is, for the most part, the same language (and ecosystem!!) it was 15+ years ago and that is a good thing. PHP has tried hard to not be the language and ecosystem that it was 15-20 years ago and because of that it feels pulled in a lot of different directions. You encounter code that mixes 15/20 year old functions with more enterprisey OO conventions that came out of the post PHP5 era. It can feel weird to switch to that from a language like Ruby that more or less has had coherent approach since 2003. I'm sure it's nostalgia but I think the PHP 4 -> 5 transition was the best era of PHP. Codebases at that time mixed OO and C-ish function based programming in pragmatic and easy to understand ways. That weird shitshow of objects, functions that accept pass by reference or pass by value, request scoped global state, etc was fun and anarchic and, for whatever reason, totally made sense to a self-taught programmer like me at the time.

cutler 5y ago

Re Facebook, you can say that again. In August 2007 the source code of Facebook's index.php was exposed revealing a long list of global variables and not a single function definition in the whole 439 lines. Facebook engineer Steven Grimm commented 3 years later that similar, if not the same, code was still part of the codebase. So much for enterprise architecture.

kalleboo 5y ago

> Facebook has made more money with questionable PHP code than any site built with elegant pearl webscripts that I know of. Wasn't Amazon originally written in Perl?

542458 5y ago
AKAIK Amazon was a hodgepodge, with the front end being mostly C with a custom templating engine that could (eventually) run a subset of pearl for scripting. More C/C++/Java/Pearl was using for backend and internal tooling. So kinda sorta, but definitely not in a way that seems elegant to me :)

ancarda 5y ago

> The standard function naming and argument ordering is inconsistent and stupid This is quite hard to fix, as it would break almost everything. So you'd end up with a Python 3 situation. However, as of PHP 8, it's less of an issue. If you can't remember the order for arguments, you can use named arguments <https://3v4l.org/cY1PB https://3v4l.org/cY1PB> like so: strpos(needle: "foo", haystack: "foobar") > It throws errors written in Hebrew If you're referring to T_PAAMAYIM_NEKUDOTAYIM, this is no longer true as of PHP 8: https://3v4l.org/2T8qQ https://3v4l.org/2T8qQ -- the error is just this: Parse error: syntax error, unexpected token "::", expecting end of file Internally, the token is still called T_PAAMAYIM_NEKUDOTAYIM, but you can also refer to it by T_DOUBLE_COLON: <https://www.php.net/manual/en/tokens.php https://www.php.net/manual/en/tokens.php> and I suspect eventually they'll phase out the Hebrew spelling.

verelo 5y ago
oh man, named arguments are great. I should have read the release notes sooner, i had no idea this change came out. Thanks for mentioning it!