From your edit, you've only been working with PHP for about 6 months, so you may not have seen some of the code most others have. Can you imagine, then, diving into a website's back-end to see @ all over? It turns out, the previous developer realized all those nasty notices and errors stopped happening if he slapped a @ on everything. Now your client/boss/friend is pissed because when someone submits their form and they have a space in their name, the entire site crashes, and you have to figure out what's causing it through a tangled web of spaghetti code with no errors.

This is the norm in PHP because, like the author said, it makes it incredibly easy to write bad code.

> If this one thing that annoys me on HN it's the pervasive anti-PHP snobbery.

This isn't anti-PHP snobbery. To write it off as such is an attempt to dismiss most of the (quite valid) complaints. And complaining about someone complaining is really only highlighting your own hypocrisy.

As you said, you really don't understand his need to complain. That's fine, but many on HN do. This was a great write-up for all of PHP's downfalls. Some of it is really only complaining about how PHP isn't Python, but there are a lot of fantastic points about language design and how PHP sacrifices consistency for... really no reason at all. So don't assume every complaint about a language is "snobbery" or an attempt at "streed cred" (wut?) Instead, ask yourself why there are so many people writing so many complaints about this one language. Then, ask yourself why you're writing them off.

I do maintenance for a lot of PHP sites at my job, and the code is staggeringly difficult to debug or modify. It's punishment for my sins.

PHP was a tool for generating textual data structures (HTML) and it should've been leveraged by another tool for control flow and business logic, but it wasn't. The code I maintain is pre-frameworks; it's got no DRY, no separation of concerns, no design forethought at all. It's just HTML generation that satisfies its needs as they arise.

Now PHP is a quirky, mediocre, and capable language that's still really good at generating HTML.

You've turned something that's a person's fault into something that's the language's fault.

Other languages have some sort of warning suppression as well, like Java's @SuppressWarnings or C#'s #pragma warning disable. Although they won't suppress all errors like PHP does, it can still bite you if you don't fix them.

It IS snobbery. You're taking a look at other people's code, and judging the language from it. I've written PHP for about 3 years and I've never once used the @ to suppress errors.

> You're taking a look at other people's code, and judging the language from it.

At some point, you have to start blaming the language for fostering an environment where that code is acceptable.

Not to mention that I have no idea why the original commenter picked on this. It was listed as one of the 7 or so things that can go wrong with that one single, not unusual line of code. It's not like he had a whole paragraph about why @ is bad.

Nonsense. The @ error suppression is a tool, just like any other. It should be used sparingly, but it does have its uses. I have been writing in PHP for over a decade and I have used it exactly one time. And yes, it irritates me when I see it in other's code all over the place ... which is why I refactor all external PHP code before I place it inside of mine.

The amazing thing about PHP is that it has a plethora of tools available and the language doesn't force you to write code in some constrained manner according to what some snob perceives as the right way. The only right way is the way that works and works well.

You don't like a feature of PHP? Don't use that feature. Simple as that.

> I refactor all external PHP code before I place it inside of mine

> You don't like a feature of PHP? Don't use that feature. Simple as that.

I don't know anything about you, but judging from that attitude you haven't worked in many teams. Of course it's not as simple as that. If I had a penny for every time I had to fix someone not checking that strpos() === FALSE, well, I could fund my own startup. You may have the luxury of refactoring all over the place, but the reality out there is that horrible code like this is left to fester until it causes real business damage.

I haven't worked on any teams. I've always written software solo. What of it?

> You may have the luxury of refactoring all over the place, but the reality out there is that horrible code like this is left to fester until it causes real business damage.

Refactoring is not a luxury, but a necessity. Not only do I refactor other peoples' code, but I refactor my own. That's the only way to get to a quality code base.

Well, that means you have zero experience with the majority of concerns expressed in this thread, and so are not qualified to opine on them. You work in a happy bubble and I envy you for it, but in the real world you very very rarely get the go-ahead to refactor old code. So in the real world, you very very rarely get to see a quality code base. In any language, really, but PHP compounds this problem with its idiosyncrasies. But you wouldn't know about that.

But there is a huge difference here. PHP directly encourages it, making it so easy to do "just prefix it with @" and dedicating a part of the core language syntax to it (thus spending such a nice character for such a triviality). I believe (correct me if I'm wrong) that in Java, it is just another annotation, and in C# just another preprocessor directive.

And I think that's what the article is about - so many things are wrong in the very foundation of the language.

To get the same effect as @ you'd have to use try {} catch {} blocks all over the place and leave the catch blocks empty, as with any other language with runtime exceptions. Sadly this is done more that one would think...

PHP programmers have only one single thing in common. PHP.

Is it so wrong to use @? I've always used (@$_REQUEST['foo'] === 'bar') as a shorter way of writing (isset($_REQUEST['foo']) && $_REQUEST['foo'] === 'bar') - I'm curious if there's a problem with that approach.

You'd probably be better off creating a function to do what you want succinctly rather than using the suppression operator.

Out of curiosity, where do you side on the C-is-an-unsafe-evil-language-because-of-pointers debate?

PHP makes it extremely easy to write ANY code. But since article saying "I've noticed this piece of good code in PHP" is not going to get on HN anytime soon, you get much more attention to bad one. That's like saying Internet is the source of filth because it makes easy to post bad stuff. It makes easy to post all stuff, that's the point.

"This was a great write-up for all of PHP's downfalls."

These "downfalls" are known and discussed 1000 times. Really, who needs another article about "PHP sucks because I can find 3 functions with inconsistent parameters"? How exactly it is going to make anything better? What exactly does it contribute to the world?

No. PHP makes it easy to write bad code and between normal and challenging to write normal code. This is why Doctrine, the closest thing PHP developers have to SQLAlchemy, needs three ways to declare table and column metadata: a separate YAML file, a separate XML file, and in PHP comments. All three of those methods are awful, and only one allows you to keep the metadata and class in the same file.

> These "downfalls" are known and discussed 1000 times.

And, like a wiki, it's useful to have them all in one place.

I write code in a number of languages, and there's nothing "challenging" in writing proper code in PHP. The fact that your example has nothing to do with code quality or language only underlines that.

> "And, like a wiki, it's useful to have them all in one place."

Maybe, but that article isn't it. PHP has a wiki: http://wiki.php.net/. You want to list things you want fixed in PHP and have it in one place? Ask for an account and maintain a page there. Rehashing old tired "strpos doesn't have underscore and str_rot13 has, oh noes!!! I can't use language with missing underscore!!!" is really stale by now and doesn't contribute anything new.

Maybe my point wasn't clear. It's not a difference in how those two ORMs accomplish their goal; it's that PHP doesn't let you do what SQLAlchemy does, even if you wanted to. Want to write an ORM that uses YAML, XML, or comment annotation in Python? Great! Want to write an ORM that uses classes or objects as column declaration in PHP? Too bad.

> Rehashing old tired "strpos doesn't have underscore and str_rot13 has, oh noes!!! I can't use language with missing underscore!!!" is really stale by now and doesn't contribute anything new.

Now I think you're just being petty. Obviously an underscore isn't what we're talking about here. Take your straw man elsewhere, please.

I'm actually doing just that; it's not as clean as you can do in Python but it's not outrageously verbose either. Trying to map one languages features onto another is not a valid critique.

Different language has different limitation. Just because you can not have SQLAlchemy in C, does not mean C encourage bad code.

What prevents you from doing that in PHP?

https://github.com/gigablah/fsphinxphp/blob/master/src/FSphi...

Note the $getter parameter.

> Now I think you're just being petty. Obviously an underscore isn't what we're talking about here. Take your straw man elsewhere, please.

What he's talking about here is known and talked about for 10 years. It's just function names, it's not that big a problem. Yes, we know old function names are inconsistent. No, we can't change them because that will break code. If that's what makes or breaks language for you, PHP is not for you, and most languages are not for you, because you're obviously not interesting in solving the problem, you're interesting in boosting your self-esteem by boasting shiniest tool out there. Nothing wrong with it, but PHP is not created for that. If that means for you that PHP sucks, fine, but for 99.99% out there shininess is very low on the list of priorities. So if you want to discuss important stuff, leave old stale stuff like ranting about strpos alone and discuss important stuff.

You must have missed the rest of that paragraph. I specified what it does.

> What he's talking about here is known and talked about for 10 years. It's just function names, it's not that big a problem.

Again, missing the point. Python has these same minor inconsistencies in its stdlib. It's the combination of all these minor inconsistencies with a language that gives you more tools to write bad code than good that makes PHP torturous. It's everything that the author wrote about in one neat little package.

Any old tired issues for you could be something new for someone else.

> So your complaint is that when you use @ to suppress an error it... suppresses the error?

This was one bullet-point from a 7-item list. Also it didn't say that @ is bad in any way (perhaps its use is), it was there only to demonstrate error configuration which is clear by the bullets after it.

> > There is no threading support whatsoever.

> That's a good thing.

You are right that for many tasks not even thinking about threads is a good idea, but there are cases where threads are very appropriate. Having the feature wouldn't hurt, would it? (Considering how tied the php is to C)

> So, it's a problem that array_search returns 0 when something is at... position 0? And returning false is just a sentinel value, much like functions in other languages might return -1. So what?

He explained the "so what" in the next few lines. I'll cite it for you: "If you use FALSE as an index, ..., PHP will silently convert it to 0 for you. Your program will not blow up; it will, instead, do the wrong thing with no warning"

Having a try statement is same as having to check for the value to be FALSE/-1/whatever, we can agree on that. But letting users write code that appears to work (yet it does not) is not a good property of a language.

> Much like Java/C/C++. PHP has array_slice() if you want it.

PHP's arrays are very different (uniform types) from those of C/C++/(Java?). So why compare them? Other than that, I agree, having slice function is enough. The author could've left this one out.

So two of your points were taken out of context, one was your opinion (two if we count your preference of if over try when checking for errors), and only two were probably justified. Rather strange choice considering you had dozens of options.

I still don't see the point that's trying to be made here. Whether it returns -1, FALSE, or you need a try/catch, the programmer still needs to check. To successfully program in any language with an 'index of' function, a check needs to exist regardless...

No, you should not. You should never have error reporting turned off. You should certainly have it set to not display errors to the client, but all errors should be sent to a log, preferably syslog, and they should be reviewed. Your code shouldn't generate any errors.

The settings related to displayed errors in the page are error_reporting and display_errors. The error logging is a totally sperate group of keys starting with log_

Sorry bro, if you have ever put code on production with error reporting on...you are doing it wrong.

In production, you should have error_reporting set to something like: E_ALL & ~E_DEPRECATED

And then:

display_errors = Off display_startup_errors = Off track_errors = Off html_errors = Off ignore_repeated_errors = Off ignore_repeated_source = Off log_errors = On error_log = /path/to/log/file (or syslog)

Ha. Ha ha. Ha ha ha.

Tell me more about maintenance programming and legacy production systems.

It's important to re-iterate what the article is NOT saying. It's not saying that you can't do awesome work in php, there's tons of great counterexamples. It's not saying that you can't change the world with php. It's not even saying that you can't write a maintainable, legible, beautiful app with php.

The problem with php is that the core language ignores a ton of what we as a community have learned about language design: Be consistent. Make it easy to do the right thing. Make unwise code look awkward. Pick a type system and embrace it. Don't try to magically do the right thing. Be predictable. Avoid action at a distance.

It's not that PHP makes for a great beginner language. So does Python. It's not that PHP has flaws, so does every language. Many darlings of the Hacker News crowd even have some of the flaws from this list. But I'd challenge you to make a list a quarter of the size of this one with Python, or Haskell, or frankly even Javascript.

I am confused by why you think this is "anti-PHP snobbery". What about HN's attitude to cold fusion or to VB? How can you tell which criticism is valid criticism from experienced developers about which tools are good and which are bad and which is "snobbery"?

It's not like experienced developers who dislike PHP for being poorly designed and having a poorly managed community is a rarity. It's very common among respected developers. I suppose that to be a respected developer you must conform to the anti-PHP bias? Does the conspiracy go all the way to the top?

Or maybe a lot of these criticisms are valid, but you disagree for your own specific reasons?

More programmers===better programs. How can this be a bad thing?

As far as the snobbery goes, to me it just seems like natural human behavior. People need to believe that their beliefs, their choices are the right ones. For some, the easiest way to do that--rather than being honestly objective or introspective--is to degrade what others do.

There are two ways in which this could be dealt with: one would be for PHP to have a change of religion by the core developers and start a massive cleanup project fixing API warts, adding placeholders to or deprecating the default MySQL driver, etc. This wouldn't be easy but it wouldn't be especially difficult except that the core developers are usually hostile to suggestions that they fix, or even document, mistakes.

The other would be for other languages to start simplifying the learning process - Google AppEngine is probably the easiest intro of all, albeit with a severely non-standard architecture, Rails.app, etc.

I think a language like Python or Ruby is likely to gain a smooth dev server install before PHP becomes less treacherous.

(Pro-PHP flamers: I started using PHP back in 1999. Your arguments are not new.)

- Be able to start and serve in minutes, across most platforms

- Allow for portable code e.g. the code you create locally should be able to be ported over to an actual webhost with only [S]FTP.

- Not require the command line to "work". At all.

I tried to learn django ~a year ago, and it was an experience wrought with frustration and pitfalls. The documentation was so-so, and limited in resources (or I couldn't find it). The main trouble was getting all the packages/dependencies correct. I am quite comfortable with linux and terminal (again thanks to PHP), and though I eventually got it working, I was turned off enough by the whole process that I didn't do anything with it. My accomplishment was that I got it to work, which for me was certainly still worthwhile as I was still learning, but a newcomer would likely have gone back to Facebooking long before that...

What is dangerous about the PHP bashing in my eyes (speaking with some current experience as a newb), is when someone decides to try and learn programming and they google some stuff about PHP and read endless diatribes on how horrible it is. So they go off and try django or RoR, are met with tough situations with little to no documentation; can't get anything to work, and give up all together.

Whether or not PHP is pretty, it is accessible. The divide that is created by language ideology only serves to hurt the community as a whole, IMO.

HN's fascination with cloud computing and massive scalability is not representative of web dev in the rest of the boring world. The vast majority of web sites out there are powered by shared hosting, where the norm is to cram 1,000 sites on a cPanel server. Apache+PHP makes economic sense in this environment because when your site isn't getting any requests, it uses no resources. But if everybody started running a persistent Django or Rails process in the background, or if every customer had to be given a VPS, hardware and maintenance requirements would quickly exceed what the provider can profitably offer.

I can host a small website on NearlyFreeSpeech for $0.30 per month plus bandwidth, even less before they introduced a surcharge for dynamic websites. One of my old clients is hosted on another pay-as-you-go shared host, where she incurs all-inclusive charges of $0.07 per month on average. (The site is mostly static, with a PHP guestbook.) Like it or not, PHP makes this possible by folding the app server into the web server, and a lot of effort has gone into making such an environment reasonably secure without blowing up resource requirements. Even if you use a regular shared host that charges $8.95 per month, that's still cheaper than a medium-quality managed VPS.

The current state of shared hosting might not be anything to write home about, but the low cost (compared to a VPS) allows anybody, including dirt poor students, to run a web site without being held hostage to a less customizable service that might or might not exist tomorrow, e.g. Posterous. I think this contributes to technical literacy and independence in a small but unique way. Any realistic alternative to PHP had better meet the same requirements.

This is the one big problem python has; terrible package management. I can think of 3 different package management systems for python. All of them barley work and the various libraries all require different mangers and different python versions.

This package requires python 2.6. This other package requires 2.5. And now we have separate python 3.x packages. Ridiculous.

See, that's part of the problem. PHP has been terrible for close to two decades. It used to be even worse than what Eevee describes.

Ruby, rails: "rails server" Ruby, sinatra: "ruby <sinatra script>" Python, django: "python manage.py runserver"

All of these spin up an app server on some port > 1024. I'm honestly not sure how it can get much easier than that.

Technically PHP isn't much easier if you need to compile it, configure Apache, etc. but in practice they just pay $1/mo for a crappy hosted account where they simply upload a file and start fiddling.

This is a trivial distinction for a professional developer but there are quite a few PHP users who started with a personal homepage and grew from there – and despite the stereotype, they're not all designers, either. That's why I like the Rails.app idea: give today's bright 13-year-old a nice, easy path to getting something visible and let them get hooked before they need to learn all of this other stuff.

The local stuff was indeed nice and simple.

The PHP crowd is mostly filled with "Internet Programmers" [A person who copies code from the internet and pastes in one's codebase, without even reading it, and expects it to work.] And this also applies to all the javascript programmers who can download a jquery plugin and successfully use it in a website.

They even don't know that you can install PHP, apache and mysql separately and use it. For them XAMPP is all there it is, armed with dreamweaver and a ftp client. Most of them will be lost without cpanel.

I've tried teaching a few but all I get is :"go away don't try to be smart in front of me, I know what I'm doing."

Most of you here are smart people. But out there this is what you get from most of the PHP programmers.

That's the real idea with the principle of least surprise. It shouldn't surprise experts. But programming is hard. It's modeling real world processes in the abstract. That's hard. It isn't going to be simple for people who don't know how to program.

I'm not sure this is true. Going with the articles example, that's like saying "the more people who know how to use a hammer, the better houses we will have".

I think it pretty basic an assumption that the more eyes looking at something, the better the chances of finding (and fixing) mistakes as well as finding room for improvement.

However: I think today we have more beautiful design that we would have had if the design tools had not become democratized, maybe not in percentage, but certainly in amount.

My speculation: programming --> more programs. Both crap and great ones.

I can tell you my reasons: the market. Not all of us can roll a globe, close our eyes, pinpoint a place and tomorrow have a job there. Here where I live, about 80% of webdev jobs are PHP. Even when I do manage to get a Ruby or a Python job, chances are that I will be doing lots of PHP code maintenance and migration anyway. I would like to change it, and I don't know better than to advocate, pro and against.

I'm getting the impression that this is why a lot of people hate PHP - Money. People don't like that the market is full of money wasted on an inferior language. Perhaps there's a bit of envy in that, perhaps not.

The winners in the marketplace aren't always the best, and it's not easy to change minds. People get religious about the things that make their living, whether it be a programming language, certification/designation or some other thing.

But Atheists aren't going to convert many Christians and Christians aren't going to convert many Scientologists.

In the end, you have to work within the parameters of the market or create your own. I guess for some people, like the OP, it's easier to vent. Nothing wrong with that - we should all speak our minds, but it's not necessarily going to be effective in converting anyone.

Look at the resulting discussion here, the OP's either preaching to the choir, or his message is falling on deaf ears. I don't see a lot of 'a-ha, he's right, I'm switching now' posts.

> the OP's either preaching to the choir, or his message is falling on deaf ears.

That was the point of the post. If he points people to it, and they read it but still disagree that PHP is crap, then there's obviously no hope for them.

Yeah, but why would you care unless you're begrudgingly participating in the PHP industry? It's not your problem unless you make it your problem - i.e., if you're so against it, don't work in a PHP shop, don't take PHP contracts. Problem solved - if other people want to use lame/bad languages, who cares?

The impression I'm getting is that a segment people who hate on PHP are participating in the PHP economy because there aren't as many local opportunities in {insert language here}. To me, that's not much different from the guy who's stuck working in a "lowly" coffee shop because he can't find a job in his field of study, which of course, makes him entitled to be rude to customers and his fellow employees.

The money is nice, but after watching the ridiculous waste of PHP idiocy for the Nth time, you can't help but want to get people to stop.

At least with PHP it's likely to be some vaguely HTTP/POST-ish interface, not some XML/WSDL monstrosity...

And, unlike you, I don't think these articles are pointless. I hope they help PHP get more bad reputation among coders, and peer pressure will do the rest.

Bashing and negativity is not the way to do it.

You'll get much farther showing a PHP person something more interesting (whether it be Rails, Django, or whatever) and highlighting all the cool things about it. Because that person will not be on the defensive, his/her mind will be way more likely to have that 'Wow, that's so cool I should try it' moment.

I could not agree with you more. Advising beginner programmers to use PHP is like handing out guns in a playground, someone is going to get hurt, and it will probably be the users.

While there isn't multi-threading in PHP, you can in fact multi-process which provides similar functionality.

http://php.net/manual/en/function.pcntl-fork.php

I've run into these a few times and acquired a bit of mastery of PHP's PCNTL, POSIX and Semaphore/SHM/IPC extensions.

I don't do much PHP work anymore, but I do maintain an OSS library for other people in that situation: PHP Simple Daemon -- https://github.com/shaneharter/PHP-Daemon

This is half-plug, half +2 to your point.

You can always do:

    index = a_list.index(a_value) if a_value in a_list else -1

  if value not in list:
      # value not found
      return
  index = list.index(value)
  # Code to deal with the thing

    >>> "foo".find("a")
    -1

PHP is the MS Word of web programming. It will be here for a long time, just get over yourselves and concentrate on what you write, not how you write it.

* PHP is open source. If you don't like it, change it. Or submit patches. Or bug reports

* PHP does what is says on the can. It's a hypertext preprocessor, and it does this exceedingly well

* If you're having difficulty doing complex work in PHP, you're using it for the wrong problem

The anti-PHP stance on HN is almost meme like. The lack of silly memes is why I respect HN over other aggregators,

Bug reports have been filed and closed for many of these issues.

A full on fork of php might be interesting, though the thought of what's going on behind the scenes in the php interpreter terrifies me.

That having been said, I agree PHP does what it was designed to do, but has been leveraged into pretending to be a general purpose language (much like what happened with perl)... which it is NOT really good for.

If there's one thing that annoys me on programmer forums in general, it's that pointing out PHP's giant flaws is conflated with snobbery. Design matters, and that is not the same thing as saying it's impossible to build anything good with PHP.

This is quite harsh sarcasm, but if it isn't true for the GP, it's true for so many people. Well said.

Programming language critic come up every now and then in HN, this is nothing new. If you got a point, why not refute it?

Are you saying language design don't matter and not worth discussing?

PHP has some wrong design decisions, however many of them don't really matter (like function called strpos instead of str_pos - really, that's your problem?). Some do, and people are welcome to propose solutions for them. People also welcome to write rants about "PHP sucks, nobody should use it, anybody who uses it is an idiot" but they shouldn't expect this will be taken seriously.

When did the original article ever suggest that? I got the impression that he had looked it up in the docs, and found the docs seriously broken. That fits my recollection of PHP's docs - there are a lot of them, but they often don't tell you what you need to know, so you have to go trawl through the comments. Of course, most of the code in the comments is crap, full of errors, has security holes or all three.

> function called strpos instead of str_pos - really, that's your problem?

Yes, that's a problem. Ditto for arguments in random order. It means that it's much harder to remember the function without having the docs open in another window.

"PHP sucks, nobody should use it, anybody who uses it is an idiot"? Sounds about right. I know people who are security consultants, who've worked with PHP for years and years - I even know a guy who works at Wordpress. None of them think that you should be using PHP...

No one in this comment section is saying to you "stop using php on this project you're doing because it's badly designed". No one is in your business.

That is, we're not telling people to stop after they've gone into McDonalds, we're decrying the fact that so-called health experts are telling people that McDonalds is actually just fine for you. That's a better analogy.

Who are you to advocate that? Or to advocate anything?

I despise people who presume to know what's in the best interest of others. You only know what's in your best interest. You have no idea what is good for anyone else.

You want to share your experience? Great. Do it when it's asked for. Nobody asked for a hit piece on PHP.

> we're decrying the fact that so-called health experts are telling people that McDonalds is actually just fine for you.

Exactly which maven and luminary of computer science has advocated the use of PHP?

That is outright nonsense. At no point has that happened. PHP grew organically, without a single endorsement.

Wow. Are you seriously advocating the equivalent of moral relativism in programming? You have no idea if, say, Brainfuck is good for anyone else?

I didn't say that they were luminaries per se. Programmers telling non-programmers that PHP is OK for them is what I'm referring to. That would match the analogy--someone who's studying health science telling someone who hasn't studied health science that McDonalds is perfectly healthy.

Programmers need to stop telling non-programmers that it's perfectly OK to use PHP. Frankly, they need to be blunt that programming is hard. That you either have to willing to put in the investment or don't do it at all. This soft runway into developing applications is exactly the reason why so much poor software exists in the common market.

The original post just can't be sensibly called "anti-PHP snobbery". It just points out PHP's shortcomings. But when all these PHP-users can't really attack the truth, they attack how it's presented instead (and of course whip up some strawmen and generally just try to skirt around the issues).

The human ego is a sad thing.

(Disagree? How about commenting instead of downvoting with self-righteous indignation?)

PHP devs certainly know its shortcomings like JS guys know that languages too. It's not the fact that he points out the shortcomings, that's fine. What makes it snobbery is how the author points out flaws and is so passionately anti-PHP with the subtext being "what I use is superior". He points out flaws in his preferences but in a way that makes it seem like flaws in Python are acceptable but flaws in PHP are never acceptable.

A lot of people who "point out PHP's shortcomings" are really just on a mission to make themselves and their preferences superior. It's a big pissing contest and these arguments come and go like how JavaScript was once despised and now loved.