Hacker News Reader

Comment by core-questions | Hacker News Reader

There was never anything wrong with PHP, really.

* If you wanted to scale it horizontally, it was ready to do that 15+ years ago

* No problem running it completely stateless

* Deploys are completely sane and predictable, it's just a bunch of files, and even when composer came along it didn't really change that too much

* Performant enough as far as the interpreted web languages go

* No problem writing a RESTful backend in it and fronting completely "modern" client facing tech on the top if you want

* Server side rendering since day 1

Like, it came down to people complaining about some function names / param orders as if it were the end of the world. I think a certain subset of people (shall we call them hipsters?) are just keen on finding new ground where they can rewrite the same boring things instead of working hard to improve the ecosystem of something existing.

I moved on from PHP aeons ago because it got this undeserved bad rap, but I still follow it and would welcome the chance to run it again.

View on HN

It's fine to like PHP and I'm willing to believe that modern PHP is a lot better than what it used to be but it annoys me that every time the language is brought up these days some people feel like rewriting history to pretend that PHP-bashing 15years ago was just a baseless memes made by haters who didn't get it.

There was plenty of wrong with PHP. There were very unsafe defaults, poor API choices, poor coding standards, inconsistent syntax, paper-thin C bindings that didn't provide the level of abstraction you'd expect from a scripting language etc... If you've forgotten what PHP used to be you can just take a trip down memory lane by browsing through this classic: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ . Lest we forget PHP was started as a templating engine that evolved haphazardly into a full fledged programming language, and it showed.

If you think PHP is a good language today then say that, but let's not pretend that the complaints and ridicule were always undeserved.

> If you think PHP is a good language today then say that, but let's not pretend that the complaints and ridicule were always undeserved.

It's a question of when do you let that go?

Right, I don't think it's necessarily the people that are _for_ PHP are ignoring the past, it's that the people _against_ PHP are still stuck in it.

This is a common straw man; PHP 5 and 7 made large strides, but that's because there was so much to fix, and there still is and will continue to be, like lack of first class functions, actual modules, etc. PHP is also unsuitable for persistent processes like serving WebSocket.

Ratchet works fine.

Why do you need "actual modules"? I feel that (when PSR-4 is followed) PHP's code separation practices are among the best, especially compared to other interpreted web-languages (Python, Ruby, js). And it's convenient while experimenting that it doesn't really enforce anything.

Without modules there can be dependency hell: conflicting subdependency versions, unless all your dependencies update their subdependencies in lockstep.

Websockets are no problem with Ratchet. OhDear is a high traffic app that uses laravel-websocket (based on Ratchet) with absolutely no performance issues.

They probably still have to maintain systems running PHP 5, and are quite literally stuck in it ;-)

Never, since PHP is fundamentally flawed, and trying to redesign it would make the split between Python 2 and 3 pale in comparison. PHP's main selling point is backwards compatibility and the existing ecosystem; a fundamental redesign would remove that. PHP's name is also mud when it comes to programming language design, and its community is notorious for poor practices, so no one's really clamoring for a more modern PHP.

The bitter truth for PHP stans is that it is what it is, you can get things done, and you can have valid reasons for using it (like legacy reasons, job market, etc.), but it's rightfully trending down and will continue to.

Oh, PHP definitely sucked before 5.

> Deploys are completely sane and predictable, it's just a bunch of files

This was absolutely the killer app for PHP. It was lucky enough to be well integrated with Apache, and crucially could run as a non-persistent per-user interpreter behind the web server. This made it exactly ideal for deployment in shared hosting environments. The fact that you can't do this with e.g. Node forces all sorts of containerisation yak-shaving on us.

People tried to do this with a few other languages, such as Apache mod_perl, but PHP was the one that thousands of cheap shared hosting providers made available, letting people get started with web development.

I started my career as a php dev 15 years ago, and yes, there was plenty of wrong with php. Messy Api, terrible default, wonky typing, no namespace, etc.

It succeeded, as it's often the case in IT, not because it was the best, or even very good, but because it was easy to adopt and had a killer feature.

> there was plenty of wrong with php. Messy Api, terrible default, wonky typing, no namespace, etc.

"Messy Api" is discussed above ("it came down to people complaining about some function names / param orders as if it were the end of the world") so I won't comment.

"terrible default": would be interested in specifics here

"wonky typing": every scripting language had wonky typing 15 years ago, and many of them still do today. This has never been a valid criticism of PHP when comparing to it's primary competitors.

"no namespace": THIS is a very valid criticism. PHP really wasn't a sane language before they added namespaces. But... they added namespaces 11 years ago.

> would be interested in specifics here

Magic quotes would be the first one I can think of off the top of my head, which incidentally, was made a default because the mysql api in PHP was so prone to sql injections, that PHP decided to automatically escape all user input as a way to protect inexperienced programmers.

Pretty much everyone agrees magic quotes were a bad idea and they were eventually deprecated in 5.3 and removed entirely in 5.4.

"Messy Api" isn't just parameters. For instance "Fatal" errors and regular errors going to two different logs was very messy and would byte you if you didn't pay special attention to it.

Or multi-byte compliant methods that are a variants, and not the standard method, thus biting anyone who just thought utf-8 would be default.

"terrible default": the poster child for this is register globals, which it took ages to have off by defaults. That's just a single line to set it properly, but that was part of the boilerplate that could have been avoided way earlier.

Overall developing for PHP meant to defensively remember a ton a weird stuff, just like javascript was for a while. I am so glad we mostly got past that, even if I am not in PHP anymore.

Fatal errors is fair enough; though I only ever experienced this with parse errors, PHP being stateless did make this less likely to be caught until well into runtime, so it could be an issue.

String encoding though is, again, something other languages had similar gotchas with. Remember we're comparing PHP to its popular alternatives at the time, not to our hypthetical ideal runtime.

The bad defaults you and a sibling commenter are referring to (magic quotes) are, again, from 11 years ago.

Sure, 15 years ago PHP had serious issues, but here we are today acting as if they didn't fix most of them over a decade ago.

> but here we are today acting as if they didn't fix most of them over a decade ago.

Recall that the defense of PHP in this tree leads with "There was never anything wrong with PHP, really."

> The bad defaults you and a sibling commenter are referring to (magic quotes) are, again, from 11 years ago.

That's because the context was the state of PHP 15 years ago.

Php has had some really poor errorhandling and lots of magic. The idea that good error handing is just ignoring it is so wrong, that every update to php is basically a list of “this error will now be presented to you”.

How many scripts continue to prohibit apostrophes in passwords because there used no way to reliably instruct devs on how to handle apostrophes in strings? People named O'Brien still can't enter their names in forms and expect to get it back despite magic quotes being gone years ago.

Nowadays, modern php is conservative but fine. But it was really a terrible choice in its early days, when every one of its selling points was a misfeature.

> How many scripts continue to prohibit apostrophes in passwords because there used no way to reliably instruct devs on how to handle apostrophes in strings?

Thankfully this problem was solved back in 2004/2005, but unfortunately shitty code was already pervasive and the “right way” wasn’t heavily communicated enough.

I have a framework that has a database backend that relied on some default behaviour of count() where if you don't put in an array, it would just return 0 and not error.

Broke in 7.x because it would now warn now... I don't remember what it returns now but that was a thing...

PHP was the MySQL of programming languages and there was plenty wrong with it, mainly the dumb defaults that cause incessant security issues, all the inconsistencies and the habit of papering warnings over errors.

This release is another step in resolving these problems.

> the dumb defaults that cause incessant security issues

The first Java web shop I worked for had a homegrown version of magic_quotes_gpc. That’s when I realized that those who had gone through making PHP installs and apps secure had very valuable experience.

Interesting point! I learned a lot about security due to php. The problem was always that you don't know what you don't know. I recall going back to my first php site from like the php 3 days and I had zero SQL injection protection – I just didn't know it was a thing.

I think that is unfair to MySQL. MySQL is and always has been a fantastic piece of code and to my surprise it has developed and improved under Oracle's stewardship.

PHP has always been a great piece of code as well, there clearly is a reason it is used so much. Like PHP, MySQL used to have stupid defaults though, like silently ignoring errors.

Function names and parameter order matter. That is the difference between having to look something up in the documentation and not. Back in those days most text editors didn't have fancy autocompletion with parameter documentation, if you weren't sure about the order you might have to look it up in the documentation. Having a self-consistent API that was easy to remember was essential. Especially in a language with dynamic types!

When I switched from PHP to Python it was an amazing, liberating feeling for me that I will never forget.

It takes 10 sec to google "str_replace" and have the params presented to you. Using a manual is an integral part of development. I don't think there's many people who can memorize all the methods and their params, including optional ones, nor should they.

That sounds like it takes a lot more time and mental energy than if the API were consistent.

We have machines to do that for us. As in, "press Ctrl+Q, IDE shows relevant help." I don't value encyclopedic knowledge of every API out there any more...especially since those I do recall are of rather, um, limited use nowadays. Like with any language, the point isn't to cram a dictionary into your brain, it's to communicate.

It's a red flag if the basic operations (like string and array functions) are so inconsistent and weird so as to require use of an IDE or constant use of the docs.

Back in the day everyone has the PHP manual downloaded in CHM format (that was before broadband was common). Searching in CHM was just 1.5 seconds away.

Strongly typed languages have better autocomplete since ages, so in Java you would simply type "Str" in Netbeans and you would get all of the ways to create a String or StringBuilder including the parameters right at your fingertip without context switch. No memorizing except the vague notion of "sometimes you want to use a StringBuilder instead of String". Just keep typing code.

You mean statically, not strongly typed. Strong typing roughly means avoiding implicit type coercion.

10 sec every single damn time, for like 4 years, until i switched to other language (ruby). And like google once or twice to remember params in %sanelanguage%

I kept the php docs open all the time. Alt can over, type the function name. But, honestly, you just start to remember all the different little gotchas (at least back in the v3 days).

Python???! Python2 vs python3 is probably the worst thing I have ever seen a language do. Now teams are stuck supporting both versions, new devs are always confused, teams can't upgrade, or if they do upgrade much of their python2 code is useless. The language is now filled with hacky crap: urllib, urllib2, urllib3 and ... AND python is slow.

"That is the difference between having to look something up" PHP (for 15 years?) has had IDEs that fill it in for you.

I am honestly confused how anyone could code themselve up into that python2 only corner. With the release of python2.6 and python3 in 2006, it was clearly described what one had to do to write upwards-compatible python2 code. 2006.

https://www.python.org/dev/peps/pep-3000/

No one had to have any problems with the transition. If they did, they had to willingly ignore the in-your-face documentation on the migration process.

But they did, and they will always do at every turn...

I am not against making something not backwards-compatible. I am in favor of throwing old, bad things away even at the risk of having to rework some stuff... But how crazy legacy is at every damn company is just making it so frustrating. They will happily just wait it out for 14 years and then complain about their Python2 being desupported

> There was never anything wrong with PHP, really.

Looking at the Python standard libs vs the PHP standard libs, PHP used to be a bad mess. Other than that, it's still brilliant.

the biggest point is that people are focussing too much on PHP own quirky edges but then are fine with other languages insanity (I'm looking at you javascript and python). PHP is not perfect and I'm pretty sure it's bad name comes from code written for wordpress or joomla or the guy that came before you than PHP itself. Otherwise I can't understand how Python or Javascript can get away with way worse issues.

what python issues do you have in mind? the linguistic gotchas i can name off the top of my head are:

- the way mutable default arguments are handled

- the weird behavior of closures referencing loop variables

- leaking variables out of if/for/with (yes, i know it's convenient, but can bite sometimes)

- GIL stuff

- exec not being able to introduce new local variables (yes, i know code-objects have their local variables decided at compile time, but it's surprising if you don't care about that implementation detail)

other than that i can't think of many "insane" behaviors that can bite you. i'm curious what you're referring to!

and sure, i'd change a lot of the language to make it more FP-friendly if i could, but being what it is, the semantics seem pretty unsurprising most of the time

Isn't the base indentation style of Python insane ? I remove a "if:" block and and have to press backspace, maybe 100 times ? If I add one "if:" then have to press 100 times on space ?

Yes, nice you can have Python-adapted editors where ident levels can be tuned, but no, it's still a big defect

No, the indentation is a feature.

Your editor can help you with the editing. (And the problem you mention are exactly the same, if you write production code in other language. Your teammates will hopefully insist on consistent indentation in C or Java as well.)

it's never really been a problem for me, i just select the block and tab or shift+tab it as needed. honestly i'd be doing the same in C or whatever braces-based language

> No problem running it completely stateless

It's a problem for some use cases, and even in the web use case, reusing connections to databases and services can be a pain with PHP because it's completely stateless.

Persistent connections are available and if your connection dies the db request will continue next time the page is hit. Although that could cause more slowness issues.

> reusing connections to databases

pgBouncer and ProxySQL are going to give you a better bang for the buck than a stateful web app will.

Maybe. Kinda. Not really.

You can have an awful implementation of a connection pooler, sure, but opening an authenticated socket is more expensive by far than just referencing one.

Less so for a unix socket/named pipe- but still much slower than a memory lookup.

Of course you probably don’t care until you hit a certain scale or number of backend system accesses.

Fetching a connection from a (sane) pool isn't just a memory lookup. Database conenctions have to be cleared of state (transactions, temp tables, prepared statement handles, ...) which takes time as well. Otherwise one runs into "funny" bugs at some point in time.

Unless they're local (and managing that fleet would get pretty annoying), there's still unnecessarily TCP overhead, and even the possibility of exhausting ports.

I'm not arguing for a truly stateful webapp, but the connecting pooling you get for free (or some library wrangling) with a long-lived process does a lot for performance and scalability.

Compare https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ which is not really about the strawmen you mention.

2012. I did agree with it wholeheartedly, when it came out and PHP 5.3 was brand new. It is now 8 years and several major versions later, most of the critique is obsolete and the rest is just "let me try to write horrible code; see, PHP is horrible because it's written in PHP!"

The comment I replied to said: 'There was _never_ anything wrong with PHP, really.' (Emphasis mine.)

Btw, I do agree with most of the changes Facebook's Hack made to PHP.

Oh, ok. There was an immense number of things wrong with PHP. It's gotten to the usual manageable level of $anylanguage.

> Like, it came down to people complaining about some function names / param orders as if it were the end of the world.

Arrays go (needle, haystack). Strings go (haystack, needle). There might be a couple of exceptions but that's basically it.

Higher order functions are inconsistent as well. There are many more examples. The language feels (is?) patched together.

I've been working on a dead simple service to deploy and host Laravel/PHP applications without having to do system administration. https://www.amezmo.com

It was more about certain communities highly valuing "prettiness", such as RoR.

To be fair, there is something to be said about the aesthetics of a language, and Ruby is (at least to me) a far more readable and "pretty" language than PHP. There are a lot of small niceties that, once you are familiar with them, make Ruby genuinely enjoyable to read.

Yes, once you are familiar with. Otherwise, PHP with its generic curly-brace syntax is way easier to grok (I have to work on a codebase in Ruby and the funny syntax + no strongly typed compilation pass makes it really hard for me to get started modifying things).

> and Ruby is (at least to me) a far more readable

It’s funny folks pick on the “Magic” in PHP, yet overlook all of it in Ruby. I’m not a PHP guy anymore really (now Python/Rust/Java/Ruby mainly), but I’m still continually annoyed reading Ruby code. Here’s an example:

- find a method being called on a class, so want to find out details on said method

- grep through codebase, find no definition for said method

- grep through all gem dependencies, find no definition for said method

- search web, don’t find any obvious leads

- cry in despair

- finally find that method is handled by a method_missing on a dynamically generated class and never has anything related to the method name even as a string

- flip desk and go home for the day

Meta programming became far less common in Ruby, I barely see it in Rails apps anymore.

This. And I do agree with all the point parent mentioned about PHP, it is just now I am a lot older I am starting to question this higher value of "prettiness".

At the time of Ruby (driven by Rails) starting to draw people away from PHP I think there was much more value attached to a single "right way to do it" than just Ruby being prettier. In the current world with Laravel and other frameworks in the PHP world its less of a thing, but at the time every PHP application I worked on came with its own half-baked framework coupled together from various libraries, and missing some feature or another. Moving to Rails where you could jump into any application and at the very least understand the fundamentals of where particular bits of code belonged from the offset was a breath of fresh air.

Hell, I maintain an application where the person who originally programmed it reimplented Rails in PHP (except worse)... It gives me all kinds of grief lol

>> There was never anything wrong with PHP, really.

I mean, your listed points are arguably correct, but this sentence is quite incorrect.

edit: downvoted by PHP fans. It's OK, I get it, nobody likes it when others dunk on their favorite language. :)

You were downvoted because your post lacked any real content or rebuttal (and, probably, for the edit - no one likes it when people complain about downvotes).

FWIW though, you're absolutely right - there was (maybe still is?) an enormous amount wrong with PHP. The only real rebuttal core-questions needs is a link to the classic essay, "PHP: a fractal of bad design" [1], which lists far, far more problems than just issues with function names or parameter order, and does it more comprehensively and with more style than you or I could hope to.

[1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

One I always like is people using "mysql_real_escape_string". Well guess what? It comes from mysql itself: https://dev.mysql.com/doc/refman/8.0/en/mysql-real-escape-st...

Lots of "classic" PHP is just thin wrappers of C libraries. Many of the inconsistencies in PHP come from being consistent with those libraries.

Not really. You may be surprised to learn, as I was, that PHP function hashing mechanism was strlen() in the beginning. So the number of characters was more important than naming consistency.

https://news-web.php.net/php.internals/70691

That is for function with no C counterparts. htmlspecialchars() exists in no common C library. The reason strlen() is called strlen() (not string_length() or length() or whatever) however is due to C.

Yes, I was shocked to learn this about early PHP, that function names were hashed simply by their lengths - so names were chosen to fit a specific length. Pragmatic and fast? Yes. Insane design? Completely.

Edit: I can also imagine this design decision must have had context. Perhaps it was a common technique in low-level programming, as a practical way to save time/space.

Given the amount of functions in early PHP (we are talking PHP/FI 2 max here, even userlevel code hardly had functions back then) even not hashing them at all, but doing a linear search over the function table would have been acceptable. Hashing by length most likely lead to few buckets with more than 3 functions.

A "classic" is timeless (cf. Reflections on trusting trust, published in 1984). This essay used to be spot on; with age, it didn't become classic, it went the other route and became obsolete (as it was rightfully critiquing PHP 5.3).

If this is a way of advancing the case that PHP is no longer bad, well, sure. I allowed for that, it may be true, I can’t say. We were discussing whether it was ever bad, which it clearly was. But sure.

On the other hand, if you’re trying to nerd-snipe me into a debate over the meaning of the word “classic”... :)

I’ve gotta disagree with your characterization. At least in the field of jeremiads, surely the criteria can’t solely be timelessness - that’d imply that an essay that successfully inspires change couldn’t be a classic (not that that’s what happened here, I’m not directly attributing anything to anyone). Words are hard to pin down, but I think when it comes to screeds, what’s “classic” could be, in fact, whether it provoked some kind of change - if at the time it won hearts and minds. Or, what’s “classic” could be not necessarily about the specific thing it’s arguing against, but instead about the underlying principles guiding that argument. Or maybe it’s about the style, panache, humour, or clarity with which those principles are argued. Maybe some combination of all of the above.

No one programs with gotos much anymore, but “Go To Statement Considered Harmful” is probably safe to call a classic. America is an independent nation and King George no longer holds the British throne, but nevertheless the Declaration of Independence is certainly a classic text. For reasons of style, persuasiveness, its underlying principles (I think anyone designing a PL should have read it), and its widespread popularity and influence at the time it was written, I think the PHP essay counts as a classic too. YMMV.

Dunk? What you've done is stood on the other end of the court, holding the ball and said "I can dunk this ball" then left the court.

If you've got some counterpoints or arguments, please give them. Going "lol php bad" is just dumb.

Reply on news.ycombinator.com