Your comment pisses me off, but there's something I want to say all the same: I think you are, essentially, right. Whatever one's woes with PHP might be, they don't justify trolling and unsubstantiated mouthing off. Besides, "toy language" is a purely inflammatory statement that doesn't even have any factual content.
However.
However, the implicit underlying assumption I think I perceive in your comment -- that PHP criticism must be trolling -- annoys me a lot. Please allow me to expand on this.
You see, one constant characteristic of the Internet in general is the noise. Look here on Slashdot: do you read all the comments on any given story?
The noise is a bigger problem than you'd think. The noise means that it's hard to get heard. It means that to be heard, unless you're a remarkable writer (which I, and most people, aren't), you have to exaggerate your message. "PHP is a toy language" is one such exaggeration; and perhaps even actually worthy of being modded up if followed with factual information to support it. And much likelier to catch a moderator's attention with its use of strong language.
Which you would, undoubtedly, consider a troll all the same, wouldn't you?
As you can probably guess by now, I have crates of such information against PHP. (In my defense, I do try hard to gather evidence against my own tools of choice as well, for two reasons. One, being aware of their own idiosyncrasies allows me to work better with them. Two, it's a simple matter of intellectual honesty.)
The vagaries of life have landed me into a managerial-ish position in a small company that develops and hosts large-scale PHP websites. My responsibility here is twofold: ensuring that the sites work, and ensuring that they keep working.
I didn't know PHP before joining this company; I had a generally positive opinion of it beforehand, from reading Slashdot. So I got to discover it through that new role.
Let us just say, to put it mildly, that my opinion of PHP has quickly become very poor.
I think that managing a language's design and development is one of those jobs that's freaking damn hard. It takes a LOT of experience, critical thinking, introspection, knowing to prioritize issues, knowing to tap into the decades of experience in language design to understand what works and what doesn't, why, and in what context. And different people with different backgrounds and objectives are more or less successful with it.
And I don't feel the people behind PHP -- I'm sorry, guys, I don't know how to put it nicely... -- are doing the best possible job of it.
More precisely, my primary issue with PHP is its culture as a project. Cultures are inherently difficult to describe, but if I had to put it in a few words, I'd call it the "Works for me" culture.
Simply put, the sort of attitude that PHP seems to encourage -- by which I mean, the shortest-path-to-arrival approach to doing most things in PHP -- work fine for the developper producing the code, but are formally broken in a way that WILL come back to bite the ass of whomever poor dude is in charge of keeping the thing working.
For instance: I understand PHP uses a function based on the tolower() C call to make method calls case insensitive, and leaves it at it. It works for them, doesn't it? Except that in the real world, it breaks. Deploying PHP sites on servers that use a Turkish locale yields blank pages. The workaround is to never use that particular locale. Easy, isn't it? No, it isn't: PHP's gettext functions for dynamic translation require the locale to be set appropriately (unlike that of other languages). And I have my Turkish clients on the phone a lot.
Until recently, before the introduction of PDO, the canonical native way of addressing databases was to use PHP functions named after the database itself (mysql_*, etc, making the process of migrating databases, or creating a site that may have to be deployed client-side on varying database backends, an utter pain. The current canonical way still doesn't proactively encourage the use of prepared statements, that would yield better performance and forbid entirely SQL injection attacks. (But the current way "works for me", doesn't it?)
PHP STILL doesn't have namespaces. Why does this matter? Well, for instance, had PHP put the HTTP request data into its own namespace, the whole register_globals debacle wouldn't even have been possible. Good engineering practices are no silver bullet, but they do ensure that whole classes of problems simply can't happen. I think this is why the "Works for me" culture tends to fosters projects (and I don't mean only PHP, here, mind) with recurrent security issues.
Unicode support has been problematic; and by this I mean I have two major problems with it. Firstly, the lack of a native Unicode type means you can't carry around a known-good string that you can pass around or retrieve from an third-party, and only convert back to the requested encoding. Why does this matter? Well, most PHP functions break hard on UTF-16 encoded byte arrays, which contain zeros. Secondly, whenever you raise this issue, the common answer is, "What's wrong with the mbstrings functions?" And THIS is what I mean by a cultural issue: the assumption that because mbstrings "work for me", they're a suitable solution. This is not a technical problem at heart, folks.
And there's the problem of backward compatibility, which is never a granted, and makes the job of keeping production servers up to date a nightmare. There's thread safety, there's syntax bone-headedness that probably stems from PHP's lack of a grammar, there's the inconsistent behavior depending on server-side settings that you may have no control on, etc, etc, etc.
All of those make the management of large-scale PHP projects an incredible pain, and it's all the more embittering that a large chunk of it could be abated by good freaking engineering practices.
I think this is what people mean when they call the management and design of the PHP language 'amateurish'. Blatant lack of good engineering practice. I do disagree with the word amateurish itself, though: the fine guys over at Zend are professionals, and making good money off their language, which is one of the most widely deployed on Web servers. They're without contest professionals. Just, professionals with poor engineering practices.
The thing I can't forgive PHP, however, is that due to the way it encourages and rewards (at first) shortest-path-to-arrival approaches, it teaches beginning programmers everywhere that it's okay so long as it "works for me". That it's okay not to care about good practices so long as it works. That it's okay to embed SQL requests right in the HTML templates. And, due to PHP's lack of introspection and metaprogramming, that other approaches are a lot more work and not worth it.
And THIS is what people mean when they unleash Dijkstra's ghost onto PHP.
Granted, designing a language where the easiest way to do anything is correct and robust one, while keeping the flexibility and development speed of an interpreted and dynamically typed language, is extremely difficult. Is that any reason not to try, though?
So, yes, after more hours of nightly overtime than I care to count, after salvaging several expensive PHP projects for large companies that where unmanageable messes, I've come to hate PHP, which I consider a character flaw in me. PHP is just a language; that should warrant an informed opinion -- which I like to think I have -- but not an emotional reaction.
And this, in the end, is why I wanted to post this: your comment annoys me a lot, but I think its sentiment is, at heart, correct: emotional reactions to technical issues shouldn't supplant informed discussion.
And this goes both for the PHP-hater and the PHP-lover side.
All of my criteria? None. That's my point. There is no technology that doesn't deserve its share of criticism. (Actually, asking people what their preferred tools' most important drawbacks are is generally a good litmus test for their competence. If they can't tell you what the pitfalls are and how to work around them, or why they don't affect the task at hand, watch out.)
Simply, some tools are a better match than others for any given task.
For instance, I think that PHP makes for a good, simple and effective
It has deep-rooted support for meta-programming and introspection. Namespaces are simple and straight forward. The re-occurring interfaces in Python shave down development time and encorage uniformity.
Using Python is actually a pleasure. Mind, it does have its flaws: Performance (which is about on par with PHP), populatity (not deployed as much as PHP), and some OOP querks (but still better than PHP's).
I think this is what people mean when they call the management and design of the PHP language 'amateurish'. Blatant lack of good engineering practice.
Totally agree 100%. Another example: did you ever use nl2br() [php.net] to convert newlines into <br> elements? It's an extremely common thing to do. In a minor patch release, they changed the function to generate XHTML instead of HTML. In one stroke, everybody who thought they were generating valid HTML had errors in their code. This might not sound that bad, until you realise that nl2br() can appear a lot in large projects, there's no way to get the old behaviour of nl2br() back, and if you have a decent QA process in place, you'd be being notified of the errors across all the websites you maintain. You end up having to go back and change all your code to use generic string replacement functions.
Now, maybe you might say that it's a sensible thing to change (I disagree, there should be different functions for HTML and XHTML), but at the very least, they should have put a change in semantics in a major version update, not sneaked it in between 4.0.4 and 4.0.5.
It's not really the design of the language that's the real problem (although it's not pretty), it's the cavalier attitude from people who don't seem to take a professional attitude to their work that really grates.
Amen to the cavalier attitude. You know about PHP's Javascript-esque === operator? (that's the one with three equals signs). That got designed on the spot in an IRC session with Zeev and some other devs. Because I actually had to explain to these folks what the concept of "object identity" was, i.e. what lisp does with 'eq', python does with 'is', and Javascript does with ===. Yes, because PHP's is different. Not only does === fail to do object identity testing, it's simply '==', does all the "deep comparison" of ==, but also bothers to compare the type.
In other words, I was unsuccessful in explaining this rather basic concept. They got it blisteringly wrong, and hacked this wrongness into the language for all time. I attempted to explain (much more patiently than here) that no, this is not what === is supposed to do, but I wasn't heard. Not by Zeev, not by anyone else on channel. No one got it at all.
I passionately hated PHP for a long time after that, but it's just not relevant enough to my work anymore to hate. I have choices, I don't have outside clients demanding I use PHP anymore, and my choice of languages is respected where I work. I've chosen python for some projects, perl for another, C++ for another (the C++ one was of course not web). I could probably write my next project in Haskell and no one would bat an eye (though I will be stuck with maintaining it for all eternity). I'm even eying Prado -- a PHP library -- for an upcoming project, though I've still no desire whatsoever to write actual business logic in PHP, so it'll have to be solely at the view end of things.
In PHP's defense, it is desperately in need of the current functionality of ===, because 0 == false, and there are core PHP functions that return *both* 0 and false (which mean entirely different things, in context). As such, you're left in a situation where you must use PHP's === to tell which one exactly the function gave you. An object identity comperator is all good and fine, but PHP needed this functionality much more desperately.
At any rate, I can't disagree with the perception of ineptitude on the pa
I looked at the bug, and it appears that it's gc'ing as expected, but doesn't let the OS reclaim the extra heap. This is pretty much to be expected, almost all language runtimes behave this way. Heck, most virtual machines like Java or Smalltalk allocate a fixed heap right off the bat. Perl also has the batty notion of "scalars" and as a result believes that a zero in a string is false, and makes string comparisons really hell with its own insanity around 'eq'... though Perl's also not in the habit of pas
Strings are only comparable for string equality with 'eq'. The == operator compares only numeric equality, and the numeric value of any string that doesn't look like a number is, in fact, zero. $ perl -le 'print "matches" if "foo" == "bar"' matches
If you use -w or "use warnings", which any sane person should do, you get a warning about it. That perl's scalar type lets you play fast and loose with strings and ints with is fine for one-offs, but there's no flag or pragma that actually separates strings and in
But that's not a problem, that is a correct way to do things. Perl is intentionally weakly typed. If you want to have weak typing and compare stuff then when you want to compare different types of stuff with each other, you need different operators/functions depending on what sort of comparisons you want to do. The alternative is to be verbose and convert stuff before comparing.
Maybe not the only correct way, but definitely better than PHP's way - where they didn't seem to think about the implications of wea
"This might not sound that bad, until you realise that nl2br() can appear a lot in large projects, there's no way to get the old behaviour of nl2br() back, and if you have a decent QA process in place, you'd be being notified of the errors across all the websites you maintain."
If you had a decent QA process in place you wouldn't upgrade all of your prod servers in one go without testing the upgrade in dev first.
HaydnH, I must ask, do you have any experience of managing PHP production servers? It is frequent that minor patch versions of PHP are mandatory upgrades due to critical bugfixes. Slipping something that breaks code in a bugfix version is NOT acceptable by any sense of the term. It means that, if you have good QA and intercept the issue on your test servers, then you must still scramble and allocate ressources to have the code audited and updated on ALL the sites of your production platform, remaining vulner
Wow, it's amazing how easily you missed the point. Let me rephrase:
In a minor release, they significantly changed the semantics of a commonly-used function. And they did so with little warning. This is unacceptable. Period.
A lot of php functions are idiotic/redundant. nl2br -- because it's so hard to use str_replace?
One of my complaints is that they add these half-assed functions and then add new parameters, change the semantics, etc. etc.
Consider http_build_query -- a useful function (but it would only take 3-5 lines of php code to write it yourself). Only available in php 5+. Except they added a new parameter in PHP 5.1.2 (making it actually useful), so you'll probably have to rewrite the function yourself.
Python's "import from future" is a good approach here, IMO. Language features can get kicked around, have the bugs shaken out of them, without becoming part of The Official Language. If they pass the test, they make it in. In the mean-time, it's pretty clear you shouldn't be relying on them.
Actually, "from __future__" is more about letting users get a feel of the soon-to-come core changes of the language (also called "incompatible language changes" in __future__'s DOCSTRING). And about rooting bugs out i
Umm PHP does not make good egineering practice. You hit walls as you code. Naming conventions are not standardized throughout the frame work. Modulazation in PHP is what duct tape is to home repair. Biggest hit: PHP is interpretted not compiled and there is no other option besides third party wrapping of compiled code.
In ASP.NET for example I can precompile my site in DLLs to whatever degree I am comfortable with. So if I want my Data Access layer locked down after a certain phase I can keep my junior develop
I've noticed that most open source projects are the way that you describe, with the culture you describe. If I were you I would stick with big companies that produce commercial software. They tend to be motivated by cash, and hire real engineers to make sure things get done correctly as much of the time as is possible.
While Microsoft has its flaws and might be deteriorating in their practice of engineering as of late, they still outshine everyone in the areas that you are complaining about.
Oh look... (Score:1)
"PHP is a toy language" trolls in 3... 2... 1...
Argh. (Score:5, Insightful)
Your comment pisses me off, but there's something I want to say all the same: I think you are, essentially, right. Whatever one's woes with PHP might be, they don't justify trolling and unsubstantiated mouthing off. Besides, "toy language" is a purely inflammatory statement that doesn't even have any factual content.
However.
However, the implicit underlying assumption I think I perceive in your comment -- that PHP criticism must be trolling -- annoys me a lot. Please allow me to expand on this.
You see, one constant characteristic of the Internet in general is the noise. Look here on Slashdot: do you read all the comments on any given story?
The noise is a bigger problem than you'd think. The noise means that it's hard to get heard. It means that to be heard, unless you're a remarkable writer (which I, and most people, aren't), you have to exaggerate your message. "PHP is a toy language" is one such exaggeration; and perhaps even actually worthy of being modded up if followed with factual information to support it. And much likelier to catch a moderator's attention with its use of strong language.
Which you would, undoubtedly, consider a troll all the same, wouldn't you?
As you can probably guess by now, I have crates of such information against PHP. (In my defense, I do try hard to gather evidence against my own tools of choice as well, for two reasons. One, being aware of their own idiosyncrasies allows me to work better with them. Two, it's a simple matter of intellectual honesty.)
The vagaries of life have landed me into a managerial-ish position in a small company that develops and hosts large-scale PHP websites. My responsibility here is twofold: ensuring that the sites work, and ensuring that they keep working.
I didn't know PHP before joining this company; I had a generally positive opinion of it beforehand, from reading Slashdot. So I got to discover it through that new role.
Let us just say, to put it mildly, that my opinion of PHP has quickly become very poor.
I think that managing a language's design and development is one of those jobs that's freaking damn hard. It takes a LOT of experience, critical thinking, introspection, knowing to prioritize issues, knowing to tap into the decades of experience in language design to understand what works and what doesn't, why, and in what context. And different people with different backgrounds and objectives are more or less successful with it.
And I don't feel the people behind PHP -- I'm sorry, guys, I don't know how to put it nicely... -- are doing the best possible job of it.
More precisely, my primary issue with PHP is its culture as a project. Cultures are inherently difficult to describe, but if I had to put it in a few words, I'd call it the "Works for me" culture.
Simply put, the sort of attitude that PHP seems to encourage -- by which I mean, the shortest-path-to-arrival approach to doing most things in PHP -- work fine for the developper producing the code, but are formally broken in a way that WILL come back to bite the ass of whomever poor dude is in charge of keeping the thing working.
For instance: I understand PHP uses a function based on the tolower() C call to make method calls case insensitive, and leaves it at it. It works for them, doesn't it? Except that in the real world, it breaks. Deploying PHP sites on servers that use a Turkish locale yields blank pages. The workaround is to never use that particular locale. Easy, isn't it? No, it isn't: PHP's gettext functions for dynamic translation require the locale to be set appropriately (unlike that of other languages). And I have my Turkish clients on the phone a lot.
Until recently, before the introduction of PDO, the canonical native way of addressing databases was to use PHP functions named after the database itself (mysql_*, etc, making the process of migrating databases, or creating a site that may have to be deployed client-side on varying database backends, an utter pain. The current canonical way still doesn't proactively encourage the use of prepared statements, that would yield better performance and forbid entirely SQL injection attacks. (But the current way "works for me", doesn't it?)
PHP STILL doesn't have namespaces. Why does this matter? Well, for instance, had PHP put the HTTP request data into its own namespace, the whole register_globals debacle wouldn't even have been possible. Good engineering practices are no silver bullet, but they do ensure that whole classes of problems simply can't happen. I think this is why the "Works for me" culture tends to fosters projects (and I don't mean only PHP, here, mind) with recurrent security issues.
Unicode support has been problematic; and by this I mean I have two major problems with it. Firstly, the lack of a native Unicode type means you can't carry around a known-good string that you can pass around or retrieve from an third-party, and only convert back to the requested encoding. Why does this matter? Well, most PHP functions break hard on UTF-16 encoded byte arrays, which contain zeros. Secondly, whenever you raise this issue, the common answer is, "What's wrong with the mbstrings functions?" And THIS is what I mean by a cultural issue: the assumption that because mbstrings "work for me", they're a suitable solution. This is not a technical problem at heart, folks.
And there's the problem of backward compatibility, which is never a granted, and makes the job of keeping production servers up to date a nightmare. There's thread safety, there's syntax bone-headedness that probably stems from PHP's lack of a grammar, there's the inconsistent behavior depending on server-side settings that you may have no control on, etc, etc, etc.
All of those make the management of large-scale PHP projects an incredible pain, and it's all the more embittering that a large chunk of it could be abated by good freaking engineering practices.
I think this is what people mean when they call the management and design of the PHP language 'amateurish'. Blatant lack of good engineering practice. I do disagree with the word amateurish itself, though: the fine guys over at Zend are professionals, and making good money off their language, which is one of the most widely deployed on Web servers. They're without contest professionals. Just, professionals with poor engineering practices.
The thing I can't forgive PHP, however, is that due to the way it encourages and rewards (at first) shortest-path-to-arrival approaches, it teaches beginning programmers everywhere that it's okay so long as it "works for me". That it's okay not to care about good practices so long as it works. That it's okay to embed SQL requests right in the HTML templates. And, due to PHP's lack of introspection and metaprogramming, that other approaches are a lot more work and not worth it.
And THIS is what people mean when they unleash Dijkstra's ghost onto PHP.
Granted, designing a language where the easiest way to do anything is correct and robust one, while keeping the flexibility and development speed of an interpreted and dynamically typed language, is extremely difficult. Is that any reason not to try, though?
So, yes, after more hours of nightly overtime than I care to count, after salvaging several expensive PHP projects for large companies that where unmanageable messes, I've come to hate PHP, which I consider a character flaw in me. PHP is just a language; that should warrant an informed opinion -- which I like to think I have -- but not an emotional reaction.
And this, in the end, is why I wanted to post this: your comment annoys me a lot, but I think its sentiment is, at heart, correct: emotional reactions to technical issues shouldn't supplant informed discussion.
And this goes both for the PHP-hater and the PHP-lover side.
Thanks.
Mod Parent Up! (Score:3, Insightful)
Re: (Score:2)
Re: (Score:3, Insightful)
(Actually, asking people what their preferred tools' most important drawbacks are is generally a good litmus test for their competence. If they can't tell you what the pitfalls are and how to work around them, or why they don't affect the task at hand, watch out.)
Simply, some tools are a better match than others for any given task.
For instance, I think that PHP makes for a good, simple and effective
Re: (Score:1)
Python.
It has deep-rooted support for meta-programming and introspection. Namespaces are simple and straight forward. The re-occurring interfaces in Python shave down development time and encorage uniformity.
Using Python is actually a pleasure. Mind, it does have its flaws: Performance (which is about on par with PHP), populatity (not deployed as much as PHP), and some OOP querks (but still better than PHP's).
Arghmen (Score:5, Interesting)
Totally agree 100%. Another example: did you ever use nl2br() [php.net] to convert newlines into <br> elements? It's an extremely common thing to do. In a minor patch release, they changed the function to generate XHTML instead of HTML. In one stroke, everybody who thought they were generating valid HTML had errors in their code. This might not sound that bad, until you realise that nl2br() can appear a lot in large projects, there's no way to get the old behaviour of nl2br() back, and if you have a decent QA process in place, you'd be being notified of the errors across all the websites you maintain. You end up having to go back and change all your code to use generic string replacement functions.
Now, maybe you might say that it's a sensible thing to change (I disagree, there should be different functions for HTML and XHTML), but at the very least, they should have put a change in semantics in a major version update, not sneaked it in between 4.0.4 and 4.0.5.
It's not really the design of the language that's the real problem (although it's not pretty), it's the cavalier attitude from people who don't seem to take a professional attitude to their work that really grates.
Re:Arghmen (Score:5, Interesting)
In other words, I was unsuccessful in explaining this rather basic concept. They got it blisteringly wrong, and hacked this wrongness into the language for all time. I attempted to explain (much more patiently than here) that no, this is not what === is supposed to do, but I wasn't heard. Not by Zeev, not by anyone else on channel. No one got it at all.
I passionately hated PHP for a long time after that, but it's just not relevant enough to my work anymore to hate. I have choices, I don't have outside clients demanding I use PHP anymore, and my choice of languages is respected where I work. I've chosen python for some projects, perl for another, C++ for another (the C++ one was of course not web). I could probably write my next project in Haskell and no one would bat an eye (though I will be stuck with maintaining it for all eternity). I'm even eying Prado -- a PHP library -- for an upcoming project, though I've still no desire whatsoever to write actual business logic in PHP, so it'll have to be solely at the view end of things.
Re: (Score:2)
An object identity comperator is all good and fine, but PHP needed this functionality much more desperately.
At any rate, I can't disagree with the perception of ineptitude on the pa
Re: (Score:2)
Perl also has the batty notion of "scalars" and as a result believes that a zero in a string is false, and makes string comparisons really hell with its own insanity around 'eq'
Re: (Score:2)
Re: (Score:2)
$ perl -le 'print "matches" if "foo" == "bar"'
matches
If you use -w or "use warnings", which any sane person should do, you get a warning about it. That perl's scalar type lets you play fast and loose with strings and ints with is fine for one-offs, but there's no flag or pragma that actually separates strings and in
Re: (Score:2)
If you want to have weak typing and compare stuff then when you want to compare different types of stuff with each other, you need different operators/functions depending on what sort of comparisons you want to do. The alternative is to be verbose and convert stuff before comparing.
Maybe not the only correct way, but definitely better than PHP's way - where they didn't seem to think about the implications of wea
Re: (Score:2)
If you had a decent QA process in place you wouldn't upgrade all of your prod servers in one go without testing the upgrade in dev first.
Re: (Score:2)
I must ask, do you have any experience of managing PHP production servers? It is frequent that minor patch versions of PHP are mandatory upgrades due to critical bugfixes. Slipping something that breaks code in a bugfix version is NOT acceptable by any sense of the term. It means that, if you have good QA and intercept the issue on your test servers, then you must still scramble and allocate ressources to have the code audited and updated on ALL the sites of your production platform, remaining vulner
Re: (Score:2)
In a minor release, they significantly changed the semantics of a commonly-used function. And they did so with little warning. This is unacceptable. Period.
Re: (Score:1)
One of my complaints is that they add these half-assed functions and then add new parameters, change the semantics, etc. etc.
Consider http_build_query -- a useful function (but it would only take 3-5 lines of php code to write it yourself). Only available in php 5+. Except they added a new parameter in PHP 5.1.2 (making it actually useful), so you'll probably have to rewrite the function yourself.
It would
Re: (Score:2)
Actually, "from __future__" is more about letting users get a feel of the soon-to-come core changes of the language (also called "incompatible language changes" in __future__'s DOCSTRING). And about rooting bugs out i
Re: (Score:1)
Biggest hit:
PHP is interpretted not compiled and there is no other option besides third party wrapping of compiled code.
In ASP.NET for example I can precompile my site in DLLs to whatever degree I am comfortable with. So if I want my Data Access layer locked down after a certain phase I can keep my junior develop
Re: (Score:2)
If I were you I would stick with big companies that produce commercial software. They tend to be motivated by cash, and hire real engineers to make sure things get done correctly as much of the time as is possible.
While Microsoft has its flaws and might be deteriorating in their practice of engineering as of late, they still outshine everyone in the areas that you are complaining about.
Maybe you used to
Re: (Score:2)
Yeah, we couldn't understand that issue either. While our project has been translated into Turkish, it will never work on PHP 5.x with that locale. From http://codex.gallery2.org/index.php/Gallery2:Known _Issues [gallery2.org]:
I'd have h