It just works.

If you have a web server configured to run PHP, then it's ridiculously simple to get a page to execute. Just put a .php file on the site and it runs. Done.

You don't have to jigger a bunch of components, dink around with a bunch of Tomcat or Ruby on Rails or proxy or other annoying settings. Most other web execution environments have a bunch of Rube Goldberg machine components you have to plug together to get them to work. It also performs very well and supports a lot of things.

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

  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

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();

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

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.

And yet there's nowhere like it. You could move to some ideal community somewhere, and maybe you visit there now and then because it doesn't have all those other problems, but all the arts and culture, all your favorite restaurants and bars, all the meetups and hangouts and friends and co-workers make your city worth the downsides.

PHP has no fucking culture, the vast majority of 3rd party libraries and classes and snippets are garbage, the vast majority of tutorials are garbage. There are some gleaming institutions like Symfony, and some little places that are trying really hard to make it a better place, but other than that it's a wasteland.

Let's not romanticise dog shit. Yes, the original guy's post was unnecessarily harsh to the development community and people who work hard to make their life in said city, but this city is a clusterfuck in comparison to pretty much anywhere else. It's one redeeming feature being that it's easy to get to and everyone's heard of it.

Here's where I disagree: it's not enough to say "hold your nose around these parts, but it's OK because those few blocks on Main St. are worth it."

There will be flaws in any city, and sometimes due to mismanagement, the flaws will be neglected until blight sets in. Here's where the citizens of the city need to step up: they either flee the city and it continues to decay, or they acknowledge the flaws and address them. Don't just accept the downsides! Fix things. Make improvements. The city only thrives on the investments of its citizens.

Rasmus himself should give it a try as a side project with a different name. I would follow him from day one.

PHP has a lot of bad parts and, like javascript, is asking for its cup of coffee. The time is ripe.

Then again look at what happened with Perl 5 / Perl 6 transition or specifically with the one that didn't happen.

There are three opportunities right now in front of our eyes we are all missing: a simpler-than-node JS on the server implementation, a rectified php, and a simpler functional language for web development. Bonus point: a universal templating system, like jinja, for all programming languages.

As soon as I finish the course about compilers I'll jump head first to try to solve them all.

I don't agree with ever design decision made for the syntax, and I've not used jinja, but it has the universal part handled quite well.

The idea of a roasted PHP is interesting. It's not a no brainer in the way CoffeeScript is though. There's no real choice of language in the client-side, but there is on the server side.

Server side devs can just learn ruby/python/.NET/Scala. Client side devs are probs best switching to JavaScript or something very similar.

I rather see a 'for' statement than imply that an object is 'loopable', or an 'if' instead of guessing if the var is boolean.

I rather see a differentiation between statements and variables like {% statement %} {{ var }} like in jinja.

I don't support the idea of logic-less templates. Everything in the right measure. Not a full-fledged language inside the template but basic loops and conditions I think are ok.

I am always complaining about syntax but I believe if it is too noisy or it makes me think about its meaning, it's too complex and should be simplified.

As I've stated elsewhere on the thread, I prefer the idea of giving another language the ease of use of PHP. It is likely to be less work, especially in the case of Lua (super easy to embed in C). And the compiler is already built for you. :)

So, I'd like to know if C is the only way or if there are new papers that I don't know of for implementing modern compilers before committing to C. I am just starting so there is a lot to read about different contexts and ideas.

(PS: Java is not an option)

I don't think you have to use C++ to target LLVM. I think you can output LLVM IR from anything and then just call LLVM from the shell to get an executable.

PHP the language sucks ass.

PHP the environment (part of the server + html processor + no setup or configuration for most users + page is the app + etc..) = WIN for many many people.

Not a single other environment has ever duplicated that. Until someone does they'll never displace PHP. It's ripe for the replacing but understand that it's not just the language, it's the entire environment surrounding it.

Someone in the Rails community is trying with a small start.

http://www.kickstarter.com/projects/1397300529/railsapp

Ruby and its community are far from perfect. The biggest difference that I see between it and other communities, is that when a lot of people come about some negative aspect of using Ruby, eventually within a few months people start working on actually fixing it. X number of months later, it ships.

[1] http://news.ycombinator.com/item?id=3824767

* Syntax? Sucks * Arrays? Or wait, are they hash tables? Sucks * Stdlib? Sucks * Performance? Sucks

PHP doesn't have arrays, it has hashtables. Although PHP probably got there by accident, consensus in dynamic languages today is that the hashtable is the superior default collection datatype.

The standard library is state of the art in C, which is most of the time state of the art, full stop. The interfaces to the libraries are awful by way of being inconsistent.

Performance is more than good enough. Scaling it properly is more of an artefact of good application architecture, but this is the case for any environment.

But I think that the things PHP really has going for it (huge installed base of the runtime, huge installed base of legacy apps, huge developer community) aren't going to smoothly make the jump to a new language. And once you've given up that sort of backward compatibility, why not fix a few other things while you're at it?

Still, I think there might be potential for a PHP-like language that breaks some backward compatibility but fixes a lot of basic things like unicode support, modules loaded at startup or runtime rather than as a ./Configure flag, syntactic quirks, etc. Something where you could spend a few minutes to a few hours (max) refactoring a PHP script into PHQ (or whatever you want to call it) script and gradually modernize your app.

It seems like it shouldn't be too difficult to write an automatic converter from "PHP" to "Improved PHP", which might solve a lot of these issues.

http://www.addedbytes.com/blog/if-php-were-british/

Yes, PHP has mass appeal for people that are happy to limit themselves to the lowest common denominator, however people that want to reach even a tiny bit further can discover other languages that have better ways of doing things.

For instance, his "Hello world" example is completely fucking inane, and just spitting out a thing like that will lead to poor app design and unmaintainable spaghetti code.

Depends on how you define the language? Nobody is twisting your arm, you don't have to use any of the inconsistent syntax. Just write your own functions.

The core language is actually very similar to C.

I wrote a few tools for my IT team a month or two back. I needed a Quick and Dirty web UI. How do I write some .py files that output HTML, put them in a web directory, then goto http://server/tool.py?

It was just easier to use mod_php and rewrite the simple tools in PHP. Trust me, I REALLY wanted to use Python, but couldn't. To be fair, I didn't have superuser, but I did look for docs on how to do this for Python, and apparently isn't not easy. You have to use WSGI or something? I don't know.

My tool now works well, in PHP.

You need different knowledge than PHP, but I can't say that it's harder than PHP.

It's hard to argue with those sentiments. And I think the root of the argument stems from the diverging convictions of two distinctly different camps of hackers. There are grease monkeys who love tinkering and see value in a tried-and-true tool that works everywhere. And then there are the craftsmen who strive for elegant code and choose their tools carefully. (There's truth in both of those aspirations. Let's not get carried away in value judgements between the two camps.)

But hearing "PHP sucks but I like it" sounds like Stockholm Syndrome to me. There are some great aspects to PHP that other web stacks and frameworks could learn from. Yet there are some major flaws that actually get in the way of productivity. I hope we can keep the discussion constructive and learn from both camps in building the future of web programming.

Using the two together seems to imply we have "skilled people who care about elegant code and tool selection" and "mechanics that like to tinker". Like I said, I don't think that is how you meant it... but that is how it comes off to me. And I tried really hard not to project any value judgement.

The "craftsman" approach in the analogy is presumed to be more deliberate in his work, placing more emphasis on ensuring that the highest quality work is assured, and comparatively less on the practical matter of ensuring that it delivers what is needed on a short turnaround. One aspect of this analogy that may be relevant to consider is that craftsmen are considered to produce high-quality furniture and other products, but those products are quite expensive compared to the products made in factories that most people (can afford to) buy.

In professional development, software developers are generally expected to balance these concerns. Produce the highest-quality product that it is practical to deliver within a reasonable time frame.

No doubt this analogy is still an oversimplification of what PHP developers (and other developers) are like, as virtually all analogies tend to be. But it isn't intended to be derogatory toward PHP developers -- or toward developers in general whose focus is on shipping a product and not producing the perfect architecture.

Does the analogy apply to enough of the PHP developer pool to have value? My guess would be yes, but if your experience dictates otherwise, I have no problem with that assertion.

http://i.imgur.com/pG3q7.jpg

Different people will end up enjoying different tools. I started web development with Ruby and Rails, but find that I really enjoy PHP. Then again, I don't have to maintain anyone else's crappy code. I find that when I write clean, well tested PHP, it really isn't frustrating or painful.

If you prefer something else, that's great! Use it. I guess these types of debates aren't exactly unique to this industry though. When I used to lurk around automotive message boards when I was younger, I recall some pretty epic flamewars among Chevy/Dodge/Ford/etc. fans. Everyone loved their favourite, and were certain that the others were clunky pieces of crap. Sounds a lot like programming language flamewars... :)

Oddly enough, that man's programming preferences are even more hilarious: he likes to do his web development in the scripting language for his favorite furry MUCK. I'm not even kidding; he bolted it onto a Web server somehow and actually did paid contract work in this language. And since he was the only one who knew how to use it, it meant job security. Up to a point. After he got fired, he was also the only one who knew about the back door he snuck into their MUCK-based application server.

Mofo was Dennis Nedry in a dirty fox fursuit. Or not, as the picture shows.

Try getting good at a different programming language, then write your blog post about how PHP is awesome.

Also, your comment kind of becomes moot because he goes on to say "I do know and actively use Python and server-side JS ..."

No, but you appear woefully unqualified to put forth any kind of opinion as to why the language you like is a good language if you have no frame of reference.

I know Python, and I really like Python and think it is awesome.

Sure, but you have no basis to make a comparison. You just happened to luck out; Python is a great language. PHP is... not.

-C#

-Java

-PHP

-ActionScript 3

-Javascript

-C/C++ (not so much now but did in the past)

-Objective C

and I've played around with Ruby and Python a little.

Knowing all these languages, I still think PHP can be damn good when used properly. If you look at some of the frameworks built with it, they are clean and powerful.

I also think C++ is a pretty bad language, but you can do some very impressive and clean -- and most importantly, maintainable -- things with it if you use it properly. Unfortunately there are lots of definitions that people have come up with that detail the "proper" subsets of C++ that are safe to use, with disagreement on a bunch of things. (And for the love of $DEITY, please don't lump C++ in with C, which is really a beautiful, amazing language.)

Every time I've switched languages there has been a transitional period where I've bemoaned the lack of X in the new language, and later wondered how I ever got by without Y, which lets me do in 10 minutes what took 4 hours and hundreds of lines before. Each new language or technology is a new tool in my toolbox, which allows me to make an informed decision when choosing how to build a product.

So if you've only ever used one programming language, then yes, I'm going to take your opinion with a mountain of salt.

It's ok to have a favourite language, it's ok to love your favourite language and sing its praises, but if you can't point out the flaws of it, you're not a good programmer. Your opinion won't be taken seriously. You don't have the experience of working with it long enough to be bitten by the warts, and you don't have the breadth of working with other languages to know what you're missing.

And his reason is because of its ease of use and the fact that it works. That to me sounds nothing like "PHP is awesome." Sorry to put it this way, but it looked like you put words in his mouth.

I could get a new set of screws and screwdrivers, but it's a lot more difficult and expensive than just using the Phillips stuff I have lying around. Depending on how important my project is (am I making a load-bearing shelf or am I putting up a poster frame?) the answer may differ.

Common in Canada, where they were invented. They're square head. Nearly impossible to strip, will stay on your driver with no support at almost any angle.

Not well known in the US because of a decision Ford made nearly 100 years ago to not pay Robertson the price he was asking.

Thus, to this day, any product that comes with screws is likely to come with Phillip's head, and all of its terrible downsides (I keep a supply of Robertson heads so that I never have to deal with Phillips' inherent shittyness).

Bad legacy decision making and inertia conspire to aggravate generations, long after the original thinking behind those decisions stopped making sense. The parallels to PHP are pretty clear.

(Of course every analogy holds only up to a certain point.)

The American bias towards towards the Phillips screwdriver has mostly to do with the gift of patent made to the government in order to support the war effort, putting them effectively into the public domain. They were better than flat screws/drivers, but that's not saying much: when I worked in aircraft maintenance, about half of all of the Phillips-head captive fasteners (Camlock or Dzus type) on inspection and access panels needed to be replaced between periodic (400-hour) major inspections due to stripped heads.

Let's keep that in mind. The goal and the end-result isn't a monument to superb software engineering. What we create are experiences for, mostly, non-tech users. How the sausage is made almost isn't important (as long as it doesn't kill you). It's easy to get lost in the pursuit for technical excellence and ignore the realities of building a business.

The fact that Facebook is built on PHP should pretty much tell the story and put a lid on these endless arguments: You use whatever tools you have available at the time to create a good user experience. People don't pay for your choice of programming language. In fact, they couldn't care less.

That's not to say that the tech world should not strive to be on a path of continual improvement and technical evolution. Not at all. I guess what I am trying to say at one level is "quit griping and get back to building a product, nothing else matters".

That said: What might be a likely improved successor to PHP? By this I mean, a language that can gain wide adoption while dealing with a number of the issues of PHP (and other languages) and has a high likelihood of being deployed as far and wide as PHP is today.

Until then, all this anti-PHP hate just seems... pointless. As you said, we create experiences for users who ultimately don't care what is beneath the hood as long as it works and doesn't blow up.

There are a lot of PHP systems out there and there is a lot of money to be made as a developer who focuses on PHP. It may not be the prettiest language, but I know why I focus on it - it makes me money. I use other tech (rails, ObjC), but PHP is my bread and butter - and if you do it right, PHP really isn't that bad.

The only time I've seen PHP apps blow up is when they are past due for re-development anyways - a symptom that is not unique to PHP. Anyone who's seen Rails spaghetti knows what I mean.

Pretty damned simple. And cheap, for the level of hosting you get for $6 per month, Heroku is free.

As far as Rails spaghetti, if you're using TDD, then it's easy to fix things if new code breaks old code.

What you are pitching is not a language, it is a deploy interface provided by a server. But does everyone agree that PHP has the best possible deploy model? Not at all.

I am happier with languages other than PHP. I gather you are not. That is fine, you use PHP and I won't. There is absolutely no necessity for other languages to ape PHP in an attempt to capture the attention of people who prefer PHP anyway.

    include 'app';
    include 'models';
    include 'templates';

    $data = models::getCustomers()
    $view = templates::parse('customers',$data)
    app::show($view)

The first sentence is mostly accurate, but I disagree strongly with the assertion in the second sentence. Grouping related functionality into libraries reduces the cognitive load of programming. The same could be said for his assertion about the benefits of HTTP as a "first-class citizen."

I do agree that getting a PHP application running on a LAMP stack is easier than say getting a WSGI implementation up and running, but this has nothing to do with libraries.

As far as the benefit of first-class vs libraries for handling the request, that's something to consider (as there are arguments on both sides)...

Maybe there is just a fundamental brain-structure difference between individuals... I don't actually think PHP is easier for a beginner than something like Sinatra, so I don't buy the explanation that PHP is easier for those new to programming.

Objective-C, when used like Objective-C and not just C-with-classes, is a lot like Ruby. Both have a shared heritage in Smalltalk.

E.g. http://www.cocoadev.com/index.pl?HigherOrderMessaging

I leave assigning these as an exercise for the reader.

I'm creating an ad-hoc language right that also has this quality. I cringe as I shoe-horn one or another crude extensions into it and then step back and realize that for its particular purpose, it would be harder to do that much better.

I guess that people still think that they know better than their sysadmin regarding how to set up a production environment (regarding to the php.ini rant). Maybe because the sysadmins know that expose_php = off turns off those pesky easter eggs. Or they are better at Reading The F[...]riendly Manual (http://www.php.net/manual/en/ini.core.php#ini.expose-php).

Had a good laugh at the complaints about PECL libraries that provide "everything but the kitchen sink". Last time I checked, it was still "The PHP Extension Community Library". People should complain about that particular project, if they need to. It has nothing to do with the internals team.

Wondering how he could forget about the <script language="php"></script> bit.

I work all day with PHP even though I love Ruby (and Rails, and Sinatra...) because practically ALL our client base wants either a static site or Wordpress, or another PHP-based CMS. Few of our clients have the budget for a custom web app with its own custom web stack to power it.

There's almost nothing faster to get bootstrapped into a functional application or script than PHP. Assuming your server is already configured with PHP you just upload the project.

PHP 5.3 and 5.4 give me great hope for the future of the language.

Its not like phps ease of use is not a good thing -- it is. but other languages/platforms aren't _that_ much harder

With PHP people have something that just works, reasonably, and given that an interpreter lives the lifespan of a "page view" making big errors is non trivial.

So PHP is not a good language, but many other languages should learn something from PHP. The problem is that the community backing this better dynamic languages, such as Python and Ruby, still for some (IMHO obscure) reason aren't shipping something that is PHP-alike, but just with a better base language (without trying to add tons of abstraction layers).

I no longer use PHP because after years of using better languages (I like Ruby as a "practical language") it's too hard to return back to PHP, but I often find myself fighting with the useless complexities and layers of abstractions that Ruby contains "by default". Not in the language or the implementation itself, that is good enough IHMO, but in the tons of gems around and in the integration with the web "side".

I think the standard libraries could do with an update, to add the consistency they deserve, and do update them to use modern features. The community for PHP is reaching a point of maturity that it has not seen before (look at composer, PSR-0, symfony2 and ZF2). I think this maturity is making the community a good place right now. I'm not leaving it anytime soon.

Take away PHP, watch the major sites of the Internet disappear. Where would we be with no Wikipedia?

Good god, what debuggers have you been using that makes PHP and xdebug seem like it "works quite well".

a) All languages, frameworks and technologies are bad and ugly, each in many of their own horrible ways

b) Nobody has any fracking idea what they're doing (mostly)

c) Your best bet is to find something that does not hurt you as bad as other stuff and stick with it. If you enjoy php, that fine (of course it's completely beyond me how it is possible to enjoy it, but its not the point).

On a side note, after having spent most of my time programming in high-level languages, I wonder how things are down there in bare-metal-programming land. I've grown tired of web development and I wonder what it's like programming in an environment that does not have poorly designed, inconsistent frameworks and leaky abstractions, only registers, memory and pins :) Too bad it's probably too late for me to get started there.

Because PHP was built for a web environment and has features that make it quite useful out of the box, for that environment.

With Ruby or Phython you need to do extra work or jump into a framework to get to that "starting point". However, if you are going to start comparing Ruby/Python with a framework to PHP, then you need to look at PHP through one of the prominent frameworks out today (Symphony, ZF, Etc). Otherwise you are comparing apples to oranges.

With 'library' typically meaning 'extension' in PHP parlance, you do. The socket methods are part of the Socket extension, cURL is an extension you have to compile in.

The only reason you'd not actually notice this is because, unless you compiled your own copy of PHP, it will have been done in the default install bundled with the OS, or in xAMP, and will have automatically been injected into the 'global' scope.

This is all just daft, though. You could go on forever with the "it can't do X but it can do Y" schtick, with any language.

Python developers user REPL to quickly test elements of their code or play around with the language; PHP developers hit refresh.

[1] Gentoo's USE flags for PHP (the ones with - are the ones I haven't compiled in for my box):

    apache2 bcmath berkdb bzip2 cgi cjk cli crypt ctype curl curlwrappers fileinfo filter ftp gd gdbm hash iconv ipv6 json mysql mysqli nls pdo phar posix postgres readline session simplexml sockets spell sqlite sqlite3 ssl threads tokenizer truetype unicode xml xmlreader xpm zip zlib -calendar -cdb -debug -doc -embed -enchant -exif -firebird -flatfile -fpm -frontbase -gmp -imap -inifile -intl -iodbc -kerberos -kolab -ldap -ldap-sasl -libedit -mhash -mssql -mysqlnd -oci8-instant-client -odbc -pcntl -pic -qdbm -recode -sharedmem -snmp -soap -suhosin -sybase-ct -sysvipc -tidy -wddx -xmlrpc -xmlwriter -xsl

That's why we had Unix boxes instead of LISP machines, that's why we had PCs running MS-DOS and not Amigas, why we later had PCs running NT instead of SGI Octanes, and nowadays people have PCs running windows7 rather than elegant iMacs.

"Cheap and easy, quick and dirty, and get the job done" is a perfect description of PHP and the very reason for its success.

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

Also, why not just call them an API to procedures written in C and realize that none of us scripters are coding in anything.

I code in Lua.

My feelings on PHP are much the same as my feelings towards JavaScript - most of the code I've encountered in the wild was cobbled together by designers who knew nothing about programming and a lot about how to cut and paste scripts together. I find myself blaming the languages for the mess people left me.

But occasionally, much like JavaScript, I'll encounter some PHP code that was truly written by a master - someone who really knows how to use the language effectively, who doesn't intermix SQL, HTML, PHP, and JavaScript in the same 1000 line index.php page. Well-constructed code, designed with purpose.

I suppose that's the same with any language, isn't it?

PHP, like JavaScript, is everywhere, and if you solve other people's problems for a living, I think you need to know it reasonably well. At least well enough not to make it worse than the last developer.

Embed in HTML, wire stdout to the web page. Add a couple functions for "first class HTTP support". Write an Apache module. You could probably make it even easier to deploy than PHP, with the benefit of a nicer language. Obviously I'm oversimplifying, but it's mainly glue code. Seems like the hardest part is getting it deployed on the $5/month hosts.

Is there some obvious reason it hasn't been done? Did they already and nobody cared? If I didn't already have a massive project backlog I might take a shot at it. It seems like a good opportunity for someone to make a difference.

Edit: Crud, they already took the name mod_lua: http://httpd.apache.org/docs/2.3/mod/mod_lua.html

The one point I'd disagree with is his assertion that PHP doesn't have a templating language. Of course it doesn't: PHP is a templating language. That's what it was written to be. Many of the uglier things you have to do in PHP are related to the fact that what the language always wants to do, by default, is spit out a web page.

If what you want to do with your software is output web pages, then PHP is the best call. If you want to do basically anything else, pick another language. But at web applications, PHP just can't be beat.

Pretty much every PHP app in the world shares a database. So you've shifted your scaling problems from an area that programmers understand and control to a 1-MLOC mystery.

I bring this up because I have a few friends who make their living saving the asses of PHP programmers who buy the notion that PHP is magically easy to scale. I hear a lot of horror stories from them about the absurd sums of money spent cleaning up the messes.

I do agree that PHP is fine for doing basic web apps. But I don't know anybody doing anything serious with PHP that only uses PHP, because serious web apps eventually need more than you can do in that language. PHP's "shared-nothing" scaling just means that when the going gets tough, some language other than PHP will be doing the work.

True, however in my experience it's pretty easy to scale the database layer. One beefy DB server can easily handle 2 or 3 front end servers with even mild caching. If you get aggressive in the caching strategy, one DB server can handle up to 10 front end boxes. And if you need to scale beyond that, replication is a well understood paradigm (sure, not by normal app developers, but there's plenty of resources out there).

> I bring this up because I have a few friends who make their living saving the asses of PHP programmers who buy the notion that PHP is magically easy to scale.

I never said that it was magically able to scale. I said that the language is easy to scale. What you do with it is on you. So if you're writing garbage code, you're going to get garbage scalability...

Note, though, that you've introduced another shared resource, cache servers, to fix the problems that a "shared nothing" approach introduces. Because once again, the "shared nothing" line is bunk.

I'm not sure your point about a database is valid; Python and Ruby and Perl apps are all using a shared database (or newer k-v store) as well.

I agree that most web stuff written in scripting languages is built around a database for shared state. But in more powerful languages, you have other options.

On the other side, put good developers on a PHP project and you will get a good product, regardless of the haystack position and possibility to suppress errors (etc. etc. etc.). The fact that there is so much spaghetti PHP out there doesn't make it impossible to write good code with it. And that matters a lot.

Need to know how to use in_array?

http://us.php.net/manual/en/function.in-array.php

Not only is there a quick reference on the top, but clear, concise, and diverse examples on how to use it if you don't want to spend time thinking about how to work the arguments.

Maybe the expert programmer doesn't really care about these qualities, because javadoc is "easy" to them, but it doesn't compare to this for me.

P.S. As someone who has dabbled with Ruby, Python, etc. I do acknowledge they are vastly superior languages in many respects.

If you can't get syntax/semantic changes adopted in a single language then getting a whole new language adopted is a non-starter.

I think the core PHP developers should take a long look at the inconsistencies of the language and formulate a plan to reduce/eliminate them without breaking backwards compatibility. In some cases, it should be relatively easy but in others it will be very difficult. The inconsistency of "==" would be hard to fix while making sure old code still runs correctly.

This doesn't add anything useful, post it as a link on the original thread. It is just a bunch of noise cluttering up the frontpage of HN!

Given a poorly engineered PHP or Python project, I will always pick the latter. However, if I were to start a project on my own I'm confident enough in my PHP that the language choice is harder to make.

That's true, but my point is that there isn't such a visceral hatred for C and C++ even though they are widespread and notorious for memory leaks, vulnerabilities, indecipherable corporate quagmires (perhaps due to an over-engineered OO architecture or 700 line functions or opaque symbol names or dependency hell, etc).

Besides the lack of language features like @ (error silencing)

Red-flag bad practices exist on all platforms. The horror story of a PHP project littered with error suppression is like opening up a C project and discovering that the control flow is guided by a 200 label GOTO architecture. It's not PHP's fault that the programmer abuses the language, it's the employer's fault for hiring a highschool student at $15/hr.

C is enormously more consistent, better defined and specified, and well-documented than PHP.

It's a solid enough language with a very specific use case, and not even remotely competing with PHP.

PHP is a terribly inconsistent, poorly defined, poorly documented, poorly implemented, poorly designed language that can't do anything better than any of the other languages it is competing with.

The one thing PHP has going for it is inertia. That's it.

Yes, this is a trite and negligible truth of PHP. A developer suffering any significant loss of productivity due to problems like mismatched needle/haystack parameters just isn't very competent. It's a non-issue if the developer is being paid a real salary. I'm not saying these issues aren't important enough to warrant attention, but the debate between maintaining backwards compatibility and squashing bad practices certainly isn't exclusive to PHP.

and not even remotely competing with PHP.

I already addressed this in my previous post. I'm not suggesting that PHP is in competition with C, that should be pretty obvious. I'm asserting that C, like PHP, is ridden with dangerous pitfalls for developers who don't know what they're doing. PHP is just easier to work with for a novice programmer.

The one thing PHP has going for it is inertia

And did that inertia spontaneously emerge from a vacuum? In the spirit of PHP's namesake you've devised a recursive argument to explain the only conceivable upside to using PHP.

You're just hand-waving away the issue. "Yes, you have to keep far more in your head at once to make sure you don't step on a PHP landmine, but that's why we're paid the big bucks!"

I'm sorry, but this is a false dichotomy and an inaccurate parallel with C. C's landmines are well-defined, understood, and derive from the target purpose (portable assembly). PHP's landmines are ambiguous, ill-defined, and just plain stupid, often caused by what amounts to a truly brain-dead lack of cognitive effort on behalf of the language authors. The language is poorly specified such that even if a developer should wish to invest sufficient effort, it's impossible to know where they all are.

Moreover, there are such ugly corner cases built into the language and common libraries that some landmines are entirely unavoidable. Whose brilliant plan was it to make fopen() accept URL parameters instead of defining a common stream API that arbitrary stream types could support?

Let's say I want to treat a byte array as a stream -- this is a pretty common thing to do in most languages:

  fopen('data:text/plain;base64,'.base64_encode($data), 'rb');

> And did that inertia spontaneously emerge from a vacuum? In the spirit of PHP's namesake you've devised a recursive argument to explain the only conceivable upside to using PHP.

PHP's inertia emerged out of ill-qualified individuals adopting the language as the most visible available option during a time when there was largely a dearth of options and limited understanding of the web as a platform and "what comes next" from CGI.

People -- collectively, as a group -- adopt poor solutions to their problems, simply as a matter of compounding gravitation and a lack of understanding of the long-term implications.

It's simple group decision making, and it's not reasoned, nor is it necessarily likely to produce the best possible answer, or even a good one -- especially when the group in question is ill-equipped to understand the problem space they're working in.

Sounds like Java to me :-)

You get nothing in exchange for the extra headaches of PHP.

Of course you receive something in exchange. Whatever explanation you have for the ubiquity of PHP is the benefit one receives in exchange.

Besides, my point is that headaches are not inherent to PHP. Just because a community of hobbyists and novices churn out shaky code doesn't mean that developers employing best practices will.

https://github.com/symphonycms/symphony-2/tree/master/sympho...

Here is an example of quality PHP code. Clear and organized OO structure, useful comments, self documenting method and variable identifiers. Why is this inherently wrong?

This doesn't follow at all.

That's a strawman argument to be sure, but I think it's reasonable to point out given the oft-repeated claimed that PHP is fine for small-scale hacking but is inadequate for "serious" software engineering.

Way to many people jump on the "PHP is crap" bandwagon for no reason and they all repeat the same thing over and over.

I'm not a big fan, but I like the fact the developers seem to be trying to improve it.

http://www.php.net/filter