PHP 5.3 came out in June 2009. Quoting from the readme:
The key features of PHP 5.3.0 include:
* Support for namespaces
* Late Static Bindings
* Lambda Functions and Closures
I don't know what you are even arguing about.
PHP has a sort of support for types, but while you can say that a function accepts a certain kind of object, you can't express that a particular function takes an int or a string. That's really pathetic. It's fine if you don't want a language with types -- many great languages don't have them -- but only PHP thinks that stupid half measures are acceptable.
PHP has had objects for some time, but it arguably didn't work well enough until their second try.
It's true that PHP makes it very easy to get at elements of the web request, but what I meant was that it is trapped in the content-generation phase. The Apache API is very sophisticated and gives you full control over the HTTP response cycle, but PHP throws all that way, and turns Apache into a dumb teletype. So every PHP script that needs to do authorization is written in this silly inside out way; first you start to deliver content, and then you check if you're allowed to actually do so. Whereas the right thing is to check authentication and authorization first, and then never even call your content script if the user's credentials didn't check out. Apache nicely separates this out with their Authentication, Authorization, and Content phases, but nobody told PHP. Other web frameworks don't have this problem either (I've used some web servlet engines written in Java, and they too avoid the brain-damage of doing it all in the content-generation phase.)
As for daemon scripts, I have no direct knowledge, but there aren't a lot of people who would suggest it's a great language for a daemon. Even fork() can be problematic in PHP. I wrote a system that tried to use it that way and we ran into all sorts of reliability problems (none of which I've ever encountered writing similar programs in Perl).
I may be more behind the times than others, since I happen to have worked on three different PHP projects that all started around 2003-4 or earlier (and are still chugging along). After being bitten in the ass by various broken features over the years, most of them have adopted a very limited subset of PHP (some even refuse to use objects, to this day), and I can see why.
I mean, PHP can be confused by something as simple as loading libraries from different script files. Rasmus' official advice to us was to have one "loader" script that included all the libraries in one shot. I find it hard to respect a language that has difficulties with things like this.
PHP has a sort of support for types, but while you can say that a function accepts a certain kind of object, you can't express that a particular function takes an int or a string. That's really pathetic. It's fine if you don't want a language with types -- many great languages don't have them -- but only PHP thinks that stupid half measures are acceptable.
PHP has had objects for some time, but it arguably didn't work well enough until their second try.
It's true that PHP makes it very easy to get at elements of the web request, but what I meant was that it is trapped in the content-generation phase. The Apache API is very sophisticated and gives you full control over the HTTP response cycle, but PHP throws all that way, and turns Apache into a dumb teletype. So every PHP script that needs to do authorization is written in this silly inside out way; first you start to deliver content, and then you check if you're allowed to actually do so. Whereas the right thing is to check authentication and authorization first, and then never even call your content script if the user's credentials didn't check out. Apache nicely separates this out with their Authentication, Authorization, and Content phases, but nobody told PHP. Other web frameworks don't have this problem either (I've used some web servlet engines written in Java, and they too avoid the brain-damage of doing it all in the content-generation phase.)
As for daemon scripts, I have no direct knowledge, but there aren't a lot of people who would suggest it's a great language for a daemon. Even fork() can be problematic in PHP. I wrote a system that tried to use it that way and we ran into all sorts of reliability problems (none of which I've ever encountered writing similar programs in Perl).
I may be more behind the times than others, since I happen to have worked on three different PHP projects that all started around 2003-4 or earlier (and are still chugging along). After being bitten in the ass by various broken features over the years, most of them have adopted a very limited subset of PHP (some even refuse to use objects, to this day), and I can see why.
I mean, PHP can be confused by something as simple as loading libraries from different script files. Rasmus' official advice to us was to have one "loader" script that included all the libraries in one shot. I find it hard to respect a language that has difficulties with things like this.