Posted by Stas on May 21, 2008
So, another “PHP sucks” post, this time from Jeff Atwood. He actually ends up even kind of praising PHP, surprised by its success. I have a couple of thoughts on that topic too.
First, people really need to stop reading something on PHP written somewhere in 2005 (probably about experiences that happened in 2001) and apply it to PHP as it is now, without even checking around for current trends. It’s as if people would dig up books from middle ages saying that there are only seven metals in existence or debating about phlogiston, and would use it speaking about the modern chemistry. Come on!
Then the next thing apparently wrong with PHP is too many functions. Right. Since when? Since when having a lot of functions is a problem? Does it hurt anybody? Does it make writing PHP code harder? Does it make programmer less successful in achieving his goals?
About keywords I could kind of understand – OK, a lot to remember (though I didn’t see anybody really having trouble to remember such complicated keywords as “while”, “if”, “class” or “public”) and it takes out some good English words that could be used as function/method names to confuse the enemy (who wouldn’t want to have function named endforeach() or static(), not to mention function()? too bad those are not available!). But complaining there’s too many actual functions that allow you to do real useful stuff? That is the thing that is bothering people? That is what scares people away from using the language “for years”?
The next beef with PHP is that people write sucky code on it. No, really, they do? Must be something really wrong with this language. It’s not like people write mind-bogglingly sucky code on every other “good” language on the planet. But I get it. The intent was – PHP makes easy to write sucky code. Yes, this is true. As true as “Porsche 997 makes it easy to drive at 100mph into a brick wall”. PHP makes it easy to write various kinds of code – and if 90% of code written is sucky, then 90% of PHP code would be sucky. But my experience says quality of the production code almost never has much to do with the language, but only with the culture – organizational and personal, and with choosing right ways to do the job. The rest is just bad statistics in play. Like “I know 7-year-old writing websites, and his PHP code sucks”. I bet his Haskell code rules though
That’s not to say PHP couldn’t use improvement. It could. And it does, actually – and there’s enough room for improvement still, in many areas. But it probably would never satisfy purists. It’s practical. Maybe it doesn’t allow you to write whole programs in one line of uncomprehensible character soup or play with high-level math theory concepts, but it allows people to write web applications. So they do – so where’s the surprise when one morning somebody wakes up and discovers there’s a ton of web applications around and they are written in PHP?
P.S. I wish for every 50 “PHP sucks” blogs people would write one good RFC.
Posted in Engine, Functions, PHP | Tagged: critique, PHP | 18 Comments »
Posted by Stas on May 16, 2008
One of the things I am doing in course of my work is performance benchmarks for various stuff – PHP, Zend products, applications, etc. Performance in PHP space is currently like alchemy – there are a lot of rumors floating around about various properties of various stuff, but much less reliable data that can be verified and used. PHP has standard bench.php script, but it covers only a small part of what real-life applications do. I wish there were more established tests and methods for benchmarking PHP engine and applications. But benchmarking is a complicated subject, and variety of PHP platforms and applications makes it harder to create useful general-purpose benchmarks.
But more to the point. On Zend Framework lists there was a topic raised about performance impact of Zend_Loader component, which is used for – no surprise here! – loading classes, including autoloading, etc. Some folks thought that since Zend_Loader is executing some code before actual loading the required file, it must cost something. And it makes sense. However, how much does it cost?
Well, the best way to know the price of something is to ask – and in this case, to run the test. So that’s what I did – I made a list of 725 Framework classes (ZF now has more than 1000 but I composed the list some time ago and had also to drop some to avoid some tricky dependencies). And I wrote two scripts – one that would load these classes with require_once and one that would load them using Zend_Loader::loadClass. Both the data file and the scripts are available for download for those that would like to play with it. I tested them with and without Zend’s bytecode cache, to see how much one can save using bytecode caching technology.
So, the results were as follows:
Without bytecode cache:
php5.2 4.42 4.42
php5.3 4.96 4.97
With bytecode cache:
php5.2 63.04 56.62
php5.3 61.28 55.52
The numbers are requests per second, so more is better. Test run on Linux dual 2GHz AMD.
What we can conclude from these?
- It is very important to understand that it is a narrow-point benchmark that tests only one function in one specific way. Please do not draw conclusions on behavior of whole applications based only on this benchmark.
- You do want to use bytecode caching. You won’t get 15x performance on any real application, but it does speed up loading very significantly.
- Without bytecode caching, it doesn’t matter if you use require_once or Loader – both are equally slow
- With bytecode caching, Loader has some overhead – explanation for this is that with file accesses eliminated, require_once of course has little left, while Loader still does a couple of function calls. But on real-life apps it’d probably be very small, provided that it’s about 10% even on loading-only huge-class-list benchmark, and your application probably does something useful instead of loading 700+ framework classes ) Meaning, fears of using the class loader vs. doing require_once are seriously overstated.
- 5.3 is still a moving target, to don’t put too much stake in current benchmark results for 5.3, they probably will be different by the time 5.3 is in release cycle (hopefully, better )
P.S. This post does not talk about other things like “what if I stuff all classes I use into single file”, etc. Maybe next time.
Posted in Functions, PHP | Tagged: benchmark, performance, PHP, zend framework, zend_loader | 9 Comments »
Posted by Stas on May 7, 2008
PHP has a setting named display_errors that allows one to specify if various error messages should be sent to the output or not. It is recommended to keep it off, especially for the public sites, since it may reveal too much information about the application, and looks awful when seen on a public site.
However, for a developer an error report shown in time and place may prove quite valuable and usually is easier to work with then logs, etc. Of course that would mean – keep errors on in development, off in production. OK, then what we do if something weird happens in production and we want to see the errors, but we don’t want others to see them?
ASP has an interesting feature here – it allows you to display detailed error page only when accessed from local browser, but display something generic when accessed from “outside”. Maybe PHP could have some setting like display_errors=local which would enable display_errors for requests originating from developer machine but would disable it when outsider accesses it? Of course, this should be carefully done to prevent security problems, but I have a feeling it might be useful.
This can be done with an extension or even user-defined prepend script, but I think system-level mechanism might help people to use it correctly and avoid embarrassing themselves with publicly-displayed errors while keeping the stuff easy to spot for developers. Would that be useful?
Posted in Functions, PHP | Tagged: display_errors, errors, PHP | 11 Comments »
Posted by Stas on April 13, 2008
I saw in Ben Ramsey’s blog the link to the eWeek’s “100 Most Influential People in IT” list and this:
60. Stefan Esser
Esser’s “Month of PHP Bugs” project thoroughly exposed the insecure nature of the widely deployed PHP language and forced a rethink of security in the open-source world.
I think Stefan Esser is doing great work by helping make PHP more secure, and so I join the congratulations for being in the list. I don’t really know what 60 means – is half as influential as #30 (Brendan Eich, Mozilla’s CTO) and 1/4 of that of the number 15, Linus Torvalds himself – or they just had to order it because otherwise it is hard to comprehend – but I guess any place in the 100 is great.
What drew my attention, however, is the wording of the description. Namely “thoroughly exposed the insecure nature of the widely deployed PHP language” and “forced a rethink of security in the open-source world“. MOPB was very useful in making PHP better, however I do not see how reporting a bunch of vulnerabilities (most of them fixed by the time of publication – for which thanks to Stefan Esser as the responsible reporter) is “thoroughly exposing the insecure nature of PHP”. Bugs and bug reports – including ones that may affect security in one way or another – are nothing but commonplace in both open-source and non-open-source software worlds. There’s nothing groundbreaking or “exposing” – there’s no secret that programs have bugs and nobody ever denied that in context of PHP or made any claim that I know of that was disproved by publishing these bugs.
I also fail to see how the fact that PHP had 43 bugs (MOPB reported 46 issues, 3 of them not in PHP) in various versions and various modules could force anybody to “rethink of security in the open-source world”, whatever that might mean. Just for the right perspective, main PHP source has now around 80 extensions, issue count on bugs.php.net now nearing 45000 (of course, many of them bogus, but still). To compare, Firefox’s Bugzilla counter approaching 430000 by now. I do not know how many of the bugs reported can be thought of as security bugs, especially provided that many bugs not thought of as security problems per se could lead to security problems given suitable context. Probably a bunch of them. But I do not see how that leads to any “rethinking”. Of course it leads to the plain old thinking – how to fix such bugs and try and prevent future ones like them – but that’s how it always worked and always will work, nothing special.
I’m writing this not to cast any shadow on the list or Stefan Esser’s work. I just think while the recognition of the security research efforts is great, the sensationalist manner that was chosen by eWeek to describe it is just wrong.
Posted in PHP | Tagged: eweek, PHP, security | 5 Comments »