Sadly, for that PHP-community, many developers outgrow PHP and move on.
Instead of the developers growing and improving, and so pulling the entire community upwards, many simply choose to leave. I've had this personally with Drupal: many, many years did I poor a (joined!) effort into getting proper TDD, OOP, deployment strategies into this CMS, but in the end I gave up. I mean: why put effort into making Drupal something it does not want to be; while a few weeks of learning a new language, the thing I wanted Drupal to become, already exists.
I think PHP is mostly a station in the career of many webdeveloper, before they move on to what are often considered "more professional environments". Sure, there are a few brilliant and very professional PHP-devs who stick around. But relatively seen, they are a tiny minority.
I like the story of PHP because it is a very powerful reminder that ultimately what matters is that something works, not that it is beautifully designed or appeals to some other higher-order train of thought. It's a very grassroots-style of innovation where pragmatism prevails, and there is no "right" way that people dogmatically follow. You don't have to know much about data structures or hashing to do anything useful, just find a way that works. You don't have to worry about finding the "perfect design". If people can learn a language like English with far more irregularity, inconsistent function names are the least of their worries. Just do it. And I find that very inspirational and motivating because it says that anyone who puts enough effort into getting something done, will.
I completely lost interest in programming because of PHP. When I discovered other languages where I didn't need to search the documentation every time I tried to remember a function name, or debug crazy text encoding/silent failure bugs, programming because fun again.
I have written good amounts of PHP code since then, and maintained even more of it. I've also used MVC frameworks like Symfony2, where few of the usual arguments against PHP apply, but it still feels like a low quality language with the tens to hunddeds of pitfalls one has to watch out for. And don't get me started on the Wordpress development that seems to be the main technology for webdev jobs today.
The argument that PHP is easy to get started with for beginners is a lie. Sure, you can install LAMP and start writing echo statements and it just works, but what then?
The behavior of your code is sometimes weird, functions have cryptic names, and there's really nothing to point you in the right directions. There's no enforced or even encouraged conventions, and there's heaps of "Common Knowledge" one must acquire to write safe code.
yes but simply put, no one gives a shit what you want, other than the ones that already share your feelings.
You're not going to convince good php developers to stop using php, but you will convince the bad ones... actually go on with your bad self, ruby/python needs more bad devs
I have been a longtime PHP avoider myself, but I just recently installed Wordpress for the first time and I admit to being impressed by a few things.
One is the fact that because of the implementation of PHP, where I assume a totally new process is created for every web request, a PHP app can actually edit itself and emerge different for the next incoming request.
Because of this, Wordpress has amazing features where non technical users can install plugins and even edit the source code of Wordpress, in Wordpress... This would not be as easily done in any of the various reputable languages I'm aware of... at least not in the standard implementations of those languages.
Plugin support is not something that is exclusive, or even easily implemented, in PHP. Compiled languages with Lua bindings does this better, with the benefit of very easy sandboxing. Ghost (https://ghost.org/) is a more mainstream example, and it has plugin support.
As someone who has developed wordpress themes, the plugin support in wordpress is a gigantic source of frustration. It is not amazing under the hood.
Interesting trivia I've wondered about (like "why are the registers in x86 named in A, C, D, B order), not really any issue though; you memorise them just as well in any case if you work with enough code.
Rasmus created PHP for his own benefit to begin - how was he to know back in 1994 that it would grow to power so much of the web? We all make mistakes; we all learn from them. Lets move on.
Of course, noone in this day and age would make any dodgy design decisions... would they?
There's nothing wrong with the code that Node uses for HTTP verbs. It's optimized to do a single byte comparison where it needs to, the code is taken straight from nginx which is brutally optimized. You want speed, you got it.
While it's true that the code in question was taken straight from nginx, if you bothered to read the NodeJS implementation (pre-fix, and referenced in my link) you would see that a secondary check against the full verb (that nginx performs further down the line) was not included.
Hence you could GEM a page or PUN an object. I'm not sure I want a codebase that's "brutally optimized" to the extent that it's not functionally equivalent.
EDIT: Used "functionally equivalent" as a more proper phrase than "idempotent" after the below feedback
Don't use the word idempotent. One of my pet peeves is use of higher level vocabulary in the wrong context. Nothing is being applied multiple times. And the optimized code is a beast of its own, it's not an 'optimized' operation on a normal piece of code.
The code simply does not perform the same rigor as slow, spec-following code would.
The opportunity is still there. This kind of mistake is easily fixed: create your own aliases for the functions you'd like to rename, and it's done.
If the PHP people are unhappy with them, they could do exactly the same, deprecate and remove the original names through a couple of major releases, and the problem is solved as well. Same solutuon for parameter order (needle, haystack, whatever).
Really I don't understand all the fuss around PHP functions names.
> Really I don't understand all the fuss around PHP functions names.
You could add aliases to all functions in php in your company, but then you would need to teach these aliases to all new developers. Also every company would have different aliases and people changing jobs would need to relearn everything.
So aliases are theorethical solution that nobody use in practice. Changing the standard makes a new common language that you can actually use.
Very true; I would be disappointed to discover that PHP is still using the same hashing function.
However, changing the function names (especially some of the core ones) is fraught with backwards-compatibility issues - PHP code written 15 years ago should, for the most part, still work, and not enough hosts out there run with the right error reporting to point out deprecation warnings, so you would probably end up with a lot of PHP sites with code silently failing when a host upgraded.
I completely disagree. As a language matures, features need to be depreciated as newer / better features are implemented. It's actually quite common for languages to do this.
In fact PHP HAS depreciated functions over it's life, so 15 year old code might not run on modern web servers anyway. Yet we still have the same function names where they should have been renamed.
I'm all for standardizing core function names and deprecating outmoded items, but I was merely pointing out the problems inherent in doing so - there are pros and cons to all decisions, and a great deal are complicated greatly once they're out in the wild for a long time.
I think the latest PHP APIs are the least of your problems if you're running sites with code that hasn't been touched in 15 years:
* new security threats that have been discovered in that time which needed to be coded against (In the last 15 years, a lot has changed with the approach we have to building secure sites).
* newer web standards and browsers - thus compatibility on the client side might now be an issue.
* different computing paradigms (we use touch interfaces where hover-over menus wouldn't function. There's a massive range of different client side screen resolutions and aspect ratios these days too).
* different methods of sharing content (for some types of sites, supporting OpenGraph and Twitter Cards is pretty important if you depend on your content getting exposure from "word of mouth").
* different user expectations (a 15 year old site is unlikely to look any good compared their modern counterparts. While that might not matter for some sites, if you're trying to generate traffic from the average layman, then they might be put off and prefer a site which is more aesthetically pleasing).
So if someone is trying to port 15 year old PHP code to a new server, then I'd expect they'd want / need to do a sizeable amount of rewriting anyway - regardless of API compatibility. In this instance, API compatibility is the least of their worries as you can at least just use the 'find/replace' tool in your text editor to fix renamed APIs, where as fixing the other issues (eg switching from the older method of dropping variables into an SQL string, to the current preferred method of parametrized SQL which negates the risk of SQL injection attacks) will take much longer.
One thing I like a lot about PHP is its version stability, it has changed somewhat over time, but not to the point where it breaks important features.
I have seen many a framework and language (the sort that you might see hyped on this website) that make drastic changes and only their most ardent fans stick with the new version. It's often an opportunity to switch to the next big thing.
I'm not asking for PHP to break it's compatibility over night, but it's fairly reasonable for a language to depreciate a function over several major releases which might span a few years.
ie version 5.6 will raise a warning when some_function is called, saying that some_function will be depreciated in future versions of PHP. So you have both the old and new functions running in parallel for a while. Then a couple of major versions later, you drop support for the older function name.
As I said before, PHP has already been doing just this for some stuff for a while now, so it's not an alien concept to PHP developers.
Nobody can blame the guy for the design choices and naming conventions he made back then. The problem is that they still exist 20 years later when much of the worlds web infrastructure runs on PHP.
I'd have expected (hoped) that by the time of the last major release (v5.0) the chief PHP devs would have used that opportunity to to rename some of the core functions. By that point PHP's popularity was already established and the shortcomings of it known. Plus as there was already a major Zend rewrite under way, to me it seems a sensible time to throw in a few in a few niceties to beautify / simplify the APIs.
Perl -PHP's spiritual predecessor- managed to tidy itself up circa v5.8 and now, ironically, Perl is cleaner language to code in despite the jokes about it being executable line noise.
The past five or so years have seen engineers of greater experience take interest in PHP's ecosystems and core; a greater maturity in PHP is emerging. I suspect we'll see bigger changes coming over the next five or ten years, but it takes time to tame chaos.
I'm not defending the practice, I'm just saying it's the argument that gets used. "We're an oracle shop, we've spent $N Million on getting set up as an oracle shop, and we'll always be an oracle shop. Let's use ADF[1]."
I'd always argue against this. Python is, by far, easier to learn. Python was, after all, designed as a language to teach programming.
The issue is, that people often compare apples and oranges here:
Good, SOLID, and well-architectured OOP PHP applications (YII, Zend) are far harder to learn then Django or Rails. It is unfair to compare the "hacking of a free WordPress theme" to "setting up and deploying a full MVC application in Rails". When you compare similar stacks, PHP is, nearly always, the harder-to-learn choice.
A simple, hacked-together sequential script serving a webpage is, by far, easier in both Python and Ruby then in PHP. If only for the fact that both Python and Ruby come with decent, built-in webservers. PHP has gotten this in the latest release only, but before, a fair comparison would be: a PHP app requires you to erect a full LAP-stack, whereas a python-script could be serving pages on the most barebone machine with Python installed.
Again, the very beginning of PHP might seem easier to learn, because in practice, a lot of the infra is there and a lot of groundwork is already done (LAMP-stacks come for almost free; Passenger or Fastcgi not so much, allthough they are there).
And then, when going a bit further then "removing these two menu-items in a WP-theme", when moving into the area of proper designed, maintainable webstacks, PHP is a lot harder to learn.
And when moving one step further, e.g. including stuff like asyncronous workers, long-running-threads, commandline-tools, and so forth, PHP is often even completely unable to cope, but in the very least, proves a really hard and cumbersome tool.
You're correct, but unfortunately that's not the point. PHP makes it very easy to learn to write ugly hacky code quickly, and in the beginning, that's all that matters - the person learning simply doesn't know any better.
When comparing stacks, (1) to serve a PHP page you upload it to the server and you're done, (2) a basic PHP page is a web page. Python just lost. (Not that I don't prefer python.)
It's not PHP, it's mod_php that makes PHP so easy to use.
Yep, I think Rails is easier to learn compared with Zend, which is over-designed for me. I will choose CodeIgniter in the shared hosting world, but in the cloud age haha, you can host almost everything for free - Spring, Rails, Django. So this can change the things, except for "Brochure Web Sites" where WordPress is the king.
> If only for the fact that both Python and Ruby come with decent, built-in webservers.
With PHP 5.4+: `php -S 0.0.0.0:8000`, just as useful as SimpleHTTPServer.
And I wasn't aware of Ruby coming with a web server. I know of WEBrick for Rails -- but is there a standard module that Ruby ships with that's similar to the above PHP and Python servers?
I explicitely mentioned that the latest release of PHP comes with the built-in -S server. But that before this, it was always either install *AMP of some variation, which is, frankly a lot harder. And even now, Whereas Rails requires a few commanline commands, a CMS like Drupal still needs quite some fiddling to get it ro run on your localhost. (Source: I have been professional Drupal trainer for years)
But let me note that neither three of these servers are anything good for production. But, for small (internal) projects, `SimpleHTTPServer`, `Webrick` or even `php -S` might suffice, especially when behind a reverse proxy. Yet of all three, Webrick is especially slow, and php-s is especially memory-leaking and unstable.
I find it hard to use this survey as actual statistics. I could not find any details on how they measure, how many sites and servers are measured and so on. As far as I know, someone emailed his 400 friends on Facebook and placed the results in an excel-sheet.
* Does it take volume into account? Github (Ruby, Java, Scala) alone serves more pages then your average 10K Wordpress-sites will. Yet Facebook (PHP) serves such a huge number that it might even dwarve all the "enterprice" C#, Java and Cobol sites of probably all governments in the entire EU.
* Does it take economic value in account? One gov. site, or one large application (say, google docs) alone costs a multitude of what a 100K mom&pop PHP-webshops have cost. I, personally (as in: this is not a statistic nor any proof of anything) see a lot more value going around in the Ruby on Rails webdevelopment-economy then in the PHP-economy; the latter seems to consist of mostly a few-hundred-bucks Drupal installs or WordPress themes, whereas the first is almost always custom built and startup-development growing far over the 1K.
* How do they adjust for "not recognised"? I mean: it is hard to hide the fact that you are running a Drupal site, even for something large as the Whitehouse.gov. Whereas your average custom-built Django-backend is probably not even accessible for crawlers and even if so, most probably not recognisable as being Python/Django powered. In other words: off-the-shelve stacks are far more often recognised; and are, quite probably, nearly always PHP.
* How does this account for all the backend? Sure, WordPress is written in PHP, but many WP sites run off MySQL, which is just as important as the PHP-part; is WP not, PHP and MySQL powered then? Or other backends: the startup where I work now, has 90% of its code in the backend, Rails, with a tiny 200 lines PHP-app facing our users. This is certainly not a PHP-app, but would this survey count it as such?
which is why I mentioned this specifically: would this survey count Facebook as PHP, or as C? This makes a big difference on the outcome of "the amount of large sites running on language X"
I find the inconsistency of the ordering of parameters in core PHP functions to be more frustrating than the names of them.
Either way, I guess I have to agree that people are spending a lot more time than necessary referencing php.net.
But then again, no need for all the anger and rage. There are a lot of things in the World much worse than PHP. There are things that are horribly wrong and yet still ubiquitous. Go fight racism, not web programming languages.
When I was visiting my brother for Christmas last year, my 14 year old nephew told me he was interested in coding and really wanted to learn Java and PHP. My reaction was "you clearly don't read Hacker News".
67 comments
[ 4.9 ms ] story [ 138 ms ] threadEdit: I'm not necessarily disagreeing with you but I just want to know what your reasons would be to see it die rather than be improved.
Or indeed developing a successor. Loads of people bitch about how bad PHP is - I see very few efforts to even come up with a better alternative.
Instead of the developers growing and improving, and so pulling the entire community upwards, many simply choose to leave. I've had this personally with Drupal: many, many years did I poor a (joined!) effort into getting proper TDD, OOP, deployment strategies into this CMS, but in the end I gave up. I mean: why put effort into making Drupal something it does not want to be; while a few weeks of learning a new language, the thing I wanted Drupal to become, already exists.
I think PHP is mostly a station in the career of many webdeveloper, before they move on to what are often considered "more professional environments". Sure, there are a few brilliant and very professional PHP-devs who stick around. But relatively seen, they are a tiny minority.
I have written good amounts of PHP code since then, and maintained even more of it. I've also used MVC frameworks like Symfony2, where few of the usual arguments against PHP apply, but it still feels like a low quality language with the tens to hunddeds of pitfalls one has to watch out for. And don't get me started on the Wordpress development that seems to be the main technology for webdev jobs today.
The argument that PHP is easy to get started with for beginners is a lie. Sure, you can install LAMP and start writing echo statements and it just works, but what then? The behavior of your code is sometimes weird, functions have cryptic names, and there's really nothing to point you in the right directions. There's no enforced or even encouraged conventions, and there's heaps of "Common Knowledge" one must acquire to write safe code.
You're not going to convince good php developers to stop using php, but you will convince the bad ones... actually go on with your bad self, ruby/python needs more bad devs
One is the fact that because of the implementation of PHP, where I assume a totally new process is created for every web request, a PHP app can actually edit itself and emerge different for the next incoming request.
Because of this, Wordpress has amazing features where non technical users can install plugins and even edit the source code of Wordpress, in Wordpress... This would not be as easily done in any of the various reputable languages I'm aware of... at least not in the standard implementations of those languages.
As someone who has developed wordpress themes, the plugin support in wordpress is a gigantic source of frustration. It is not amazing under the hood.
Umm...they're not. Who names them in that order?
Of course, noone in this day and age would make any dodgy design decisions... would they?
http://www.chmod777self.com/2013/08/sigh.html
Hence you could GEM a page or PUN an object. I'm not sure I want a codebase that's "brutally optimized" to the extent that it's not functionally equivalent.
EDIT: Used "functionally equivalent" as a more proper phrase than "idempotent" after the below feedback
The code simply does not perform the same rigor as slow, spec-following code would.
If the PHP people are unhappy with them, they could do exactly the same, deprecate and remove the original names through a couple of major releases, and the problem is solved as well. Same solutuon for parameter order (needle, haystack, whatever).
Really I don't understand all the fuss around PHP functions names.
You could add aliases to all functions in php in your company, but then you would need to teach these aliases to all new developers. Also every company would have different aliases and people changing jobs would need to relearn everything.
So aliases are theorethical solution that nobody use in practice. Changing the standard makes a new common language that you can actually use.
However, changing the function names (especially some of the core ones) is fraught with backwards-compatibility issues - PHP code written 15 years ago should, for the most part, still work, and not enough hosts out there run with the right error reporting to point out deprecation warnings, so you would probably end up with a lot of PHP sites with code silently failing when a host upgraded.
In fact PHP HAS depreciated functions over it's life, so 15 year old code might not run on modern web servers anyway. Yet we still have the same function names where they should have been renamed.
* new security threats that have been discovered in that time which needed to be coded against (In the last 15 years, a lot has changed with the approach we have to building secure sites).
* newer web standards and browsers - thus compatibility on the client side might now be an issue.
* different computing paradigms (we use touch interfaces where hover-over menus wouldn't function. There's a massive range of different client side screen resolutions and aspect ratios these days too).
* different methods of sharing content (for some types of sites, supporting OpenGraph and Twitter Cards is pretty important if you depend on your content getting exposure from "word of mouth").
* different user expectations (a 15 year old site is unlikely to look any good compared their modern counterparts. While that might not matter for some sites, if you're trying to generate traffic from the average layman, then they might be put off and prefer a site which is more aesthetically pleasing).
So if someone is trying to port 15 year old PHP code to a new server, then I'd expect they'd want / need to do a sizeable amount of rewriting anyway - regardless of API compatibility. In this instance, API compatibility is the least of their worries as you can at least just use the 'find/replace' tool in your text editor to fix renamed APIs, where as fixing the other issues (eg switching from the older method of dropping variables into an SQL string, to the current preferred method of parametrized SQL which negates the risk of SQL injection attacks) will take much longer.
I have seen many a framework and language (the sort that you might see hyped on this website) that make drastic changes and only their most ardent fans stick with the new version. It's often an opportunity to switch to the next big thing.
ie version 5.6 will raise a warning when some_function is called, saying that some_function will be depreciated in future versions of PHP. So you have both the old and new functions running in parallel for a while. Then a couple of major versions later, you drop support for the older function name.
As I said before, PHP has already been doing just this for some stuff for a while now, so it's not an alien concept to PHP developers.
I'd have expected (hoped) that by the time of the last major release (v5.0) the chief PHP devs would have used that opportunity to to rename some of the core functions. By that point PHP's popularity was already established and the shortcomings of it known. Plus as there was already a major Zend rewrite under way, to me it seems a sensible time to throw in a few in a few niceties to beautify / simplify the APIs.
Perl -PHP's spiritual predecessor- managed to tidy itself up circa v5.8 and now, ironically, Perl is cleaner language to code in despite the jokes about it being executable line noise.
[1]:http://www.oracle.com/technetwork/developer-tools/adf/overvi...
But if we talk about disadvantages, me personally do not like WordPress because of its slowness.
Very easy to learn
The issue is, that people often compare apples and oranges here:
Good, SOLID, and well-architectured OOP PHP applications (YII, Zend) are far harder to learn then Django or Rails. It is unfair to compare the "hacking of a free WordPress theme" to "setting up and deploying a full MVC application in Rails". When you compare similar stacks, PHP is, nearly always, the harder-to-learn choice.
A simple, hacked-together sequential script serving a webpage is, by far, easier in both Python and Ruby then in PHP. If only for the fact that both Python and Ruby come with decent, built-in webservers. PHP has gotten this in the latest release only, but before, a fair comparison would be: a PHP app requires you to erect a full LAP-stack, whereas a python-script could be serving pages on the most barebone machine with Python installed.
Again, the very beginning of PHP might seem easier to learn, because in practice, a lot of the infra is there and a lot of groundwork is already done (LAMP-stacks come for almost free; Passenger or Fastcgi not so much, allthough they are there). And then, when going a bit further then "removing these two menu-items in a WP-theme", when moving into the area of proper designed, maintainable webstacks, PHP is a lot harder to learn. And when moving one step further, e.g. including stuff like asyncronous workers, long-running-threads, commandline-tools, and so forth, PHP is often even completely unable to cope, but in the very least, proves a really hard and cumbersome tool.
It's not PHP, it's mod_php that makes PHP so easy to use.
With PHP 5.4+: `php -S 0.0.0.0:8000`, just as useful as SimpleHTTPServer.
And I wasn't aware of Ruby coming with a web server. I know of WEBrick for Rails -- but is there a standard module that Ruby ships with that's similar to the above PHP and Python servers?
I explicitely mentioned that the latest release of PHP comes with the built-in -S server. But that before this, it was always either install *AMP of some variation, which is, frankly a lot harder. And even now, Whereas Rails requires a few commanline commands, a CMS like Drupal still needs quite some fiddling to get it ro run on your localhost. (Source: I have been professional Drupal trainer for years)
But let me note that neither three of these servers are anything good for production. But, for small (internal) projects, `SimpleHTTPServer`, `Webrick` or even `php -S` might suffice, especially when behind a reverse proxy. Yet of all three, Webrick is especially slow, and php-s is especially memory-leaking and unstable.
Just web-hosts and instant gratification.
* Does it take volume into account? Github (Ruby, Java, Scala) alone serves more pages then your average 10K Wordpress-sites will. Yet Facebook (PHP) serves such a huge number that it might even dwarve all the "enterprice" C#, Java and Cobol sites of probably all governments in the entire EU.
* Does it take economic value in account? One gov. site, or one large application (say, google docs) alone costs a multitude of what a 100K mom&pop PHP-webshops have cost. I, personally (as in: this is not a statistic nor any proof of anything) see a lot more value going around in the Ruby on Rails webdevelopment-economy then in the PHP-economy; the latter seems to consist of mostly a few-hundred-bucks Drupal installs or WordPress themes, whereas the first is almost always custom built and startup-development growing far over the 1K.
* How do they adjust for "not recognised"? I mean: it is hard to hide the fact that you are running a Drupal site, even for something large as the Whitehouse.gov. Whereas your average custom-built Django-backend is probably not even accessible for crawlers and even if so, most probably not recognisable as being Python/Django powered. In other words: off-the-shelve stacks are far more often recognised; and are, quite probably, nearly always PHP.
* How does this account for all the backend? Sure, WordPress is written in PHP, but many WP sites run off MySQL, which is just as important as the PHP-part; is WP not, PHP and MySQL powered then? Or other backends: the startup where I work now, has 90% of its code in the backend, Rails, with a tiny 200 lines PHP-app facing our users. This is certainly not a PHP-app, but would this survey count it as such?
Facebook (PHP transpiled to C and compiled into a binary)
It has since spread like wildfire. This appears to be simple blogspam (tumblrspam?) of that.
2. Instant up-voting on HN. Yay traffic!
3. Profit!
Full credit to the underpants gnomes: I couldn't have done it without you guys.
For extra bonus, do it on Tumblr, a PHP-powered website.
and then we have the Ruby guys coming along, butthumping Rails and mass assignment fests.
Name a perfect language/framework?
Either way, I guess I have to agree that people are spending a lot more time than necessary referencing php.net.
But then again, no need for all the anger and rage. There are a lot of things in the World much worse than PHP. There are things that are horribly wrong and yet still ubiquitous. Go fight racism, not web programming languages.
No such thing as bad publicity?