PHP Sadness | Hacker News Reader

PHP Sadness

phpsadness.com

69 pointsstesch86 comments

Not to take anything away from this post because PHP is a mess, but yesterday I dragged and dropped some PHP files onto a server with FileZilla, opened the right URL in a browser and it worked. No bundler, no docker, no kubernetes.

That was some PHP Happiness right there.

I also like the single-threaded, shared-nothing architecture that PHP inherited straight from the CGI days. Every request is guaranteed to start in a clean state. It's amazing that PHP 7 is as fast as it is even while sticking to the execution model of a shell script.

I wish I could run Python or JavaScript this way without losing too much performance.

Yeah me too! Essentially PHP is a purely functional programming language in the Rich Hickey sense ("If a tree falls in the woods, does it make a sound? If a pure function mutates some local data in order to produce an immutable return value, is that ok?").

PHP is like React on the server side, since the HTML output is a pure function of the request (and external state in eg a database of course). I like to think that it's no wonder that React got invented in a company totally built on PHP. Someone must've complained "I just want to change the URL and rerender the entire page with every user action, not mess around in jQuery". Someone else said "But that won't be fast enough!" and then someone must've gone "Hmm, but couldn't we make it fast enough?"

Actually, the story about PHP inspiring React is totally correct, at least I remember reading it somewhere when React just came out. Also Composer inspired Yarn, the NPM alternative.

Regardless of PHP's warts, Composer is definitely something worth emulating.

One might argue that React is clunky (but I completely get the benefits).

Whereas PHP is a beacon of elegance? :-)

It's almost 2019 and it's pretty amazing that no other language among the dozens available for web development feature easy server-side deployment.

It's frustrating and baffling for anyone who wants to provide users with an easy way to self-install or self-host.

Easy server deployment of apps simply doesn't exist (unless you're Wordpress with one-click installs available everywhere). Many developers consider easy deployment a non-issue.

Here's a previous question I asked on the topic:

https://news.ycombinator.com/item?id=14781420

There are other languages that can behave like this, Ruby ERB templates are one that can be done the same way. You can't just drag and drop PHP without some initial server side configuration either.

The reason it's nearly 2019 and no other language does this is because it's a really terrible way to manage software deployment.

> The reason it's nearly 2019 and no other language does this is because it's a really terrible way to manage software deployment.

I’m not a fan of PHP (the platform), but that sure sounds more like an opinion than an objective truth.

Could you outline some objective reasons why simply copying the code you want to run to the server you want to run it on is a bad deployment model?

Yeah, and that simplicity is also why systems like WordPress, Drupal, etc aren't going anywhere any time soon either. Yes they require an install process and a database setup, but compared to their newer competitors like Ghost, that's a lot more viable for someone with little computer experience than figuring out the command line or what not.

Like it or not, PHP and many applications written in it are more user friendly than many of their alternatives, which is worth a lot more to average Joes than security or code quality.

Unfortunately, the ease of deployment often means lower security. Lots of popular packages expect regular web user to be able to update source code (!), totally defeating any protection OS may provide: https://www.drupal.org/docs/7/install/step-4-run-the-install...

PHP is really nice and easy to deploy, and it would be my first choice for trivial one-file scripts, but I wish people did not use those simple deploy methods on the big internet. The net is not a nice place it used to be 10 years ago, and today, deploying scripts without any OS-based security protection is just irresponsible.

(And yes, it is possible to deploy PHP in the secure way with proper privilege separation, but most of the large, existing projects recommend doing it insecurely)

I agree, I don’t hesitate to use PHP for quick tasks like that. But would I try to write serious software in it? Definitely not.

Thats how i work to and i love it.

Well you could say that for anything that doesn't a) Require 'compose' (as you say, no bundler) - so no dependency management (not ideal) or your code is so minimal it doesn't need any, which isn't the case for large projects b) Require any infrastructure that's hosting the PHP app needing to be configured in the first place. That was conveniently overlooked. i.e. You don't even need to SFTP any files with something like Heroku or PaaS. It's an apples and oranges comparison imho

To me it's amazing how many of these things have been fixed in the last couple releases of PHP. They worked really hard to fix the flaws, and still there's more coming, like property types.

One thing I'm particular exited about is the "Preloading" RFC (https://wiki.php.net/rfc/preload), which fixes one of PHP's oldest weaknesses: That code that is used on every request has to be loaded everytime a request comes in. Sure, thanks to Opcache a file only has to be compiled once, but the loading of the compiled classes into memory still makes for some overhead. With Preloading, if you use a framework like Laravel or Symfony, all core framework classes could be loaded once on PHP startup.

> The point of private methods is to prevent what other code can call them. However, in PHP, you also cannot override private methods in a subclass. This is especially important when, for example, trying to build mocks in unit tests.

You may not be testing the right things if you have to override your methods just for your tests.

Also: many languages prevent all access to private members in derived classes. This is by design: private is private.

If you need derives classes-only to have access, you should typically use the “protected”-modifier.

Doesn’t php have that?

It does.

So the PHP sadness in this case refers to lacking PHP knowledge of the person who wrote this blog?

The problem stems from people believing that unit in unit testing means a class's method.

Yeah you shouldnt override any existing code when doing unit testing, only updating properties if anything... Otherwise you are taking the code beyond its scope, if you need output from a method to be something specific... Just set the variable you are storing that methods return value into to what you need that output to be.

This is nice in theory, but you need to design everything to work dependency injection style (or really have a setter for everything) to achieve this. Using a random number? Store the generator. Opening a file? Use a "FooOpener". ...

Sometimes it's easier just to stub what you want.

Yeah- Sometimes I've gotten lazy and returned an object that has all the private stuff attached. Once I've verified that it works, I quit returning that object, keeping the methods private for normal use. It gives me a clear logical delineation yet allows me to test while developing.

If you can't put the thing you're testing (method, class, application) in the state you want to test using only public methods you are not testing something useful. If you're doing to get 100% coverage be happy: that's dead code you can remove.

Counterexample: Testing something that uses your language's Array.shuffle equivalent which doesn't expose the randomness provider. You can't put it in the right state without just stubbing the call and making it return the order you want.

To be honest, for a 23 year old language, that isn't a large list. With python 2vs3 I could write a book.

One issue:

"The point of private methods is to prevent what other code can call them. However, in PHP, you also cannot override private methods in a subclass. This is especially important when, for example, trying to build mocks in unit tests."

That is called "protected". With protected you can override the method. "private" means it is private to that class overriding - I believe this was concept was extracted from C++.

"In general, you don't want to break any encapsulation for the sake of testing (or as Mom used to say, "don't expose your privates!"). Most of the time, you should be able to test a class by exercising its public methods. If there is significant functionality that is hidden behind private or protected access, that might be a warning sign that there's another class in there struggling to get out."

For me the biggest stumbling block is always the inconsistency in the standard library of function calls.

Without an IDE, I'd be constantly looking up function names and parameter order.

Also, knowing which functions return a result and which modify a passed parameter is also problematic.

I wonder if a case couldn't be made for creating a new "standard library" that would operate alongside the existing one (for backwards compatibility).. A bit like mysql and mysqli....

Fun fact: when PHP was starting off it used strlen() as its function hashing mechanism, that's why function names are the way they are [0].

[0] http://news.php.net/php.internals/70691

They kind of did with the SPL.

I haven't coded without an IDE in 8 years. SO this is not an issue.

The same can be said about Java, nobody would write all that glutter without an IDE...

I use vim exclusively and tbh i would love a solution for this. it seems there are plugins for that, but i wonder whether they could become part of the official vim package.

Maybe just use a real IDE? Not sure why so many developers insist on hampering themselves for no good reason.

i m honestly faster with vim , except for the times that i need to switch files etc.

Nowadays I do mainly PHP7.x / Symfony projects and of all this list I would say only "ternary operator associativity" could potentially be a day to day concern, and yes, empty() has gotchas.

Nothing listed is false, sure, and I'm sure there's people doing complicated things with clever code like "declaring a function called __lambda_func() (which) completely breaks create_function()" but I have not encountered it in the wild, or not for a long time.

Frankly I have more problems with Composer memory allocation in VM/containers than anything on this list.

Yeah, yeah, more PHP bashing. But PHP has very nicely cleaned up since oh 5.3 or so and with every release it's getting better. For example, to bemoan "Declaring a function called __lambda_func() completely breaks create_function()" completely ignores the fact noone should (or does) use create_function() since the introduction of proper closures. http://phpsadness.com/sad/2 is made up too, just use a constructor. There truly is no problem with PHP any more if properly used. Yeah we can rehash the arguments from the last twenty years but instead -- have you seen the language where the community and culture is so fractured someone could sneak in a bitcoin wallet stealer without anyone detecting it? The language which insists that the completely different concerns of backend and frontend development should be done in the same language? Now, that's what ridiculous!

Not sure if that's intentional, but take notice of how you're fighting for credibility for a language with bad reputation by comparing it to the one other language with similarly bad reputation :P

Generally speaking, if you expect the world to (as a first class principle) cater to your personal desires you will always be sad.

I didn't read the whole thing, but I'd be interested if anyone found any issue that doesn't have a workaround or can't be polyfilled to cater to this guy's expectations.

Edit: "reasonable" expectations. Requiring semicolon at end of line? smh Write your own editor plugin that inserts your semicolon (or write a preparser). PHP folks only wrote an entire language for the world to use for free. The least you could do (if it's really that big of a deal) is write a preparser.

Some of these are good points, but the error reporting ones are a bit pedantic.

Sure stuff like "T_PAAMAYIM_NEKUDOTAYIM" is confusing the first time you encounter it, but after your first week of PHP you're going to have seen it and know what it means. PHP has many flaws, but for me, error reporting isn't one of them.

That name is one for errors. I liked it since it was Googleable. Unique names have benefits.

If it was simply T_DOUBLE_COLON that would also be googleable. Even better, you wouldn’t need to google it since it’s not in an obscure foreign language.

Agreed, here is another one to file under "not a big deal": http://phpsadness.com/sad/46

I recommended Python with a math library to my friend to try as a replacement for R (and for server code running a project's backend data processing). The amount of effort and time spent trying to get it up and running was ridiculous.

R's syntax is very unpleasant for both of us, but it really gets the job done. Php isn't nearly as bad as R, and I've seen this kind of criticism of php for years.

What is the perfect language I should use then? Can't a list of "bad things" be made of any language? (maybe not the same problems, but there's always something)

It’s true that deployment is more difficult on Python.

Comparing R to PHP seems kind of inappropriate since what they are appropriate for rarely overlaps. I wouldn’t use PHP for statistics and I sure wouldn’t use R for a website.

As far as whether other languages could have similar criticism, no. This is an analysis of sloppy design at the core of PHP. The types of problems listed aren’t found in Python or Ruby because they planned the language better in the first place and have a better process for dealing with intelligent changes. It’s maddening for me to read what PHP developers think about changes to the language. If you want to use PHP, go ahead, but I don’t think that’s the point of this article.

>This is an analysis of sloppy design at the core of PHP.

I understand this, but the source or reason for the "bad list" doesn't change the fact that every language has something off. (just a matter of degrees)

Also, php did something so right that even despite all the ugliness and problems it's used a lot.

I think php should suck it up and make a branch to fix all of these things and let people slowly change their apps over. I have gone through a lot of rework over the years, what's one more change for better future?

Sure, it’s a matter of degree. PHP has many worse degrees than the things ‘wrong’ with Python or Ruby. Nobody said a language has to be perfect, just better. Of course other languages have flaws, but Python and Ruby have fewer and less serious flaws.

It’s like if I said hey, we should live somewhere besides Moldova. And you said but don’t Germany and France have flaws too?

As far as what they should do, yes, they should fix all of these problems. The thing is many would break huge amounts of old code and cause problems for people and harm upgrade adoption. Also, PHP developers, as seen, actually insist on things like ‘=> is better than : because it’s the PHP Way’. I’m not going to waste time trying to persuade the heathens behind PHP to turn it into a normal language. Why would I? My opinion is that PHP is a fundamentally braindead language. It’s like someone tried to make a quick and dirty scripting language with C syntax and then changed it over into a crappy version of Java with the help of a bunch of incompetent college students over 10 years for an audience of amateur programmers, which actually is exactly what happened. I have no desire to use it for anything, ever.

Your argument reminds me of a debate I ran into about using pocket hole jigs. The experts would make hand carved mortis and tenon joints and consistently attacked and ridiculed pocket hole jigs. And said no professional would ever use pocket hole jigs.

Ikea does a lot of business and I wish they'd use pocket holes on their furniture instead of some of the ghastly connectors that fall apart.

Getting things done and running a business are primary goals of software... There was a time when mysql was ridiculed mercilessly as well.

You’re right about some aspects and I am about others. PHP is good for certain projects. MySQL works well for some cases. However many experienced people prefer other tools for good reasons.

Personally I grew weary of having this conversation about PHP and MySQL about 9 years ago (you’re aware of this long history, right? This is like talking about the reasons for the civil war). Nobody needs to point out that WordPress is build on PHP, or that Flickr used it, or god forbid Facebook.

The strengths and benefits relative to other software has been debated to death in blogs, articles, forums, and mailing lists for a decade at least. I doubt we can break new ground here.

Haven’t visited your website but I visited your profile. I’m assuming that you are writing a CMS in PHP?

I generally agree there's probably no point in discussing this without an end game. So here's one:

Do you believe that python/ruby/go/node.js/etc.. can replace php and do a better job?

I haven't heard a recent apples to apples comparison, and the ones from the past have faded in relevance because of improvements made in php. I suspect that is because there are business reasons php runs circles around other solutions, and that technical superiority doesn't mean financially superior. (how many key google products run on javascript?)

If php is going to go away, it needs a jquery moment like this:

http://vanilla-js.com/

I am actively gutting all jquery from all my projects because it truly needs to go away because something better came along to replace it. I haven't seen that with php yet and I have looked because I want my business to stay running and not fall behind because of a poor platform choice.

Of course I believe that Python (etc) can replace PHP and do a better job. Isn’t that the entire topic? There’s no question in my mind whatsoever. I stopped using PHP in favor of Python in 2011 and would not consider reversing that under any circumstances. I’m quite experienced with both languages and PHP utterly lacks elegance. It’s not even close to something I’d consider using or supporting. Not sure what your perspective is based on.

I mean, I’d never consider eating at McDonald’s under any circumstances whatsoever, but somehow they stay open and people appear to patronize their stores intentionally. So, tastes vary. If you like a bunch of dollar signs, semi colons, illogically arranged standard library, endless inconsistencies and poorly thought out syntax, don’t change a thing.

Where is PHP popular? Or standard? I’m not even sure what you’re referring to. People still use PHP?

Hmmm... https://www.codingdojo.com/blog/7-most-in-demand-programming...

Okay, so it’s way behind Python, JavaScript, C# as far as common web programming languages. Beating Perl. Sounds about right for something as outdated as PHP.

My recommendation to you is to hurry up and learn how to setup your web server for Python.

https://hackernoon.com/top-3-most-popular-programming-langua...

Here, Python is noted as surpassing PHP in popularity in 2017. I guess that was the stack overflow survey. This is based on searching for 1 minute.

I am interested in making good choices for my business so I am taking your feedback seriously.

-Popularity:

I don't think it's wise to choose your platform on popularity. The masses make terrible choices all the time. But at the same time I found numbers as high as 80% of the web is running php. (numbers can vary based on metrics, traffic running php vs number of sites)

But then python is way less popular than javascript, so if I would accept your argument on popularity shouldn't I use javascript with node.js?

-Standards:

This is a more appealing argument to be made. But unfortunately I make custom software for running websites, the standard is the output, html,css and js. The backend is irrelevant to my users. This would only affect long term maintenance, of which I am not seeing a jquery moment here.

Care to elaborate on why php is going to cause long term maintenance problems or how it's non-standard in some way?

-Python can do a better job than php:

I did a couple quick performance searches and just in the past couple years php7 has made huge improvements in performance. What this says to me is that php7 is being improved consistently.

Does python run websites better than php? If so, in what way? I couldn't see a clear answer for this.

Also, since my customers never see or touch either python or php, I am not sure how I could judge if python "does a better job" for my customers.

-Php is outdated:

What is your metric for measuring something is outdated? I am not sure this is possible with a programming language this is actively being improved and used. Is this a popularity argument?

-Php is like McDonalds:

While I don't eat at McDonalds, I can easily say that R is nasty to code with, yet I am just fine dealing with it's idiosyncrasies because my friend does the majority of the coding with it, and I help with cleanup and integration.

And python simply is not better enough (or at all) than R in every respect for math processing. (this is from testing results from my friend who does math/data analysis/statistics) It may be equivalent in some ways, but certainly not better.

-Php is messy:

The "bunch of dollar signs, semi colons..." argument would fit with javascript as well (especially when mixed with libraries), so your arguments are conflicting some.

Would my customers be better served if my codebase had a more simple syntax? I am not sure this is even possible. But I am willing to hear arguments on this.

You’re all set if you like what you’re using. I appreciate that you’re thinking this through. I would prefer a language that was designed intelligently from the ground up by experts, like Python. PHP seems to be gradually emerging as a good design through trial and error, which is valid I suppose.

=> vs : is probably the least important thing you could come up with when comparing two languages. Yeah the syntax is different, so? It's a different language, not all have to use the syntax you are used to.

That is exactly my point, the "worst" thing I deal with with php is mild annoyance.

Well to be fair, R has always had a good installation story (and CRAN is super-stable), while Python is notorious for issues with packaging (easy_install, pip etc).

It sure does. Which is odd that this alone is a reason I'd use a poorly structured/designed language than a well laid out one. Maybe a similar reason why php also is used over other options? (from a slightly different angle)

Absolutely. Even the highest ranked comment here now says so.

The saddest part is that there is so much PHP code out there and it's mostly really bad code. Even Rasmus isn't happy about it, you can watch his presentations on state of PHP on youtube. PHP was meant to be a simple templating language for HTML, and it failed miserably at that, which is why almost every PHP framework out there invents another one.

>PHP was meant to be a simple templating language for HTML, and it failed miserably at that

I would argue that it was too good at that, instead. It was so good at being a real language that people didn't just use it as a templating language and it grew way, way bigger than initially intended.

When I see PHP templating libraries, they are all focused on restricting the programmer from doing supposedly stupid things. They try to prevent logic from leaking into the templates and utterly fail at it.

The problem is, the templating part is what PHP is bad at.

That the programmer has to manually escape everything because PHP doesn't actually know what HTML is, or else find a templating framework that does it for them (like any other web-facing language), kind of demonstrates how badly PHP fails at its "one job".

PHP has a lot going for it, but HTML templating isn't one of its strong points.

On the upside, though, package management is sane and distributed by default, and left-pad wouldn't happen in PHP-land.

I used to be in contact with a licensed/bought piece of software written in C++, PHP and Perl, using Mongodb as a database. It was about as much fun as it sounds. Segfaulted twice a week.

I suppose at some point they'll make a plug-in system written in brainfuck.

One that was missed is the change in the way that the count function operates on a null value, its breaking backwards compatibility.

The only way to solve it is to write your own count function and call it everywhere instead.

Another problem is, if for example you are checking for a url variable to see if it exists, there's more than one way to do it - and only one of those ways is performant. Why have a special function that checks if a key exists when its slower than just checking if the entire variable exists?

I've since moved on to C++ and go, but the ubiquity of php on web hosting will bring me back to it again.

Reminds me of https://twitter.com/ircmaxell/status/984785734811963392

One can sort out a lot of PHP parameter order inconsistencies remembering that if $haystack is an array then it's the second parameter after $needle. For string it's the opposite.

    array_exists($needle, $haystack);

But

    substr($haystack, $needle);

You're probably thinking of in_array() and strpos(). Yeah, the names themselves are confusing, not just the order of arguments.

I wish PHP was fully object-oriented so you could call a method on any array, string, or number like in JavaScript. $haystack->contains($needle) is so much more consistent! That would eliminate the need for most of those confusing global functions, which can then be safely deprecated.

This is good!

It's not one of those "LOL! PHP is so stupid!" articles.

He even took the time tagging which sad points are solved in newer versions.

Yeah, this guy actually PHPs, in contrast to most of the "php is so stupid" people

Again jokes about PHP? It's kind of old.

What's the joke?

Looks like many of the issues got fixed.

the inconsistent order of arguments is infuriating, but that has to some extent been inherited from C

Honestly, if you use PHP you should expect sadness

PHP has also its upsides:

- High-quality packages (e.g. FlySystem or anything by https://thephpleague.com/)

- Very nice and mature frameworks such as Laravel.

- Pretty good OOP features

- No concurrency / async, which makes thinking about the code way easier than sometimes in Node.js

- There are high quality packages in every language.

- Likewise with mature frameworks.

- All mainstream languages have pretty good OOP features nowadays.

Thankfully yes, there is no concurrency.

what has the world come to be, where a series of commands actually running like a series of commands is hailed as an upside.

Same world since Multics.

No concurrency is a missing feature, not an upside. OOP is a broken paradigme, so no upside to be found there either.

> No concurrency is a missing feature,

That's an opinion that isn't very popular or useful.

Ignoring the multithreaded PHP runtime and fork functionality, implementing every feature (whatever user X particularly wants) in every language will never happen.

Saying OOP is a broken paradigm is irrelevant. Some people prefer it and they are users just like you, but different too.

Meh, I get paid for working with PHP. While that's not the only thing that matters, it's a pretty big thing. If that list sums up the worst of the language, I can deal with it.

Except the ternary operator thing. That gets right up my left nostril. I LOVE the ternary operator.

A day without using a ternary operator is like a day without sunshine.

Let us your language of use... My guess is that there is sadness there too

Ahh, nothing like a bit of language shaming.

For me the biggest PHP sadness is always type coercion. ‘1’ and 1 are different things. And coercion into an array when you suddenly use [] is just insane.

It only appears to be "insane" if you are not used to working with dynamically-typed languages. PHP has been dynamically-typed from the very beginning, so you need to program defensively and check type at runtime (no assumptions are safe).

These days I do 99% of my work in Python3 and JS/ES6. PHP is still the most insane version of this, though JS isn't far behind.

Make the jump to including TypeScript in your toolchain, even if you don't ever intend to write any TypeScript.

The type checking it does on regular javascipt is still beneficial in catching and preventing a lot of coercion mistakes or attempting to accessing things that are potentially undefined.

Reply on news.ycombinator.com