Hacker News Reader

Comment by nkozyra | Hacker News Reader

> This revisionist stance that there was never anything really wrong with PHP

This strikes me as a strawman. PHP spent years being a generally loathed language for reasons that at this point aren't really worth reiterating.

But, in an analog to Javascript, it has made progress, grown up and become a better language. One of the best? Like Javascript, no. But serviceable at worst.

I stopped earnest work in PHP ~ 5.7. I dabbled with HHVM, but eventually moved most backend/server code to Go and moved on with my life. But PHP 7+ has been a big step up, at least from my current vantage point.

View on HN

>This strikes me as a strawman. PHP spent years being a generally loathed language for reasons that at this point aren't really worth reiterating.

This story is called "25 years of PHP" and the parent starts their comment with "I wrote a lot of PHP from 1999-2008". In this context I think it's fair to remind people of the many... controversial choices the PHP developers have made (or, maybe more accurately, stumbled upon) especially early in its history.

I certainly hope that most of these earlier flaws have been addressed, and I'm willing to believe that modern PHP can be a much better language to work with but that doesn't mean that we can say that criticism wasn't ever warranted. Lest we forget this is a language that once shipped a function called "mysql_real_escape_string" and saw nothing wrong with that and a tertiary statement whose precedence works backwards from any other language with a similar construct.

Really, though, who denies the language has a very bad reputation? A lot of these decisions were questionable, but explainable, like mysql_real_escape_string coming from the MySQL C code itself.[1] that doesn't excuse it, but it explains it.

[1] https://dev.mysql.com/doc/refman/8.0/en/mysql-real-escape-st...

My point is that it's not an undeserved reputation, there were many real problems. That's what was being challenged.

And the idea that it was reasonable to ship paper thin wrappers around a C API in a high level scripting language is one of the many problems that used to plague PHP. You could even get it to segfault with certain APIs because they would basically just call C completely unchecked. You also have functions having "out parameters" because the underlying C function does, even though PHP has multiple ways to return multiple values. I could also point out how basically every PHP subsystem had its own set of functions for error handling instead of having any kind of unified error system.

MySQL itself having made very questionable choices around the same era (and PHP and MySQL walking hand in hand) definitely doesn't help either, I grant you that.

Javascript has made progress too. While far from perfect and I think PHP's journey started at a worse point has has gone further JS certainly is a lot better now and the major failings of JS are of it's ecosystem and not the language itself.

I also think that both JS and PHP get a lot of flak for maintaining backwards compat as far back as they do. You can run a lot of webapps (frontend and backend) from 10-20 years back in modern PHP and browsers which is pretty amazing. I'd like them to have a modern mode (like the proposed p++/<?php2020 and modules for JS) we should still acknowledge that maintaining compat that far back is not easy.

> Javascript has made progress too.

To be clear, this is what I was saying when I called upon it as an analog.

Ah, then I misunderstood. Thanks for clearing up

If you don't do that, you get the python 2 to 3 transition. Which is still going on.

PHP did drop some stuff between 5 and 7, but all of it had been marked deprecated for some time prior (often years).

Reply on news.ycombinator.com