The "problem" is that PHP's popularity breeds more popularity, uninformed choice, and single-language programmers that only know PHP (a real tragedy!). Bashing PHP is in a serious sense a public service if it can reduce any of these outcomes.
I've written web apps in: Ruby (both Rails and Sinatra), Javascript (Node.js with Express), PHP (my own framework, CodeIgniter, and eying Laravel), and been maintenance programmer for a C CGI application. I've written desktop and CLI apps in Object Pascal (Lazarus and Delphi), to CLI apps in Go, C++, and probably a few I've forgotten. I've done Object Oriented, Evented, and to some degree Functional programming. I am a polyglot programmer.
The problem is bashing PHP. As Jeff said, PHP's power is its ubiquity and its near omnipresence. It runs on just about any platform with any configuration, with almost perfect consistency. For the most part there's no switching extensions or libraries because of the OS. Develop wherever... deploy wherever... get almost an identical experience without lifting a finger.
In fact, I have great hope for the future of PHP with 5.3 and 5.4 as they (finally!) have added and improved upon the language, and have begun to cull deprecated features. The problem for PHP right now is twofold: web hosts refusing to upgrade in a timely fashion, and legacy codebases that refuse to be rewritten. Both these are demanding backward compatibility, and slowing the advance of PHP.
I'm tired of the bashing of PHP. Bashing, in general, is the absolute least effective way to communicate your point. At least Jeff Atwood is attempting to do something.
The startup scene's dirty little secret is that (anecdotal from several local companies I've worked for and/or collaborated with) PHP development is fast and cheap. Once you have proven you can solve a business problem and get funding, then you can decide if you really need to do a re-write.
There are just too many small companies focusing on real problems(instead of what language their webapp is built in) to make me think PHP is evil or that Rasmus Lerdorf is a bad person.
Makes sense - There's definitely a pattern of bashing the popular languages.
Reading the article, I was struck by its similarity in structure and language to classic Windows bashing rants of the past two decades - i.e. "the problem with PHP is that it has no taste." In fairness, the call to action is radically different; to build rather than to buy something.
Actually, I think it is exactly because it's popular. All languages have odd ends, but you rarely hear people rant over Pythons lack of lambdas and weird explicit "self" parameter or Ruby's incomprehensible scoping rules. I'm betting that once they fall out of fashion, we will.
And no, I disagree. The main sentiment of the article is negative. It's a call to figure out how to dethrone PHP, but without telling us why this would be such an important goal.
Like Windows 3.1?
Of course that's subjective, and people disagree, but there really does seem to be a real, qualitative difference between the warts on a mostly nice language like Python, and the ubiquitous bizarro world that makes up just about the entirety of PHP.
This is entirely untrue. PHP isn't even a bad language on the scale of actual bad languages. It has some warts but they don't really impede the development of good software. There are many languages that make developing good software nearly impossible.
I don't know about impeding the development of good software. Warts can always be worked around as long as you know about them and how to handle them. But that doesn't mean they don't matter, and PHP has so many that it's difficult to enumerate them.
What other popular languages silently convert strings to floats and then do math or floating-point comparisons on them? What other popular languages have literally hundreds of failing unit tests in their mainline implementation, allowing ridiculous and insecure regressions that were actually caught by testing but never noticed to ship in an official release?
I doubt there's any one wart that's exclusive to PHP. What's remarkable about PHP is how it manages to gather so many in one place. Each one alone is not that bad, but the sheer number of them is astounding.
JavaScript. Most of the "issues" around comparisons/conversions/etc equally applies to JavaScript as it does to PHP.
But PHP does some very stupid casts but it's really just one problem. In the lists of "failures" tend to show that same problem 15 different ways to show how screwed up things are. If your code is well designed and secure you don't encounter these problems anyway.
> What other popular languages have literally hundreds of failing unit tests in their mainline implementation...
I'll give you that. Since that happened, the PHP developers have worked to ensure it won't happen in the future. No platform is free of particularly big security fails (Rails).
For the unit tests, it looks like there are still 100 unexpected failures in the latest release:
http://gcov.php.net/viewer.php?version=PHP_5_4&func=test...
Am I misinterpreting that?
Yes, no platform is free of security problems. But the way a security problem happens is as important as what the problem is. That PHP's unit tests are so noisy that important regressions can't even be noticed even when a test exists to catch them speaks extremely poorly of PHP compared to other languages.
I'm not sure when these where run but it would be easy for someone went through all of them and give them a pass. A failed test doesn't necessarily mean that deployment should be held up. 700 failed tests is a different story.
> JS doesn't have all these other problems, though.
JavaScript has plenty of it's own problems. It has legacy things you should never do. PHP has different problems (not necessarily worse ones) and things you should never do. Lists of the horrors of PHP generally include all things you shouldn't ever do mixed together to make it look much worse than it really is.
I've seen similar lists made for JavaScript (you can get some really crazy results) but that doesn't mean shit for day to day use.
Somebody has to fix them; these things don't happen instantly.
Given the fact that they had hundreds of failed test cases and now they only a few is a significant improvement -- and this is while development has continued. They realized the problem just as you describe; there isn't much more to say about it except they're working to fix it.