The problem is that people go too far with the bashing- People tend to just sneer at anything PHP-related, and don't acknowledge that great work is being done every day in PHP. An app written in PHP by a 8/10 programmer is going to be better than an app written in (sexy other language) by a 7/10 programmer.
> An app written in PHP by a 8/10 programmer is going to be better than an app written in (sexy other language) by a 7/10 programmer.
Depends entirely on your metric. It's far too easy to introduce subtle bugs, especially security oriented ones, in PHP. If I had a dollar for every XSS, remote file inclusion, CSRF, arbitrary file read, etc vulnerability I found in a "good" PHP app, I'd be a very wealthy man. Some things are mitigated by using a good framework, but in most cases people get them horribly, horribly wrong.
Oh, absolutely! Except that they're more prevalent in PHP applications than anything else. It's simply way, way too easy to do the wrong thing. If you want to introduce XSS into, say, a Rails app, it's significantly more difficult; generally, you have to explicitly throw something back as 'raw'. Sure, some PHP frameworks handle it the same way, but it's rare to see this in the real world.
While testing apps, PHP immediately throws up red flags -- it's simply not likely to be done right. It can be, but it's very rare.
That happens in nearly every language which is famous and widely used. I have seen awful Python code in the past. So bad that it would have led me to hate Python, so bad that it would have forced me to believe Python as a language sucks.
But by now I am mature enough to understand that if you hire bad programmers you get bad code irrespective of the language its written in. You can use any tool you want, if you use it badly the result is going to be bad. These are days of Python and Ruby fanboyism so very obviously everything is going to look ugly in front of it. Code bases in other languages will be declared legacy and the same thing will be translated to the new shiny language and called the 'modernized' code bases. Your RDBMS use cases will be shoe horned to NoSQL databases and declared designed for the web. This will go on and on for anther few years...
Until we get to see page long blog posts another few years from now describing how many bad Python + Django examples can be found on the net. Or how bad Python and Ruby Legacy codebases are. How framework dependency with Django, Rails or Twisted sucks. Or how someone had to spend huge engineering effort migrating from Python 2 series to 3 series. Or how they had to rewrite a large part of SQL logic to work with NoSQL databases.
This trend repeats every few years, every few years a set of tools get trolled badly.
Everyone always makes this argument, and yes you can write bad code in any language. That's a truism that contributes nothing to the discussion.
Now which languages make it easier to write more good code? Everyone talks about the lack of good PHP code and the response is "well there's plenty of bad python code out there!". What we will never see are any examples of PHP code held up as being great a few years from now.
Yes, every few years a set of tools get trolled badly. The same tools that were considered sub par by professionals at the time.
I'd like to think that the apparent security weaknesses in many PHP applications could be attributed to the fact that PHP was already around back when web security practices were more primitive.
Thus, in your career you tend see more PHP apps that were badly-implemented.
Agreed. The older a PHP application is, the more likely it is to have incredibly serious security vulnerabilities. But I've looked at and broken plenty of vulnerable applications that were written within the past couple years.
Rails is a framework. PHP is a language. If you use a framework with PHP, it's just as easy to avoid XSS. Likewise, if you use vanilla Ruby without any framework...
daeken is arguing, based on quite a bit of experience, that PHP applications (even those written with frameworks) tend to have more security vulnerabilities than Rails apps. I happen to agree with him.
One very illustrative example: arbitrary code execution. I've lost count of the number of arbitrary code execution vulnerabilities I've found in PHP applications. In contrast, I recall very vividly the last arbitrary code execution vulnerability I found in a Python application: I uploaded a PHP script to the server, which was also running mod_php. ;-)
The problem here is simple: most web servers that run PHP are configured with a rule that says "If a file ends in .php, execute it as PHP." This is useful for new users: it allows them to run and execute separate PHP scripts very easily. But it's also a potential security vulnerability if an attacker can upload a PHP file to your server.
If you're using a framework, you typically have a fixed number of scripts that should be executable and you can configure your web server appropriately. However, that requires a VPS or dedicated server.
Edit: If you're interested in an actual language-level difference between PHP and Ruby/Python that affects security, PHP scripts accepted null bytes as part of filesystem paths until recently (PHP 5.3.4, which added protection against it, was released at the end of 2010).
I'm not disputing any of that. I just get annoyed when people compare languages with frameworks. Ruby and Python have many advantages compared to PHP, but out-of-the-box XSS prevention is not one of them.
Rails is a DSL based on Ruby to build web applications that has hooks into a rich library that helps with that. PHP is a language designed to build web applications (although it can be abused to write any type of application)
