Of course, noone in this day and age would make any dodgy design decisions... would they?

http://www.chmod777self.com/2013/08/sigh.html

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.

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.

* 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'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...

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.

It has since spread like wildfire. This appears to be simple blogspam (tumblrspam?) of that.

But if we talk about disadvantages, me personally do not like WordPress because of its slowness.

* 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)

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.

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.

Edit: 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.

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.

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.

No such thing as bad publicity?

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.

and then we have the Ruby guys coming along, butthumping Rails and mass assignment fests.

Name a perfect language/framework?

Umm...they're not. Who names them in that order?