> It strikes me that adding more tools that incompetent web developers can abuse is what got them there in the first place.

This is profoundly ridiculous. It's the equivalent of saying Home Depot shouldn't sell power tools because some do-it-yourselfer might saw his foot off.

Just because a tool can be misused is not an argument against it nor its inclusion.

You're incorrectly characterizing the argument: it's actually like saying Home Depot shouldn't sell power tools without safety guards, fuses, emergency shutoffs, SawStop, etc. PHP has a number of misfeatures which make it extremely easy for all but the most vigilant of developers to make mistakes with security consequences (https://eval.in/108854 was making the rounds just this morning) or simply increasing the likelihood of creating bugs (i.e. the inconsistent parameter ordering across the similar array_* functions). Most of these complaints date back to the late 90s but now are much harder to make both because the core developers don't take them seriously and because there's now a huge backwards compatibility problem.

The most interesting development in PHP is the HHVM hack mode or similar concepts where an actively-maintained codebase can opt-in to safer behaviour. For the sake of anyone who has to secure code on the internet, I hope this catches on.

EDIT: See slide 15 onward in http://www.slideshare.net/skamerman/ipc-2013-high-performanc...

Maybe how you test for equality shouldn't depend on an ini file... just sayin...

Perhaps testing for equality doesn't need a 3 page answer... in most languages it's a pretty straightforward answer... primitive types use == and objects use either isEquals or operator overloading.

http://www.php.net/manual/en/ini.list.php

I used to believe this, but now I couldn't disagree more. People can and do misuse things all the bloody time, and the more you enable them to do that, the worse your tool is. How people use what you make is every bit as important, possibly even more important than the technical merits of what you make.

I'd rather a builder use a second hand hammer to nail something than try doing it with a jackhammer.

This is an excuse for educating people, not an excuse for kneecapping the majority due to an ignorant minority. This is the kind of thinking that plagues the GNOME3 devs and gets ridiculed so often around here. The user is an idiot so let's remove features.

I don't see many people harshing on Rails for the inclusion of WEBrick.

In terms of avoiding accidents I agree, but in general, I don't like this kind of thinking.

One man's misuse is another man's hack. The flipside here is that the more you limit and subdivide a tool, the worse your tool becomes.

I'd also rather see builder using something else than a jackhammer to nail stuff, but then I also want him to have access to one if he needs it, and I strongly want people to stop shouting "omg you can't use X to do Y, because X was not meant to do Y". First principle of hacking: tools do not have inherent purpose, they can be used to do whatever we want; they only can be better or worse at a particular task. The world didn't collapse into logical contradiction the last time I cut pizza with a sound card, because of lack of any other sharp tool nearby.

By that measure, PostgreSQL is a horrible database. After all look what happens when I do this:

    CREATE TABLE foo (
       id serial not null unique,
       bar text primary key
    );

    CREATE TABLE foobar (
       chunk_id serial not null unique,
       foos foo[]
    );

    INSERT INTO foobar (foos) values (array[row(1, null)::foo, row(2, '1323')::foo, row(3, '2222')::foo]);

    select * from foobar;

I've yet to see an article that would argue that its existence is a proof that you should be using Python now.

I don't see why you decided to pick a fight about Python, though - Python seems to be a sore point for PHP defenders and I really don't know why

Unless the web server displays a huge red message every time it is run saying "Don't even think about using this in production" you can bet that it will be.

Uhh... this is the first line the web server spits out:

PHP 5.4.0 Development Server started at Thu Jul 21 10:43:28 2011

The manual isn't exactly vague on this point either:

http://us3.php.net/manual/en/features.commandline.webserver....

So we got the warning already in there, what else would you like?

So the server outputs a message. Great. Is it huge, red and says "do not use me in production"? No. Its a standard version banner.

Maybe we should add some <blink> and <marquee>?

Compare these two screenshots: http://i.imgur.com/Kzdphar.png http://i.imgur.com/CQnU8aG.png

A simple bold tag immediately draws focus and ensures that the huge majority of people who view the page get the important message. That's not being hard to please, it's just common sense.

Doing that would mean the dev/prod environment is different, which is not that great of an idea. Keeping them as similar as possible leads to less chance of "but it worked on the dev server" sort of problems.

Regardless of what anybody thinks about Ruby developers, I've never heard or seen that "people launching production sites with servers intended mainly for Rails development use" is/was a widespread thing.

I don't think I've ever heard of new PHP devs "launching with the built in web server". Django has shipped with a built-in insecure web server for years and no ones crying to fix it.

There's things to fix in PHP, but this is not one.

Also, I've really got to stop reading the comments on PHP threads here on HN. They're repetitive, pointless and negative to the point of blindness. I'll go back to building cool things in it (and Go and Ruby and lately C, because while each of those have their issues they all serve a purpose and do it well).

Replace everyone's symfony security/auth module? what could possibly go wrong? :D

I have been under the impression that that was, in fact, one of the reasons PHP has such a bad reputation (rightly or wrongly).

  Before : Install php, write php, install apache / mod_php, refresh.
  After  : install php, write php, refresh.

[1] no need to install/configure a complex standalone server, focus on embedded thus more cohesive routing systems instead of fragile rule-on-top-of-regexps as seen in apache.

EDIT: To clarify, a framework like Rails definitely has a place for including a web server.

Now Ruby has a lightweight web servers in its standard library (but not its core library). Maybe the problem people are seeing with the web server (and it's not a new problem) is the way PHP's core library contains so many things that other languages would leave out as optional includes.

So it's more like `python -m SimpleHTTPServer` than the node http module.