Hacker News Reader

Comment by zeptonix | Hacker News Reader

I used to work way back in the day on PHP too, but even though I'm sure this will be downvoted, it's really sad people still take it seriously as a language in 2023. There's nothing remotely elegant about it. It's not expressive or programmatically succinct in the way Ruby is. It's not beautifully well thought-out the way Python is. It's not fast and modern in the way Rust is. It's not elegant or composable or client-side renderable in the way React.*script is. It just brings nothing to the table. It's an ugly hodgepodge borne out of an over-engineered homepage from 28 years ago. Various business interests have kept it afloat, and people who don't know any better keep championing it. I think people do eventually catch up with what's going on though as soon as they personally experience writing anything remotely serious (5-10,000+ LOC) that isn't a simplistic web-app.

View on HN

> I used to work way back in the day on PHP too,

This is your issue - PHP < 5.3 is very different to PHP 7+. Not just at the language level - but the community, frameworks and best practices too. No more random scattering of SQL statements in HTML files!

Modern PHP (with a framework like Laravel or Symfony) is probably one of the most productive ways to build web applications.

> It's not beautifully well thought-out the way Python is.

This is definitely an interesting take... Python hasn't even solved package management yet. And the 2.7 => 3 migration is probably the most famous example of making a mess of an ecosystem with backwards incompatible changes. In contrast PHP has Composer and 5.3 code is pretty much compatible with 8.0 (although ideally all code from the 5.3 era should be burned at the stake).

> and people who don't know any better keep championing it. I think people do eventually catch up with what's going on though as soon as they personally experience writing anything remotely serious (5-10,000+ LOC) that isn't a simplistic web-app.

You've basically just said that PHP devs are too inexperienced to be able to scale a codebase past 10k LOC? Pretty much every serious web dev using Symfony/Laravel would disagree with you.

I'm on PHP 8 and I feel the same as parent.

Sure, there's been a lot of progress since the PHP 5 days, but the core of the language has been left mostly untouched by design, and we haven't seen the kind of drastic moves like JS moving to ES6 syntax.

It's a matter of taste, so there's no absolutr truth. I hate PHP's function and property access syntax differenciation and wildly prefer ruby's approach or instance. And there's so much more nice things coming in languages that have been designed from the ground up to be nice to use.

I understand PHP's pragmatism, but can't find it pleasant to use TBH.

PS: we got arrow functions, but they stay limited to anonymous functions for instance...

The one feature on PHP that I wish was more commonplace is the `use` keyword in function expressions as it is one of the few ways to limit what names are in scope at a given point in the code

IIRC Rust's `mod` declarations can behave similarly.

Maybe PHP can add a "stricter" mode that gets rid of all the cruft? Enable it per-file, allow it to simmer for 10 years, remove legacy support in PHP 12.

This would really help in a lot of way IMHO. PHP has good aspects, getting rid of the weirder one, even if compatibility gets sacrificed, would be a boon for building new applications.

It already has one

I called it "stricter", not "strict" for a reason.

Uhm, how about PHP attributes, getting rid of comments / annotations? Named arguments? Constructor property promotion? Readonly properties (8.1) / classes (8.2)? Arrow functions or typed properties (both 7.4)?

I'd say those are really cool things. Especially as a web developer, there's just so much boilerplate I can get rid of since using 8.0+.

I’m in agreement with you that it came a very long way.

Now, most of those have been present in many other languages [0], often with less limitations.

And as usual the old ways haven’t all been deprecated either, so it stays weird. For instance typed properties were a chance to reset the clock on type handling, but no, declaring a type will force cast parameters to that type instead of throwing an error (i.e. passing 0 for a string argument will convert it silently)

[0] Constructor property promotion isn’t, but TBH I’m of mixed feelings about it. We get conciseness in exchange for weirdness as the properties aren’t declared outside of the constructor, where they would be otherwise. I wished it was done the other way round.

Yes, the backward compatibility is a crux on the one hand, on the other hand it has made upgrading PHP versions a breeze. In the past 6 months I updated several code bases from PHP 7 / 8.0 to PHP 8.1 / 8.2, the PHP part was easy (just the deprecated dynamic properties in 8.2 caused a wall of text in our loggers), the framework was a bit more difficult. The most problematic were the exotic packages that the clients had installed ages ago and that are not properly maintained anymore, so I have to figure out a replacement for those code modules.

Constructor property promotion is fine, I think. I think it ties in well with the readonly property.

    public function __construct(
        public readonly Company $company,
    )
    {
    }

There's just so much info & functionality + type safety crammed into there that wouldn't have been possible previously; it's really nice.

> declaring a type will force cast parameters to that type instead of throwing an error

There is `declare(strict_types=1)`[0]

[0]: https://www.php.net/manual/en/language.types.declarations.ph...

Yes, except it has to be set on the _caller_ side.

I kinda see why, after all it’s the caller who will deal with the TypeError. But assuming we’re not setting types for all our functions, when I do for a specific one, I want to enforce that strictness on the _callee_ side (“for this function, it really matters that the parameters are correct”), and not have to go check if every single caller files properly has the strictness set. [0]

So in the end, the best option is to _not_ type scalar parameters, and do the strict check manually and throw your own TypeError, inside your function instead.

[0] Auto setting strictness for every file in your project and checking for it in CI clears the issue, but that becomes another boilerplate you’re adding to your system. And it still doesn’t work for native functions.

It’s so close. Really, so close to be good.

> Auto setting strictness for every file in your project and checking for it in CI clears the issue, but that becomes another boilerplate you’re adding to your system

There was this RFC[0] but it seems to have fizzled.

> And it still doesn’t work for native functions.

The page states: 'Function calls from within internal functions will not be affected by the strict_types declaration' (emphasis mine). Outside of array_map I don't think this happens all that much.

> So in the end, the best option is to _not_ type scalar parameters, and do the strict check manually and throw your own TypeError, inside your function instead.

That sounds awful. Why not install a nice static analyzer like phpstan or psalm and never think about it again?

[0]: https://wiki.php.net/rfc/namespace_scoped_declares

> native functions

Thanks

> That sounds awful. Why not install a nice static analyzer like phpstan or psalm and never think about it again?

It is completely unelegant, but works decently in practice (fits the subject perfectly…). We’re extensively using phpstan, especially as it’s the best way to expose in array types.

Phpstan still has blind spots, including the ability to disable it on the caller side (in particular, as far as I know you can’t disable specific errors inline, so if you have to do it for one parameter for instance, it applies to all parameters), and the option to overwrite a variable type just for phpstan. Those comes from developer error, but that’s exactly what we want to protect the system from.

Actually checking at runtime that a value is of the right type is more secure.

"Can't find it pleasant" is a personal preference and not why no one should use PHP which the GP is suggesting.

GP’s take was way too salty, but to be honest I understand where he comes from.

Yes, it’s a matter of personal preference, but I also never worked with people that thought PHP was beautiful. Not that we look down on it, but it’s probably the same feeling construction people have towards their white vans. We value the good parts, hate the jagged parts, and if tomorrow it made more sense to ride Miata for whatever crazy reason, we wouldn’t look back. But I’m not holding my breath to have any decent reason to get out of PHP at my current job, and I appreciate the reasons why.

> No more random scattering of SQL statements in HTML files!

And yet you will still find this, because the long-tail of bad PHP is near infinite.

> although ideally all code from the 5.3 era should be burned at the stake

I guarantee you that a decent amount of real PHP coding right now is maintaining legacy stuff, not the new fangled 8.

It is, of course, the same in the Java world - most of the day job is not using Java 17. It's just that Java 6 code forced onto Java 8 isn't as bad as PHP 4 code hacked into PHP 5 code still struggling along in PHP 9. (Especially because as a scripting language, it will more likely fail at runtime, not build-time).

Sorry to be dismissive, but elegance, expressiveness or succinctness are not mandatory for "making things". Gatekeeping a programming language on esthetics is quite shallow in my opinion.

Ease of use and deployment, breadth, availability, low cost of maintaining, are sometimes more important, and PHP offers plenty of value in these respects.

I don't want to work with it, but I will never presume to look down on people that do. PHP has been a cornerstone for a whole generation of programmers and I think the current web-development ecosystem would not be where it is without it.

Yeah I do agree it was a stepping-stone in many ways.

It doesn't matter what happens, anytime something good PHP is mentioned the thread always turns into a fight. Why can't we just stop gate keeping programming languages and let people enjoy them. PHP gets tore apart all year long, and 1 nice article comes out and everyone jumps on it like it's preaching Delphi or VBA.

PHP has continued to done wonders for me, I continue to write huge apps in it, I continue to love it. I've used every other language you wrote, and continue to this day to write in PHP. Not because I'm not able to grasp how good another language is. But because it works. If I need something I go to packagist and search, it's always there. If I need to deploy something, there is tons of ways, and even basic ones. I don't need no fancy deployment setup, but I can have a fancy deployment setup if I want.

But people are more then welcome to hate it, and every time a positive post comes out about PHP I will continue to post my statement and then carry on building stuff. As there is ALWAYS a negative comment.

Everyone's at a different step in their journey. But I do agree if you're building stuff then exactly, who cares? End of the day it's definitely about what's built, not how.

HN does a lot of stuff well, but there is a ton of gate keeping here and PHP is one part of it. It does not deserve the hate it gets, it's popular to hate PHP here. It's actually less popular to like PHP. So articles like the above always get torn up.

It's rather sad to see, we should be encouraging people to build however they want. Point students in the direction of best practices and discuss ways to improve. Rather than talk about how much we hate the fact that PHP continues to be in the top 10 and pretty much the entire web is built with it.

But people do love to hate.

> Everyone's at a different step in their journey.

Text book example of being condescending.

I’ve made a few “serious” projects with PHP and has been great, I never feel like I’m fighting against it to do what I need to do, the code can be very concise, its very fast and has a lot of batteries builtin.

Python is not beautifully well thought out, the syntax is awful and the version conflicts make it a mess.

You’re comparing to React which is not a language or in the same domain is confusing and makes me doubt your credibility.

> Your comparing to React which is not a language or in the same domain is confusing and makes me doubt your credibility.

They both render HTML and do it in a very different way.

Yes, but that doesn't make it a programming language. A lot of things can render HTML. I am pretty fluent in Javascript, HTML, CSS, jQuery, React, Nodejs, Nextjs, PHP, Python, and a beginner in Java and a few others. React is not a programming language.

Right, that's why it was React.*script. Regex.

That's such a strange statement, you can compare PHP and React because they both can return a HTML string? Even though one is built entirely within another language, and it isn't is not a "language". More of a toolkit. Same as say Symfony html framework is.

This is why I stopped posting on the internet people will twist and turn stuff for reasons beyond me. It’s like pulling teeth.

A "React vs PHP" Google search turns up tons of articles and forum questions with that exact same comparison.

So either it's logical to compare the two, or the internet is just full of idiots like me and the parent poster :D.

Many of those questions have answers that point out you are comparing two very different things. Some of them are explicitly comparing Laravel and React, which makes a bit more sense. The rest seem to be AI generated trash.

The easiest way to explain it is that you could reasonably use react within a PHP project.

I wouldn't use the term "idiot" but rather "ignorant". A good article that answers the PHP vs React question would be mostly explaining the differences in the function and usage of both tools.

For reference, I'm working with both React and PHP. And yes, for example WordPress uses React components. I'm a 42 year old software architect. But hey, maybe I've been ignorant all this time.

React vs PHP is a decision you can make, because... the intention of both is to output HTML.

edit:

> The easiest way to explain it is that you could reasonably use react within a PHP project.

I can use C within a Python project. Does that mean I can't compare the two? One is compiled while the other is interpreted, so maybe you can't compare those?

> React vs PHP is a decision you can make, because... the intention of both is to output HTML.

Often PHP is used when no HTML rendering happens at all (Apis, scheduled jobs etc.)

> I can use C within a Python project. Does that mean I can't compare the two? One is compiled while the other is interpreted, so maybe you can't compare those?

Those are at least both programming languages. Several major python libraries are written in C (or other compiled language) so a pure python project is probably fairly rare. Someone asking for "Python vs C" is probably more in need of an explanation of what the broad categories mean and tend to be used for than a point by point breakdown of specific language features and ergonomics.

In this specific instance, the complaint was that PHP, a server side language, doesn't offer client side rendering built in. This a point that should be brought up comparing JavaScript to PHP, not React.

> Often PHP is used when no HTML rendering happens at all (Apis, scheduled jobs etc.)

When comparing to React those things are irrelevant.

> the complaint was that PHP, a server side language, doesn't offer client side rendering built in.

So am I allowed to compare server side rendering to client side rendering? Or are those 2 different things and I'm ignorant if I try to compare them?

If you complain your tesla doesn't float very well, then you might be a little ignorant of what cars are used for (and that you probably should have used a ferry.)

React can be used both on the server and client side. That is a benefit over something that can be only used on the server side.

React can even be both on server and client using 1 codebase (see Next.js). But it seems the PHP police here on HN does not allow me to compare that solution to a solution in PHP.

It's funny how we both think of each others statement how strange it is.

For me, not being able to compare the two is like saying: You cannot compare a horse with a car as a means of transportation because a car is not an animal.

For me, I don't care one is a programming language and the other is a framework. For me they are both ways to generate HTML. PHP was/is mainly intended to generate HTML. It started as "Personal Home Page" and now is "Hypertext Preprocessor".

React isn't a language, it's an elegant pattern layered on top of (Java|Type)script which are languages. Not sure what versioning conflicts there are with Python but there are a lot of community solutions in the form of pyenv, virtualenv, etc. Python is well thought-out, imho, but I think it can take a certain type of person time to realize it. I used to hate it but the way I ultimately came around to understanding it was someone explained to me it's essentially extremely close to pseudo-code, which I think is ultimately why it can seem very natural and why so many universities and the larger STEM/ML community have all adopted it.

React with JSX can be pretty close to being a new language+runtime (just like Svelte).

Someone who worked with Python / Django and JAVA / Spring for years professionally, I see PHP / Laravel as absolute superior way to build web apps, especially if you are in a team and people might come and go.

> and people who don't know any better keep championing it

Experienced developers understand that there are different tools for different jobs. They also understand that languages are not successful for 30 years without providing some legitimate value.

I think that PHP isn't that bad for some use cases. What I really disliked about PHP as a developer was how much control the host has over tweaking the runtime; this can be"problematic" in some shared hosting setups.

However, I'm also a bit of a hypocrite here because I worked for a hosting company, and also loved that feature.

So, I think in the context of something like a container (or vps/dedicated) it can work well.

I think PHP gets a lot of hate because it used to be a nightmare. I know friends who still use it, and they claim it's a day and night experience from the olden days. It probably wouldn't be my first choice for a project, but I probably wouldn't groan either, if I had to reach for it now

I agree with all of those points, except that it does have one thing going for it - it is easy for end-users to deploy PHP apps: FTP your files onto any random cheapo shared web-host, done.

I’m amazed that it’s been so long and no other language comes close to that :(

Re-deploy, sure. Deploy? PHP packages still need installing, modules need enabling/configuring, PHP version needs to be chosen, etc. Unless it's a tiny project, the days of "just put the files on FTP" are almost gone.

Meanwhile for small, low traffic projects, serverless services are pretty close to the "just copy to deploy" model. And fly.io is all trivial for quite a few frameworks.

Compared to moat languages, if you have no visitors, php takes up 0 system resources from your system to just sit there and wait.

So you could have hundreds of small sites on the same machine for an extremely low resource cost. That is something it brings to the table and its very beneficial for hosting solutions where there are a lot of small webaites sharing on the same resource.

Along this line, I like how memory leaks just can't be a thing because the page only exists so long as it's being rendered.

I might be misinterpreting "taken seriously" with utility, but to me it is very valuable that a PHP script can just be dropped on almost any web server and it can start doing stuff, and that alone is reason enough not to not dismiss it.

Kinda, you have to make sure all the extensions you need are installed, then fix php.ini so it's not doing anything wrong, and then it usually works if you haven't missed anything, until something becomes deprecated.

I used to agree with this and think of it as a main benefit, but setting up a server to use Nodejs is easy and a lot of servers come prepped with node, npm, etc, so it's just as easy ad starting up a PHP project, if not easier because package.json can easily install dependencies.

> It's not beautifully well thought-out the way Python is

Slagging PHP and then saying this just means you are trolling which is not exactly welcomed on HN.

It's more productive as Ruby and Python and much faster than either? Is that not reason enough for some to choose it? I'd argue that of the PHP, Python, and Ruby it is Ruby that should die. It's the same use case as Python, but harder to read and just as slow.

we should show this comment to facebook that uses hack (php originated lang) in millions of files to run their little website and infrastructure.

php isn't bad. just got a bad rep. many langs got quirks. some more than others. but php has more web production success story and usage than most.

PHP had design flaws (many of which have been addressed since the 5.x days), but what language doesn’t?

A significant cause of it’s bad rap is touched on briefly in this article, Wordpress.

Even back in 5.3 days, you could write elegant and scaleable code, it just took work to do. At a former employer using PHP 5.3 on 2005 era hardware, we could do 500+ req/sec per machine with an average response time under 100ms and a P99 response time of under 250ms, with a zero downtime SLA and hundreds of millions of requests per day. Yeah, it wasn’t easy, but it worked.

As a dear friend used to say, PHP is a ball of nails. You throw it and it sticks. Just exercise care when picking it up and all is well.

> we should show this comment to facebook that uses hack (php originated lang) in millions of files to run their little website and infrastructure.

Appeal to authority isn't a valid strategy.

Facebook used PHP because they wanted to build something really quickly and afterwards it became too costly to switch, as it always does, so they built an entire engineering department to work around PHP issues.

Your average PHP dev team can't do that.

Plus, what are you comparing it to? Reasonable people don't compare it to Vlang, they compare it to Python, Ruby, Java, C#/.NET, Javascript/Typescript, Golang, and PHP ranks at best averagely against those regarding language, standard library and ecosystem consistency.

appealing to authority? lol. no. read my comment again. it shows real production example of a juge, complex, website that serves billions. average php devs can't do that? maybe. but the php lang doesn't block them.

You mean the slow, bloated website that rarely adds features useful for users?

nope, i mean a website that serves billions

The language is valuable and a good choice because it’s easy to read and your codebase Be(when used with a framework) are very maintainable. We have Java Perl and python and php has been the easiest to get people working on existing code.

The documentation is also excellent.

$For $me, $all $the $dollar $signs $make $the $code $hard $to $read.

I loved the straightforwardness of just having a nice simple HTML page with some <?PHP ?> sprinkled in. Now everything has to be done through a million layers of indirection. Which is fine when it's necessary, but I still like to write my own pages as simple unstructured PHP.

I was waiting for a comment like this. If I had a penny for.... I would be a gazillinaire :)

Reply on news.ycombinator.com