...that's not really inherent in PHP. You can configure Python to be just as easy, and some webhosts do this. Node is pretty much always this easy. Django and Rails can also be this easy (if you've ever used Webfaction, you'll know what I'm talking about).

And, on the flip side, if you want to install configure PHP yourself, it's actually not that easy. It's trivial to get a PHP page to execute given a web server configured to make it trivial (but, again, that's true for almost any language), but configuring the web server isn't trivial.

<?php Print "Hello, World"; ?>

I can wrap that in a little HTML, to get valid return to the user.

I don't know what Node.js's hello world looks like. From google it looks like the following. This is a heck of a lot more things to understand.

// Load the http module to create an http server. var http = require('http');

// Configure our HTTP server to respond with Hello World to all requests. var server = http.createServer(function (request, response) { response.writeHead(200, {"Content-Type": "text/plain"}); response.end("Hello World\n"); });

// Listen on port 8000, IP defaults to 127.0.0.1 server.listen(8000);

// Put a friendly message on the terminal console.log("Server running at http://127.0.0.1:8000/);

  var app = express.createServer();
  app.get('/', function(req, res){
      res.send('Hello World');
  });
  app.listen(3000);

For Sinatra:

  require 'sinatra'
  get '/' do
    "Hello World!"
  end

Consider this example of a completely function blog: https://github.com/mitsuhiko/flask/tree/master/examples/flas...

There's 76 sloc of code in the blog app, plus tests, templates, database access, and more. And it's clean, clear, and simple. What does the PHP equivalent look like?

Of course, PHP is still shorter for hello world...mostly because it's running as a CGI app. This is a terrible, archaic idea for all the reasons that get discussed when people talk about Why PHP Is Terrible, but nothing is stopping you from configuring other languages that way. So here's a real apples-to-apples comparison:

Python:

  print "Hello world!"

  puts "Hello world!"

Imagine you're some mom who's made a static website for some group you're a member of. You made 20-30 static pages with Frontpage or something like it.

It's a much MUCH smaller step to rename a file .php and add

    <?date('Y-m-d')?>

It's exactly that integration that makes PHP win. If someone would make a similar integration for a better language (and made it fit the other niches that PHP fits that nothing else does) they'd stand a great chance of changing the world.

The problem is, no one gets it. Just like you you're fundamentally missing what people like about PHP. It's not the language that they like. It's that it's HTML+server scripting. No setup needed, no external files needed, no libraries to learn, no security issues at least at the start. It just works, in small increments above the level of static HTML.

And you stare at them ... and tell them they should just make a peanut-butter sandwich. They stare at you blankly. Then they tell you to go #$%$#^ yourself.

Is the peanut-butter sandwich easier to make? Yes. Does it taste better? Yes. Can you use it to feed the masses? Yes.

But sir, you forget. It isn't gourmet!

Would whiff...

Either short tags would be disabled and cause an error. Or nothing would happen.

<?php echo date('Y-m-d')?> -- Would be most preferable.

<?=date('Y-m-d')?> -- Won't work on half of webservers.

PHP is simple but most PHP servers are terrible. Part of my job is to ensure the smooth installation of proprietary software on around 1000 servers a year. This is the painful part of PHP development. If the client is paying less than $5/mo for hosting then I often run into problems with misconfigured servers, common features being disabled.. hell.. shit not working! Why isn't it working? I don't know. There are no errors. There is nothing logged... yet for some reason the session only lasts 7 seconds before disappearing.. yay!

I love PHP because it is simple and just works... I really dislike 80% of shared hosting providers who cause all sorts of problems with what should be a simple cross platform application.

"<?=date('Y-m-d')?> -- Won't work on half of webservers."

You're referring to shorttags, and how evil they are. Firstly, PHP 5.4 enshrines this echo shortcut usage, and they'll always be on from now on. <?=$something;?> will always work from 5.4 on.

Secondly, "half"? Where the hell are these mythical 50% of web servers that actively disable short tags? I've been working with PHP since 1996, have worked on hundreds of projects on dozens of hosts - shared and dedicated - over those years, and have come across this once, on a server managed by someone who compiled everything by hand (not just PHP, but everything) and felt turning short tags off was "optimal" because he'd read it somewhere. He wasn't a PHP dev, just had read 'short tags are bad'.

I don't doubt that some admins and hosts do turn off short tags. It is no where close to 50% of servers out in the wild though. 5% perhaps? Even that, in my view, would be a huge stretch.

This means PHP being crippled on many servers is PHP’s own fault.

Mixing logic and your text/data will work well for inserting a simple date, but when you start adding more complicated logic it is easy to create a mess which is difficult to read and modify even for you a few months later. That's the reason other frameworks/languages try to give you a more structured (and complex) starting point.

One other big advantage of PHP, which I find as time goes by, is (boringly) its broad stability. I first learnt PHP over 10 years ago, and what I learnt then still works now. Web apps are a very small part of what I do, I knock together the odd small one every couple of years or so.

I did do one app in Rails, but when I next came back to look at Rails about 18 months later, it seemed enough things had changed my app broke in various ways. I find I increasingly appreciate a large community, a book or two, and some stability.

Obviously if your day-to-day life is web design that doesn't apply. My day-to-day life in high performance algorithms, and I was using new C++11 features as they got implemented in compilers, and have played with many languages in that area.

Also, I didn't mention the updates in parallelism that were added (because they should have come earlier)...but do you think c++ is comparable to a modern concurrent language atm? Worth it over erlang?

Other people may have different opinions, but I don't think C++11 will convert anyone, but people who already have a big time, or code, investment in C++ will find much of their lives much easier. Another indirect advantage is that by moving to C++11, it finally allows people to make a clean break from older, less standard C++ compilers. Wether will we end up with a new state, where people end up supporting partial C++11 compilers, we will have to wait and see.

The parallelism is really just standardising existing behaviour in many cases. People who want to write things like lock-free algorithms are very excited by the atomics stuff, but such stuff is beyond me.

I am disappointed that some more practically useful threading algorithms, like thread pools and such like did not end up in the standard. However they now seem to be arriving as 3rd party libraries.

I think what is going on is that before a threadpool library was '2 steps removed' from standard C++ (as first you had to write, or use someone else's, threading/atomics library). Now they are only '1 step removed', they are more useful.

In modern architectures there are lots of places where you can get way faster, just by organizing your data in more cache friendly ways, or the way the data is layered across registers and memory regions.

You need a language like C++ for these type of optimizations.

From Slim: (http://www.slimframework.com/)

require 'Slim/Slim.php';

$app = new Slim();

$app->get('/hello/:name', function ($name) { echo "Hello, $name!"; });

$app->run();

From Silex: (http://silex.sensiolabs.org/)

require_once __DIR__.'/silex.phar';

$app = new Silex\Application();

$app->get('/hello/{name}', function($name) use($app) { return 'Hello '.$app->escape($name); });

$app->run();

  Hello World!

In reality, one of the things that makes PHP an easy language to pick up is that you don't have to have all of the overhead of learning how it works. Novices sprinkle bits of PHP surrounded by HTML-looking tags and all of the sudden they're up and running.

I started with PHP myself, and found it to be an interesting and frustrating language (needle or haystack argument first?). It's often saved by an easily searchable manual and a huge user base.

PHP is a shoot-yourself-in-the-foot language. It'll happily let you do dangerous, awful, bad, bad things. This wouldn't be such an issue if there was a higher barrier to entry, the real problem is it's easy to pick up (is that really a "problem"?), but that's a feature not a bug.

At worst, all you may need is to ensure .html prefixed resources as processed as HTML files: http://docs.grabaperch.com/getting-started/file-extensions

The benefit of being able to output HTML by default, drag+drop files over FTP or SCP to get it working, and a lanaguge that a lot of developers already know through client scripting.

I wonder if ASP still has support for Javascript as a server lanagage.

An example would be something like:

    <%
    	require('mysql');
    	require('session');
    	require('cookie');
    	require('datetime');

    	blog_data = mysql.fetch('select * from blog_meta');
    	posts = mysql.fetch('select title, content, author, pubdate, permalink from posts where published=1 order by pubdate desc');
    	user = session.get_current(cookie.sess_id);
    %>
    <!DOCTYPE html>
    <html>
    <head>
    	<meta charset="utf-8" />
    	<title><%= blog_data.title %></title>
    </head>
    <body id="home">
    <div class="container">
    	<% for post in posts: %>
    		<div id="post-<% post.id %>">
    			<a href="<% post.permalink %>">
    				<h1><%=post.title %></h1>
    			</a>
    			<div class="postmeta">
    				<%=post.author %> - <%= post.pubdate.format('%m %d %Y') %>
    			</div>
    			<div class="content">
    				<%=post.content %>
    			</div>
    		</div>
    	<% endfor %>
    </div>
    </body>
    </html>

However, for building applications that might get deployed somewhere, or talk to a database in a secure fashion, it's a nightmare.

For ruby, python and perl, it's just as easy to make a hello world like that, all you have to do is execute it as a CGI. Node.js is a FRAMEWORK, not a language, you can equally make it super simple to execute javascript the same way by again executing it at as CGI, it's actually even shorter because you don't need <? ?> tags.

The reason the Perl,Python and Ruby communities don't make apps like that is because it's a bad idea. In ruby,perl,python,javascript if you really want to you can. PHP makes it incredibly hard to not be stupid in the way your app is setup. PHP saves you a few minutes of following a rails cast in exchange for a lifetime of hell.

The crux of why most programmers disdain PHP is because of the poor choices for maintainability and ease of building larger applications, also because the PHP community has no idea what they're talking about for the most part.

Most PHP programmers couldn't even tell the difference between a language, a framework, a template system, probably because PHP doesn't have any separation of concerns. The language, framework, standard library, templating system are all mashed into one godawful mess.

But yes, it's really easy to build hello world applications. Alternatively, if you want to build a hello world application you could just write:

  Hello World

In what decade? Ever heard of PDO? Prepared statements? PHP is actually more secure when it comes to database connections than all of the wonderful alternatives you mentioned.

The most commonly used module for mysql access, mysql (not mysqli for some reason), does not support bound parameter prepared statements instead opting for some very funky string escaping business.

Prepared statements are generally the only supported SQL mechanism in other languages/platforms I have used (C, Perl, Ruby, Java, COBOL...)

From COBOL? Probably a good idea.

Facebook, Wikipedia are begging to disagree.

Quote Adam D'Angelo, former CTO of Facebook: "PHP was out of the question [for building Quora]. Facebook is stuck on that for legacy reasons, not because it's the best choice right now". (source: http://www.quora.com/Quora-Infrastructure/Why-did-Quora-choo...)

A specious comment - hiphop transforms PHP to optimised C++ and then compiles it.

https://github.com/facebook/hiphop-php

Things like this: https://bugzilla.redhat.com/show_bug.cgi?id=786686

Put an empty PHP file on your server and you've got a vulnerability. If they can't figure out how to parse a URL correctly what else is lurking? Ironically, the issue is a fix for a DOS attack, so they traded a DOS attack for remote code exec, and then backported it.

This is the equivalent of

  int main() { return 0; } 

By the way, this issue is from two months ago, we're not even talking about the really bad ancient bugs.

I am well aware that PHP has had security issues in the past, but I am also aware of the fact that it gets a bad name because people read blog posts and then decide the sky is falling.

    <html>
    <body>
    <form action="handlerhere" method="post">
    <label>Name: <input type="text" name="name" /></label>
    <input type="submit" name="submit" value="Submit" />
    <input type="hidden" name="submitted" value="TRUE" />
    </form>
    </body>
    </html>

    <html>
    <body>
    <?php
    if (isset($_POST['submitted'])) {
    $name = htmlentities(stripslashes($_POST['name']));
    echo "<p>The submitted name was \"$name\"</p>";
    }
    ?>
    </body>
    </html>

    #!/usr/bin/python
    import cgi;
    def main():
     form = cgi.FieldStorage(); # instantiate only once!
     name = form.getfirst('name', 'empty');
     
     # Avoid script injection escaping the user input
     name = cgi.escape(name);
     
     print "Content-Type: text/html\n";
     print """\
     <html>
     <body>
     <p>The submitted name was "%s"</p>
     </body>
     </html>""" % name

    if __name__ == "__main__":
     main();

    Options +ExecCGI
    AddHandler cgi-script .py
    Options +Indexes

The complexity isn't that much different, it's just that Python provided no compelling reason for me to switch to it. (And, frankly, even with Flask still doesn't for simple single-file web-page scripts. Applications, on the other hand...)

    console.log('Hello World')

http://www.lifelinux.com/how-to-install-nginx-and-php-fpm-on...

Looks pretty easy to me.

Then again, I compile my own version of Apache with FastCGI and PHP-FPM all the time.

And if you're relying on your webhost having your language-of-choice already configured for you, well, you can find webhosts with most of the obvious choices already configured. So what does that leave?

I would suggest that PHP does not, today, have any advantage over other competing languages and frameworks in the "it just works" sweepstakes.

What we need is a Douglas Crockford for PHP.

A “PHP: the good parts” and a good PHPlint would do wonders to the language and community.

http://www.xarg.org/2011/06/php-hacking/

It's very rare to find webhosts that configure Python, Ruby, Node or the rest to be as easy as "upload a file, click reload."

One reason is the wonderful statelessness of mod_php's execution model: it forks a new process for every request, and destroys it at the end. It's inherently a much more stable environment than the competitors -- you can't save anything inside the interpreter for future requests. This makes server administration easy, and probably shared hosting easier to manage.

My point was that this is true for any language.

You seem to be suggesting that the odds of picking a web server at random and having it be so configured for a given language is pretty low, which seems like quite a different issue, and (in my view) a pointless one. Nobody picks a webhost at random and just hopes that they have support, so the question is can you find support if you want it. :)

In any case, it's also incorrect in the case of Python and arguably Ruby. The first three mass-market shared webhosts I can think of are Dreamhost, Webfaction, and Hostgator. Without any configuration at all, Dreamhost supports both Python and Ruby scripts as CGI programs, Hostgator supports Python scripts as CGI programs, and I believe Webfaction does as well.

(Node is a lot newer and, admittedly, doesn't seem to have any support among mass-market shared webhosts.)

I think, because PHP servers are so stable, that's part of why they're so common on shared web hosts. For example, running a WSGI server is much more complicated. If a WSGI app goes bonkers you have to restart the relevant server. In mod_php, just kill the process.

What would be interesting is a forking-style server for Python or another reasonable language.

1) PHP is commonly implemented via CGI by many webhosts, even today. Not only is it generally considered more secure, but it lets you easily run multiple versions behind the same Apache instance. The performance hit isn't bad, either. So I'm not sure what "PHP is ... better than CGI" even means.

2) PHP is not particularly stable and it is not uncommon for a PHP process to hang until killed, often soaking up 100% CPU time. The stateless nature does make it easier to just kill it whenever it goes crazy, but it doesn't really have anything to do with how often it goes crazy.

3) You can configure servers in all sorts of ways, but there's nothing inherently harder about WSGI. You absolutely can just "kill the process".

4) I honestly have no idea what you mean by "a forking-style server for Python". Is there something you dislike about all the current ones? :)

http://news.ycombinator.com/item?id=3826416

(@lmm: Sorry, I can't reply directly to your post.)

I'm willing to believe this - but if it's true, where are the cheap shared webhosts with WSGI enabled? Or do you think there's some other reason PHP is so much more widely available?

http://wiki.dreamhost.com/Passenger

It's not like PHP solves any of the real problems, like how to manage upstream changes, how to automate releases, how to rollback database schemas after a bad release, and so on. The reason why nobody ever talks about those things is because everyone handles them with downtime and swearing. That's not software engineering. That's fail.

Edit: To be a bit less snarky here, you are arguing that the sunk costs of learning to use a computer justify more effort spent in getting a web site running just because the effort already sunk dwarfs the additional effort required. But in fact not only is that cost sunk but once I've learned to use a computer my time and energy is suddenly more valuable.

There's a place for doing things fast, and a place for doing things right. You're wrong to assume everything requires the latter.

I worked tech support for a shell provider in the 90s and I helped a LOT of users work through the mechanics of setting up a cgi-bin. One of the most difficult concepts for users without a technical background was file permissions -- specifically the execute bit.

I believe PHP's ease of use primarily stems from what most would consider a security vulnerability: mod_php instructs apache to execute code from php files without the execute bit set. This is inherently the same sort of issue behind email worms on Windows -- exec handlers which pass code to an interpreter without honoring the lack of execute permissions.

It's a terrible idea, and also widely popular. I have personally seen users switch from Perl to PHP purely because they could not figure out how to set the execute bit in their Windows FTP program.

The rest is inertia, as far as I'm concerned.

I also think it's a micro-optimization for the wrong thing. It's like buying a car based solely on how close the dealership is to your house. You only have to do the initial setup once (by definition) but you have to live with the consequences of your environment of choice every single day for the rest of the project.

I'll go to a crappy coffee shop if it's the only one around, I'm willing to go very far out of my way to get to the car dealership that has the right thing for me.

But in the end, what's most important is that the car/language gets you from Point A to Point B.

Really?

The easy of deploying a single-purpose script / hello world is always trotted out as the reason PHP ever became popular.

Yes, even in yesterday’s big item “PHP: A Fractal of Bad Design.”

Comparing the rails app config system to PHP.INI, ini_set, .htaccess and the million other ways to configure PHP and considering the app config system to be a rube goldberg machine is really unjustified, the very configuration of PHP itself pretty much non-deterministic.

http://www.jwz.org/doc/worse-is-better.html

As other have pointed out in this thread, you can easily configure a web server to behave like that for files in other languages like Perl or Python.

PHP is a reasonable templating language. That's what it should be used for.

If you use a framework, you're golden, but at that point you could be using any language.

It's like the people 10 years ago saying "if [other OS] was as popular as Windows XP, it'd be overrun with malware too". No. The issue wasn't Windows marketshare, it was the completely crap security.

(...on that note, I just realized how useful it would be if Dropbox's Public folder executed PHP.)

Looking for happiness? Heroine "just works".

Hungry and poor? Eating McDonald's three meals a day is cheap and easy.

It might sound scary. But in reality 'merit' is not the only motivating factor for adoption of anything.