Hacker News Reader

Comment by 542458 | Hacker News Reader

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.

View on HN

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.

> 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> 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 -- 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> and I suspect eventually they'll phase out the Hebrew spelling.

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!

You should watch this video: 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 ;).

I think the C roots are also why PHP arrays double as hash maps.

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.

> 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?

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 :)

> 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

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.

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.

Even a bog standard LAMP setup has opcache enabled nowadays.

> 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.

It outperformed them in benchmarks but not in practice due to having to reload all libraries on every request.

Reply on news.ycombinator.com