5 ms·

"until relatively recently" if by recently you mean 6 years. almost everything else you said is also wrong. op - use what you are most comfortable with and do

by bl4k 16y ago

"until relatively recently" if by recently you mean 6 years. almost everything else you said is also wrong. op - use what you are most comfortable with and don't force yourself into whatever is cool or latest groupthink (Edit: ok you got me.: * PHP's syntax is very random you are confusing syntax with the standard lib, which was inherited from C func for func (which if you come from an OO stdlib can seem 'random' - but it makes elegant sense in the old unix world where CamelCase object names didn't exist) * PHP lacks (or lacked until relatively recently) many programming niceties such as objects, types, closures, lambdas, and namespaces see php5 - 2004. * Even if you can (with difficulty) use PHP libraries in command line programs tons of daemon scripts run php - you are talking about a php3/4 problem (set_script_timeout etc.) see mailchimp post * Although it is almost always built into a web server, PHP doesn't make it easy for you to do anything useful with web requests this is what PHP excels at. want a function to retrieve the hostname from a URL? done. want to send a HTTP header? done. want to parse basic auth? done. php.net/parse_url $_SERVER php.net/header PHP was probably the first http/web aware language, you picked its strength as a weakness. * Since it's a web templating language at heart, PHP practically begs you to do the wrong thing and mix presentation and data. you can say that of any language, implementation-dependent. python and ruby also print to stdout which is just the web process as well. you think this because you have seen more php scripts that mix presentation and logic. * Due to its ubiquity, PHP is the choice of script kiddies who can't program. sigh

ahi 16y ago
As far as I'm concerned, php5 was still broken until 5.3. http://php.net/manual/en/language.oop5.late-static-bindings.php http://php.net/manual/en/language.oop5.late-static-bindings....
- wanderr 16y ago
  We just got bit on the ass by this one yesterday. (still deployed on 5.2)
neilk 16y ago
"relatively recently" 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.
tef_ 16y ago
the syntax seems regular but the grammar for php isn't. this is why you can't do $a = foo(1,2,3)[0] in php. also why this won't happen any time soon.

by bl4k 16y ago

ahi 16y ago

As far as I'm concerned, php5 was still broken until 5.3. http://php.net/manual/en/language.oop5.late-static-bindings.php http://php.net/manual/en/language.oop5.late-static-bindings....

wanderr 16y ago
We just got bit on the ass by this one yesterday. (still deployed on 5.2)

neilk 16y ago

"relatively recently" 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.

tef_ 16y ago

the syntax seems regular but the grammar for php isn't. this is why you can't do $a = foo(1,2,3)[0] in php. also why this won't happen any time soon.