> Except now it's 2012, and fellow programmers are still writing long screeds bemoaning the awfulness of PHP!

Yes, and not only did Jeff write one in 2008, but he wrote another one just now. You can't write 10 paragraphs about what a blight PHP is and then pretend like you're being constructive by admonishing us to create better tools.

In fact what everyone is doing with these rants is bike-shedding about an easy-to-hate language. It makes an easy topic that drives a lot of traffic because everyone has an opinion. It's just tabloid garbage for the hacker set.

A more objective view of things is that PHP is a capable-if-ugly language, and it co-exists just fine with thousands of other programming languages and frameworks all with their own visions, communities, and production applications. The existence of PHP is not harming other "better" languages at all. And if you really want to make an argument about languages hurting the state of programming, how about asserting that the dominance of imperative languages is irreparably damaging the ability of most programmers to work in functional languages where solutions are fundamentally more robust. Or what about the damage that proprietary platforms like .NET (which Jeff uses if I'm not mistaken) or iOS do to the programming world by restricting progress to a single company.

I won't belittle Jeff's contributions to the software world, because Stack Overflow is an amazing service, but despite the fact that I hate PHP, Rasmus' contribution to the software world is certainly much more important than Jeff's feel-good blog fluff.

PHP is used for web development. Microsoft's best alternative for web development is ASP.NET MVC which is open source.

The problem is that the developers of rails / grails / Wt / SproutCore / Flex / Struts / GWT / Django / Flask / Zope / Merb / Zotonic might be sure their framework is the greatest ever, and clearly worth a couple of days (or even a couple of hours) of someone's time to get it all configured and get started. However, I just see this giant list of options, each of which is in it's time the 'best thing ever'. How am I supposed to know which one to choose? Getting people started quickly and easily should be priority 1 if you want more users.

EDIT: Oh, one other strength of PHP. Many people when they start want to turn a static website they already have into a dynamic one. This is how I started on PHP, just including fixed headers and footers in a website. Then slightly customised headers which knew which page I was currently on. Then adding cookies to remember what users had already done. Then finally full user support.

In general, one thing PHP excels at adding the '1% dynamic' to an existing static website. However, I don't think this is as big a market as it once was, I don't think that many people learn a lot of HTML and make big static website anymore, then try to add dynamic elements later (or perhaps, I just associate with different people nowadays)

You're right about the 1%, and it's why classic ASP did as well as it did for a while too, until that was killed off. The fact that big players who once scoffed at PHP now embrace it (MS is a big one) shows how big PHP is and will continue to be for the foreseeable future Will PHP be here in 3-5 years? certainly. 10 years? possibly, but with a difference at least as big as php/fi -> php5 is, so current php5 skills won't really be of much use on their own.

How much PHP do you use Jeff? Lets assume none. How is PHP hurting you? I mean seriously, how much contact do you even have with PHP?

PHP is easy to learn, easy to make websites with. There are a tonne of paying jobs which require PHP. PHP runs a lot of websites.

I am a PHP developer. I prefer Python but my PHP job pays me just fine. There are a lot of things about PHP that I don't like but it gets the job done just fine. You can write reasonable code with PHP. You can write secure code with PHP.

The main people who have problems with PHP are either ex-PHP developers who usually have gone on to Ruby and look back and fire a few shots at PHP. Or people like Jeff Atwood. Undeniably smart and talented programmers who for some reason are irked by the mere existence of PHP.

Please get over yourself.

I've written web apps in: Ruby (both Rails and Sinatra), Javascript (Node.js with Express), PHP (my own framework, CodeIgniter, and eying Laravel), and been maintenance programmer for a C CGI application. I've written desktop and CLI apps in Object Pascal (Lazarus and Delphi), to CLI apps in Go, C++, and probably a few I've forgotten. I've done Object Oriented, Evented, and to some degree Functional programming. I am a polyglot programmer.

The problem is bashing PHP. As Jeff said, PHP's power is its ubiquity and its near omnipresence. It runs on just about any platform with any configuration, with almost perfect consistency. For the most part there's no switching extensions or libraries because of the OS. Develop wherever... deploy wherever... get almost an identical experience without lifting a finger.

In fact, I have great hope for the future of PHP with 5.3 and 5.4 as they (finally!) have added and improved upon the language, and have begun to cull deprecated features. The problem for PHP right now is twofold: web hosts refusing to upgrade in a timely fashion, and legacy codebases that refuse to be rewritten. Both these are demanding backward compatibility, and slowing the advance of PHP.

I'm tired of the bashing of PHP. Bashing, in general, is the absolute least effective way to communicate your point. At least Jeff Atwood is attempting to do something.

The startup scene's dirty little secret is that (anecdotal from several local companies I've worked for and/or collaborated with) PHP development is fast and cheap. Once you have proven you can solve a business problem and get funding, then you can decide if you really need to do a re-write.

There are just too many small companies focusing on real problems(instead of what language their webapp is built in) to make me think PHP is evil or that Rasmus Lerdorf is a bad person.

Makes sense - There's definitely a pattern of bashing the popular languages.

Reading the article, I was struck by its similarity in structure and language to classic Windows bashing rants of the past two decades - i.e. "the problem with PHP is that it has no taste." In fairness, the call to action is radically different; to build rather than to buy something.

Actually, I think it is exactly because it's popular. All languages have odd ends, but you rarely hear people rant over Pythons lack of lambdas and weird explicit "self" parameter or Ruby's incomprehensible scoping rules. I'm betting that once they fall out of fashion, we will.

And no, I disagree. The main sentiment of the article is negative. It's a call to figure out how to dethrone PHP, but without telling us why this would be such an important goal.

Of course that's subjective, and people disagree, but there really does seem to be a real, qualitative difference between the warts on a mostly nice language like Python, and the ubiquitous bizarro world that makes up just about the entirety of PHP.

This is entirely untrue. PHP isn't even a bad language on the scale of actual bad languages. It has some warts but they don't really impede the development of good software. There are many languages that make developing good software nearly impossible.

I don't know about impeding the development of good software. Warts can always be worked around as long as you know about them and how to handle them. But that doesn't mean they don't matter, and PHP has so many that it's difficult to enumerate them.

What other popular languages silently convert strings to floats and then do math or floating-point comparisons on them? What other popular languages have literally hundreds of failing unit tests in their mainline implementation, allowing ridiculous and insecure regressions that were actually caught by testing but never noticed to ship in an official release?

I doubt there's any one wart that's exclusive to PHP. What's remarkable about PHP is how it manages to gather so many in one place. Each one alone is not that bad, but the sheer number of them is astounding.

JavaScript. Most of the "issues" around comparisons/conversions/etc equally applies to JavaScript as it does to PHP.

But PHP does some very stupid casts but it's really just one problem. In the lists of "failures" tend to show that same problem 15 different ways to show how screwed up things are. If your code is well designed and secure you don't encounter these problems anyway.

> What other popular languages have literally hundreds of failing unit tests in their mainline implementation...

I'll give you that. Since that happened, the PHP developers have worked to ensure it won't happen in the future. No platform is free of particularly big security fails (Rails).

For the unit tests, it looks like there are still 100 unexpected failures in the latest release:

http://gcov.php.net/viewer.php?version=PHP_5_4&func=test...

Am I misinterpreting that?

Yes, no platform is free of security problems. But the way a security problem happens is as important as what the problem is. That PHP's unit tests are so noisy that important regressions can't even be noticed even when a test exists to catch them speaks extremely poorly of PHP compared to other languages.

I'm not sure when these where run but it would be easy for someone went through all of them and give them a pass. A failed test doesn't necessarily mean that deployment should be held up. 700 failed tests is a different story.

> JS doesn't have all these other problems, though.

JavaScript has plenty of it's own problems. It has legacy things you should never do. PHP has different problems (not necessarily worse ones) and things you should never do. Lists of the horrors of PHP generally include all things you shouldn't ever do mixed together to make it look much worse than it really is.

I've seen similar lists made for JavaScript (you can get some really crazy results) but that doesn't mean shit for day to day use.

Somebody has to fix them; these things don't happen instantly.

Given the fact that they had hundreds of failed test cases and now they only a few is a significant improvement -- and this is while development has continued. They realized the problem just as you describe; there isn't much more to say about it except they're working to fix it.

Like Windows 3.1?

I'm also a PHP dev and I think Python is the safest bet, since it has good support on all platforms already (including Windows).

Show me the fucking code, Jeff.

Many, like me, disagree with that premise, and so consider that he is at best trying to fix a problem that either doesn't exist or doesn't require a drastic fix like he proposes, or at worst is very cleverly tapping into a vein of contention to hype an up-coming product.

The thing is, with those who do genuinely rant against PHP, at least we can have a useful debate with them over the issues. The "PHP is rubbish" posts that feature here regularly almost always lay out their arguments and basis for coming to that conclusion, from which useful (if sometimes repetitive!) discussion can ensue.

I think that the better alternatives, in the general case, are to participate in (or even fork) PHP and bring about the change together.

Which is why I began developping websites with it. But at some point, I felt like it was preventing me from really understanding what was going on behind the scenes, and I moved away from GRails and now nodejs.

I don't hate PHP but I think Jeff's last point is good: we need framework as easy to learn and setup, but that lets you understand how the web really works.

I'm quite curious as to your understanding of how the web really works.

I agree with your point and I just wanted to add that the fact that we have to add in little details like "I prefer Python" just to be taken seriously says more about hacker elitism than it does about PHP.

Why did you say that? To me it feels like you said it so people would take you seriously as a "real" biker. Because surely a "real" biker wouldn't actually enjoy walking unless they were forced, right?

I do genuinely prefer Python. I picked it up when Django first started making noise and I really enjoyed working with Python (not so much Django). Now I mainly use Python to mess around with PyGame.

Its not a difficult to thing to say. For all of PHP's ease there are little niggles which get you down. Really simple things. Is a function called functionname or function_name. Is it ($needle, $haystack) or ($haystack, $needle).

Python is neater and I like neat.

Thought of that, Sherlock? Or should I say Bekas?

> build compelling alternatives and make sure these alternatives are equally pervasive, as easy to set up and use as possible.

A bite later:

> We've got a long way to go. [...] The best way to fix the PHP problem at this point is to make the alternatives so outstanding that the choice of the better hammer becomes obvious.

Basically, Jeff just agreed that PHP is simply better than the rest. The problem is that he cannot accept that thanks to PHP anybody can code something pretty fast. I am always amazed when I see my brother, without programming knowledge improving his wife website like gardening. Small changes here and there. End at the end the website is making money. He never complained about the "awfulness of PHP".

Easier != better. Nice try.

He's going to tweak his site, continue making money and stop caring about whatever the hell his site is written in.

Maybe a little OT, but I can't shake the feeling that he's going to introduce some nasty security bugs if he's hacking on php code without knowing what he's doing. Might not matter, but then again someone could find it and completely ruin his small business.

(of course you can write "secure" code in php, but you need some knowledge to do so..)

Again, from the brother's perspective, perhaps learning Ruby is the tempting shortcut ("I'll just learn this awesome language first and my website will be super easy to upgrade and modify")

...

and then it takes him too long to get back to his website, which has floundered and is no longer popular or making money. Or ruby was too hard for him so he went back to tweaking his site with PHP. Or <whatever>

My point is that it is all about perspective, something that a lot of HN misses. Not everyone cares about technology. Most people just care about getting the job done and making money, using whatever tool is easiest for them to personally use, at the time they need to use it. So to that guy, it isn't a tempting shortcut: it's the best route to prosperity.

The people who prefer PHP are right. The people who avoid PHP are also right. They are solving fundamentally different problems.

[1] http://www.infoq.com/presentations/Simple-Made-Easy

As the article states, if all you know to use is a double clawed hammer, it looks like the best tool for the job.

I'm looking into ASP.NET MVC for a project and if you walk through the "hello world" tutorials with that package they are 10 pages long and filled with lots of magic. As a developer, I understand the significance of that magic and it's long term purpose. But it's probably far from the best tool for the job if your project is simple.

The flaw here is perhaps the assumption that the best tool for the job is the same for everyone and the same for every task.

You choose a problem that you think PHP can't solve[well]. You solve it using your high level language of choice and I'll solve it using PHP. Let's compare the outcome on reliability, ease of re-factoring, speed, whatever .. then, when it becomes apparent that there is little in the way of difference of the end product let's stop the fucking childishness.

I love that sort of phrase, I really do. It's so ... lacking in self-awareness. Really tells you a lot about the attitude of whoever utters it.

Edit: OK, I'll bite. Um, so you're telling me, I lack self awareness because I said "fucking childishness" .. and that you understand me on some level because of it. You might want to get down of that high horse of yours.

Yep, you lack self-awareness.

I also took issue because he didn't point out any actual problems or solutions .. rather he just blanketed PHP as a problem in and of itself and his solution was to replace it. This is not the kind of thing I'd expect from someone like Jeff who runs a site that points out in great detail programming flaws not just making hearsay.

Anyway, then you came along taking offence to my use of the f word. I'm sorry you take offence to harsh language but that's not my problem. Your first response to me added NOTHING to the conversation apart from your own very strange opinion of me because of two words I had said. I figured you where a troll so gave you the response I did. Then I thought hang on, let's check this guy out and see what we can glean from his past posts. You have been active for almost 100 days and your posts seem to point to you being a nice enough guy, so I figured you deserved more than my first general reply.

I also note that you just got your CS degree. Well done, and I hope you have a long fruitful career, I really do.

Terms like "bigoted rant" and "fucking childishness" always give me the distinct impression the poster isn't interested in reasonable discussion -- particularly on HN, given the usual monocles-and-earl-grey manner of conversations here. In my experience, that sort of language only irritates whoever may disagree, and so lowers the level of debate, while achieving nothing of value. As such, angry words on the internet always feel immature to me, so the phrase "fucking childish" struck me as amusingly ironic.

Your challenge to Mr Atwood also came across as facetious; I find it very unlikely that a busy man like him has the time for a code-off, but I could see someone claiming his failure to accept a challenge as a victory by default; and even if he did take you up on it, it would prove very little.

As such, your first post read to me as little more than a troll itself, so I felt I was only being flippant in kind.

To be honest, I would have downmodded your first post and left it at that, had that button appeared to me yet. Instead, in hindsight, I guess I thought I was (from my perspective) "feeding the trolls"; itself far from the best way to improve the level of dialog, I freely admit. It wouldn't help that I very likely came to this thread spoiling for a fight with those defending PHP; it's been a conduit for many headaches since I finished my degree & got a job.

Peace.

I've dealt with my fair share of poor PHP code bases, and have experienced PHP mature over the years into a very capable language; so know how to wield it to the best of it's abilities. If you ever need any advice feel free to email me.

Knowledge is power. Defending your own knowledge by refusing to expand and learn something new is cutting yourself off at the knees (or fingers, as it may be).

From Haskell you can of course go the route to Agda or Isabelle. But Curry is also worth a visit, it combines logical and functional languages.

I, for one, am still learning how to do left-fold based IO in Haskell with enumerators, at the moment.

And it's not that I haven't spent the time learning other languages and working with them. I did a degree in Computer Science and have worked for 12 years in the industry, over which time I have learned and worked with Pascal, C++, Ruby, Lisp, Javascript and dealt with a number of other languages. I discovered PHP early on, but only relatively recently have I really taken a shine to it, particularly with the releases over the past few years, and now I won't work with anything else.

I enjoy my job significantly more than I used to because of PHP.

In the main I don't find it a horrible language, I'm aware of its weaknesses and its "problems" (usually not problems per-se, but things it does differently from other comparable languages). But in the main it fits the way I think and work, and I'm incredibly productive (and I like to think that I don't write code that's too shabby either!).

Yet I thought this post was right on target. I'm busy cleaning and finishing up my PHP projects, and then I won't start another project in PHP. It will be ruby or python, or maybe I'll go functional. It depends on what I want to do. Yes, I can say everything that you so sarcastically proposed, but I also see the value in getting new coders to not start off with PHP.

It got to the point where whenever I sat down to write PHP, I would write it in ruby first as a sort of pseudo-code, then expand the brackets out into PHP after the fact.

Eventually I decided that I would be more efficient just skipping the expanding out step.

You (General you) get companies to hire experienced PHP Devs , even as entry level for other languages and I'll be there in seconds. However, all the jobs I see require 3+ years with that language.

* Let x be the technology you want to work with professionally.

* Spend roughly a year of occasional unfocused off-time building little side projects with x. You can do it faster if you have more drive than me.

* Put those side projects on your github profile or anywhere people can see them.

* Apply to companies that work with x, whether or not they say they are hiring, or take experienced hires from other technologies. Send your github profile along with the application. Preferably go via a connection, but this is not required.

* In the interview/application process, demonstrate strong, language-agnostic technical skills along with some fundamental knowledge/realisations specific to technology x.

YMMV.

There's a lot of frameworks that make many types of web site or web app development easier than PHP. There aren't any languages that were created explicitly with the goal of being used to create web pages (and later, by extension, web sites). OK, there might be a few that have gone by the wayside (ihtml, htmlos, etc), but nothing mainstream.

PHP is "content-type: text/html" by default, which can be overridden for other tasks. Everything else needs to make some adaptation (however subtle) to 'play' with HTML. Potentially something like mod_ruby or mod_python could take off, but probably not even then, as you'd be worrying about including base library stuff or extra modules, the majority of which are already baked in to PHP (gd, etc).

You have a web page up and just want to add a dynamic copyright date to the bottom? Copyright <?=date("Y");?> and change extension to .php (or play with some mod_rewrite rules on apache). Want to capture the output of every HTML page and rewrite some links (while logging those changes to a db?)? automatically prepend a php ob_start() call then append an ob_get_clean() function in the footer, then process away.

Doing these sorts of things in any other tech stack requires a lot more configuration and meddling, or possibly rewriting core site code. PHP can scale down to be nice additional decoration in a site, or can power the whole thing soup to nuts (and can scale up much easier than some other platforms can scale down).

Related: I recently had a basic site and needed to rethink it in terms of mobile toolkit. It was much easier to take what I had an add in jquery Mobile stuff than it was to work with Sencha (as one example) because other tools like Sencha assumed I was starting greenfield, which I wasn't, and I didn't have time to learn enough of their stack to try to extract the bits I wanted. jQuery made it easy to add the bits I wanted, and PHP does that for HTML/serverside aspects of things as well.

Want to kill PHP? Build alternatives to PHPBB, Wordpress etc that compete on ease of use (incl installing, that means have host gator etc support the language used) and PHP will slowly die out.

  "PHP works great for me! It runs tons of websites! I don't know what you're complaining about..."

> there are already easy to deploy frameworks and languages for the web, and everybody who cares about development is already using them.

And yet, amongst your rhetoric, you've conveniently managed to name none of them. Is this an appeal to the silent majority?

I'm convinced that there are really good developers out there who just keep building great products in PHP. Good developers write good code largely irrespective of the language. The code is a mere artificial interface between the developer and the machine.

Brainfart. I meant Rasmus.

A programming language is a tool to get the machine to do what you want. A good tool will help you get the job done faster, and with fewer problems (like, say, security holes). It's not a "mere artificial interface", and if you think so, feel free to go write a web server in Brainfuck.

Even if we take that statement as given, what about everybody who doesn't care about development? Most modern frameworks take it as given that you are (or at least aspire to be) a fairly serious web developer interested in serious web development and are willing to learn a bunch of fairly abstract concepts up front about structuring and deploying apps. Until a framework comes along that assumes non of those things, php won't be replaced. Imagine your user is a domain expert in an area totally unconnected to computers or programming, but has managed to learn a bit of HTML and now needs to put together a site. What current framework targets this particular use case?

Something that doesn't involve any programming. Because getting all of the bits of web development together is hard work, and you're not likely to end up with anything decent at the end if you don't know what you're doing.

But he said nothing about "inventing" a language. In fact said very clearly that he wanted to take an existing language and add to it - particularly the things that PHP does do well.

from TFA:

> "to buff up a open source language ecosystem such that it can truly compete with PHP in ease of installation and deployment"

Currently, no other language can match that. They either require a VM running (Java, Ruby, etc.) or at least have a compile/build step (Python).

UWSGI has a lot of promise, but until it's as easy to get configured as PHP-FPM, PHP is still way easier than everything else.

I suspect that he is being deliberately vague here; in other words there is an announcement coming at some later date and this is preliminary PR. That doesn't make it untrue though.

If you are into .NET and build .NET sites, then cool. I work with a bunch of WordPress sites and WordPress uses PHP...so that's what I use. Until they decide to switch languages, I'm sticking with PHP. Until then, shut the fuck up and let me work without making me feel like an asshole for not conforming to your way of doing things.

Tools evolve over time and saying screw drivers are useless and everyone should use a battery powered screw driver doesn't change the fact that a screw driver drives screws.

If you don't like the tool move on to other tools or make your own and get people to adopt them. Don't bash the brilliant people who worked hard to make the tool in the first place.

My father is 71 years old and codes in PHP! He was never going to learn python, ruby or anything else but PHP was approachable for him. Provide a language with that low barrier to entry and let's talk. Meanwhile I love my dad but we won't be writing the next google and that's ok by him and I both. If he wants that he'll ask me to write it in COBOL! :-)

I just don't see how PHP is more approachable, especially compared to the supposed ease of ruby on rails.

PHP is the A-10 of languages. It's a slow, ugly and easy target. It works pretty much everywhere.

There isn't any one perfect solution, just workable ones.

Perhaps it's best if you either completely take deployment into your own hands, or you let someone else do it for you. Given all that, rolling your own could still be made simpler.

Try these guys (they also do rails and other stuff as well): webfaction.com

Compare Ruby to PHP and something like Symfony to Rails.

Learning Ruby: approachable. Learning PHP: approachable. Learning Rails/Symfony: run for the hills (for newbie programmers).

Languages !- Frameworks (at least for the purposes of this comparison)

Him figuring out <? print date('Y'); ?> is fairly easy when he already understands html.

  One of the explicit goals of my next project is to do whatever we can to 
  buff up a ... particular ... open source language ecosystem such that it can
  truly compete with PHP in ease of installation and deployment.

I was expecting an elitist diatribe about PHP (because this is perennially popular amongst particular programmers) but that's not what this post is intended to be.

Interestingly Jeff does take the usual potshots at PHP almost like he thinks he'll lose street cred if he doesn't but the basic message I agree with: if you want someone to stop doing something you consider undesirable give them better alternatives.

That being said, I simply disagree with the premise. PHP has a lot going for it:

1. The CGI type model of creating everything, servicing an HTTP request and tearing everything down is a powerful one (and used in Python, Ruby and elsewhere). Once you go stateful (eg Java servlets) you have to worry about resource leakage;

2. PHP has a stateless core of API functions. IMHO this is basically ideal for Web programming given (1). It makes startup/teardown cheap and reduces resource usage (making it cheaper to provide for hosting);

3. Imperative programming is IMHO a natural fit for Web programming. One thing that's wrong with PHP is all the bloated OO mega-frameworks people create on top of it to try and make it Java, Rails, whatever; and

4. Inline code in HTML is a powerful technique. The learning curve for PHP is quite gentle.

So if you want to make a better PHP (something I'd encourage anyone to do rather than simply jumping on the PHP hating bandwagon) you should tick all the above boxes. Of course if you do this, you will probably want to fix some of the following:

- argument order consistency

- API function naming consistency

- default to HTML escaping on output

- effectively default to SQL parameter binding

- no register globals

- and so on

Side note: all of the above is well known. Pointing it out in yet another PHP hating blog post is both pointless and boring.

Jeff also asserts that PHP's popularity is sheep mentality. What nonsense. (1)-(4) above explain it far more than that, particularly the cheap hosting and inline coding.

I like to point out that 4 of the top 20 sites are built using PHP (Facebook, Yahoo, Flickr, Wikipedia) so--like it or not--it must be doing something right.

Homer (Simpson) once said "sometimes the only way you can feel good about yourself is by making other people look bad and I'm sick of making people feel good about themselves". I see a lot of that with (us) geeks but it's just so unproductive and pointless. You don't need to hate on "not X" to justify your choice of "X" (X = Python, Ruby, Lisp, Clojure, Scala, GPU type, phone type, tablet type, camera type, you get the idea).

EDIT: as far as Facebook goes, they didn't "give up" and use HipHop, they decided to have their cake and eat it too. They get the productivity benefits of programming Web pages in a "fit for purpose" language while getting most of the performance benefits of native code and they only had to give up some small subset of PHP to do it.

If you argue the subset thing is a problem try working in any C++ shop where using only a small subset of the language is de rigeur.

??? Is that a joke? Don't do that! That's just as bad as magic quotes.

> no register globals

It hasn't existed for a quite a while now in PHP.

Other than that I quite agree with what you wrote.

Most of the criticism of PHP is simply a desire to be special. If lots of people are using something, you want to make sure not to, so that you feel special. Now that you've decided not to use it, you need to justify it to yourself. And people find all sorts of real criticisms in the process - yet none of them matter!

    > > default to HTML escaping on output
    > ??? Is that a joke? Don't do that! That's just as bad as magic quotes.

I understand the debates Django had about changing what the unspecified output function did, but nowadays if you're building a new template language of any kind it's an absolute no-brainer: Make it easier to encode than to bypass encoding. The alternative is just awful.

What if I assign that string in a variable, and then output it later?

I'm not convinced this can be done well. Maybe if all you do is make some templates and fill them in you could do it. But I do a lot more than that, I output dynamically built html all the time.

Just give people a very easy and shortly named function for escaping.

Ask any Haskell weeny for details.

Also in your example, you'd probably be better of, if your language knew about the HTML structure, e.g. something like P($var), instead of putting the tags in as strings.

I like this, although when you concatenate strings, does it actually concatenate them (and loose the type info)? Does it escape them, and then concatenate? Or does concatenation actually make a closure, which is only executed upon output? (And does doing that make things memory heavy.)

Haskell is on my next language to learn list.

> something like P($var)

Ugh. I hate that. I've spent years learning HTML, I want to write HTML, not some other language that looks like it.

Also about the HTML: You can of course use different syntax for what I proposed, one that's closer to actual HTML. But I think as long as the syntax tree is preserved, it's still close enough to HTML for me, and all your accumulated knowledge about HTML is still applicable. (Not to be derisive, but if your years of learning are no longer of any use upon such a cosmetic change, you should probably examine your level of comprehension.)

$foo = <p>$textvar</p>; $foo->append(<span class='will-end-up-before-close-of-p'>Hello!</span>); // etc.

Mozilla proposed to add XML literals to JavaScript at one point, which didn't take off for security reasons, but server-side it's a different ballgame... maybe it could be worked out? Hmm.

Have you looked at how Racket (Scheme, Lisp) deals with encoding HTML in S-expressions? I find that rather nice, and even prefer it to plain HTML or XML. Racket is a fine language for manipulating S-expressions, too.

http://roboprogs.com/devel/2009.07.html#2009_07_30 (point number 4 in the numbered list)

Of course, I was thinking of a runtime attribute, rather than static typing, but the idea is similar.

And if you can't extend your type system to make this work, do it in your head, mutating the names of variables to help you keep it straight. For example, esStr and unStr are not of the same type, and moving data from one to the other without conversion is always an error.

http://msdn.microsoft.com/en-us/library/aa260976(v=vs.60).as...

I'd say don't do that, refactor into templates instead. With your preferred approach to generating markup, you're largely on your own in protecting against XSS. Hopefully all the developers using your code are awesome at spotting and pro-actively dealing with XSS issues.

Still, with a HTML escape everything default, either turn it off, or use a raw "I know what I'm doing" method instead.

You'd do something like @html.SalesWidget("90% off today") with the SalesWidget being responsible for escaping the string.

Also I don't really get your argument, why not give people a really short and easy way of not escaping a string instead? The opposite of what you're suggesting is just as easy and far safer. You're less liable to accidentally muck up.

PHP IS a templating language. Writing another one on top of it is just adding complexity for no gain.

Such a mechanism would have to include encoding functions (and assertion override functions), of course.

It seems this would help alleviate many types of fill-in-the-blank injection problems as well.

Not to mention the (also type safe) dead easy to use persistence framework.

I'm still in the process of evaluating different solutions for my next web project but so far I'm pretty sure this is gonna be my go-to framework in the future.

[1] http://www.yesodweb.com

> ??? Is that a joke? Don't do that! That's just as bad as magic quotes.

No, it's not. Magic quotes are a pain to reverse. HTML escaping can be built into the echo/print/<?= .. ?> commands, so that it is:

    - A setting that can be totally turned off at run-time, if you want;
    - Easily overridden on a case-by-case basis with a 'rawecho' function that 
      does *not* escape anything.

Plus too many cases of extra backslashes from back in the magic quotes days.

HTML escaping is not the one and only escaping strategy that magically makes everything safe. So any automated system would need to incorporate overrides on a per variable basis.

http://blog.astrumfutura.com/2012/06/automatic-output-escapi...

I'd like to mention something similar that I found in human behavior with respect to manufacturing jobs that we used to do for customers at a company that I was at. What we found was that people had 1 or 3 major complaints about something that were pretty valid. But what they did then was feel that they needed to build a strong case so they ended up coming up with as many nits as they could to build their case as if that somehow made the true concerns stronger. Just my experience but I have found that if you have a true concern about something to simply focus on trying to get that fixed. If you throw everything in the other party sometimes feels that they will never be able to please you and then they don't even try to fix anything. YEMV.

I disagree with this, especially in a RESTful world. It is very convenient, and obvious, way to look at a web request as a referentially transparent function for the most part. And the non referentially transparent requests really do change the world. We are moving our backend to a bunch fairly clear workflow of, that has layers that look like:

Get DB stuff -> referentially transparent -> Write DB stuff

And these can be arbitrarily nested. It works pretty well, it's easy to reason about, and it's pretty easy to write.

I can pretty much create and "deploy" a PHP web app within minutes of getting a run-of-the-mill hosting service.

Similarly, LPG is a great car fuel here where I live, because of a good price and abundance of gas station, but it's not the case in the US.

Did we read the same article? Jeff admits that PHP has a lot going for it and we should stop complaining about it.

The biggest thing PHP has going for it is that it is supported everywhere.

The thing that really fries my brain is templating systems built over frameworks -- PHP is already a templating system, and building another one in PHP is just silliness of the highest order. I mean, sure, separate out the gnarlies and include or require them as necessary (but, please, don't nest includes so deeply that you can't find anything anymore), but don't throw away what the environment provides just so that you can reinvent that particular wheel.

5. The set of functions for a gazillion useful everyday things that don't come standard in other languages. Where else would you find functions like htmlentities(), strip_tags(), mysql_real_escape_string()? I like list comprehensions - Python can be very concise - but PHP isn't exactly verbose:

Compare, reading a web page:

http://rosettacode.org/wiki/HTTP#PHP

http://rosettacode.org/wiki/HTTP#Python

http://rosettacode.org/wiki/HTTP#Java

Sending an email:

http://rosettacode.org/wiki/Send_email#PHP

http://rosettacode.org/wiki/Send_email#Python

http://rosettacode.org/wiki/Send_email#Java

6. Navigating or searching the online documentation is lightning quick. You don't have to know the names of functions or variables, you'll find them. The examples are like mini tutorials.

7. The write-test turnaround is lightning fast. There's probably not a small group of languages in this group, but you will really notice this if you come from say, JEE.

You need (need!) a language that's fun to use (that's fun for you to use), day in day out, not verbose, nor loaded with layers of frameworks. PHP is simple, direct, and I haven't been bitten by problems that in other languages have taken days to work out... or have never been worked out.

Honestly, I have never been bothered by the humungous list of "issues" in the link at the top of Jeff Atwood's post.

BTW, === exists explicitly to test type equality first, that's the point.

As we use to say in my country, "never tried things sweeter than carrot". I mean that was about me: I didn't know better things existed.

All that is done better in Python:

5. You don't need many of functions you use in PHP, for instance, _real_escape_string is not needed when you can do cursor.run("SQL Query param1=? AND param2=?", [param1, param2])

6. You can get help on functions in coding shell:

>>> help(open) # help on file opening function or even >>> open? # in IPython

With that I look into online or PDF docs quite rarely.

7. That's even faster in Python: you try things out in the shell, then save the shell session (IPython) and copy the code you need into the working file.

Moreover, while in PHP I was adding var_dump's everywhere, reloading a page 10 times before reaching the source of a bug, in Python I just do $ python -m ipdb same_script.py and have the debugging shell in the place I need, and it takes a minute of two to find the source of a bug.

I don't mean to defend php overly much. However, it can't be ignored that progress is being made at making php better.

(I did like the quote suggesting AppleScript is "even worse" than PHP. I'd say it's far worse, since AppleScript makes easy things difficult.)

The developer's usual routine is the same as someone using Zend; they write honest-to-goodness PHP and reload the page. There is no compilation involved; you instead are using the JIT (or until recently, an interpreter) that monitors the filesystem for changes and silently integrates them.

Facebook devs use PHP exactly as everybody else does; they just do so with a different toolchain.

You will find any number of C/C++ programmers who think you can't write anything in Java. Many Java programmers think you can't write anything (beyond 100 lines) in Python. Many Python programmers think you can't (or simply shouldn't) write anything in PHP. And so on.

Some people are insecure.

Some people can't separate their language from themselves (and see a criticism of their language as a criticism of them as people).

Some people exemplify the Dunning-Kruger effect [1].

Some, like teenagers, are just asserting their identities.

Some simply have biases that are mental blocks.

[1]: http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

Ppl who have strong opinions when it comes to language design have strong opinions when it comes to language design. Ppl who think languages are just a means to an end think languages are just a means to an end. These are two differenty species and indicative of their particular worldview, attitude and preferences. To use that as any kind of filter is silly.

Lets not look at CS for a second...If you want to know what a Stieltjes integral is, a probabilist will tell you one thing, a functional analyst another, and a measure theorist will give you yet another more pedantic definition. There's no right or wrong definition here...every one is coming at it with the tools they are more well versed in. The probabilist is the end-user, so to speak. He can't do his day to day work without internalizing it, because his bread and butter, the PDFs and CDFs of all the distributions he deals with, comes from Stieltjes. The functional analyst is going to use Stieltjes when he deals with Banach spaces, but otherwise he has other preoccupations. The measure theorist studies Stieltjes in depth because it goes to the very foundantion of measure theory...but he isn't really an end-user.

Now back to CS...a C++ programmer will think of Java as an interesting toy because you don't get union types and pointers & so forth. The Java guy will think of Python as an interesting toy, and the Python guy thinks PHP is an interesting toy. None of this means any of these people are insecure or being a teenager. If the only goal in life is "languages as means to an end" where end = $$$ in the short term, then yeah, lets just cut to the chase and do PHP. But there are other goals, yeah ?

When you have crap like this in your language:

> E.g., $i = 0; $a[$i] = $i++; makes a different array than $i = 0; $a[$i + 0] = $i++;

you have no hope of making a truly large program work. There are just too many sources of itsy bitsy bugs; you'll never find them all.

(I'm not a PHP user; I have no idea why those are different arrays. Don't bother explaining; I don't want to know.)

You get $a[1] = 0 the first way, and $a[0] = 0 the second way. PHP seems to evaluate the array index before the right hand side if there is something more than a $variable to evaluate; otherwise PHP evaluates the array index after the right hand side, after $i has been incremented.

I haven't used hiphop, but I'm curious if it preserves that disparity between arrays when translating to C++, or if it breaks PHP compatibility by making those two arrays equivalent.

Maybe you should be the one to stop being so arrogant as to tell other people what they should feel.

Meanwhile, PHP gets a number of things very right. For instance:

* State: there is none across requests. Oh sure, there's APC, and the filesystem, and databases, etc., but those are all accessed via libraries. There is no PHP-level state that survives a request, which provides natural fault isolation: a request which goes wrong doesn't take the server down with it, or live on to corrupt other requests.

* Concurrency: PHP's concurrency model is the web request. If you want to run some code in parallel, curl to localhost. If you wrap an appropriate library around this, it looks just like Erlang's actors. This is shared-nothing concurrency, which turns out to be a compelling local maximum.

* Interactivity: The development workflow PHP provides is very productive. You save and load the page. You don't save, optionally recompile, restart the server, wait for it to initialize, forget what's different from the last three times you tried this because this has all taken three minutes and you forgot to write it down, etc.

These three things turn out to be among the most important parts of a server-side language, and PHP gets them very, very right. The rightness was accidental, not by design, but this doesn't make it any less right.

Also, the language itself can be improved. In the HipHop toolchain, -v Eval.EnableHipHopSyntax=true turns on a bunch of (backwards-compatible) features we've added to our PHP dialect, the most notable of which are XHP (syntax for using XML literals as PHP expressions) and generators (inspired by Python's, using similar 'yield' syntax). I put up some sample code for a talk just the other day, if you're curious: https://github.com/kmafb/hiphop-samples

So the language does two of these three things by not doing them at all ? State: oh there's no state across requests. Concurrency: No shared resources, no threads, but we'll call it shared-nothing concurrency and then say it looks like Erlang!! Amazing. An Erlang actor holds mutable state and sends immutable messages. A web request in PHP does neither.

> If you want to run some code in parallel, Why do you even bring up parallelism in a post about concurrency ? ( http://news.ycombinator.com/item?id=3837147 )

> PHP gets them very, very right. The rightness was accidental.

Completely agree. Here you have a language that decides to tackle hard problems in CS by not tackling them. Then it becomes uber-pervasive because you can do "hello world" over the web by just doing <?print("hello world");?> Once the traction is a given, we argue about why not tackling hard problems is actually "very, very right".

Getting "hard problems" right by realizing they're intractable and refusing to solve them is a perfectly valid system design choice, even though it drives people up a wall when they first encounter it. For an example that has stood the test of time, check out UNIX's handling of the "PC-losering" problem: http://dreamsongs.com/WIB.html. When modern systems people read about this controversy, it seems kind of insane; of course system calls can be interrupted, and of course you don't want the OS to be magically trying to make them look transactional by backing up and restarting your system call when the world is really in an unknown and unknowable state. Ctl-C on a read() shouldn't restart the read(), unless the application thinks it should, and only the app really knows. EINTR was the non-solution that acknowledged the intractability of solution.

Historically, UNIX is a "worse-is-better" system not unlike PHP. I claim anyone designing a new system from scratch to replace it should learn from it, though, both mistakes and successes. PHP is not free of successes.

About the only thing you're protected against is memory leaks, and that seems to be because you have to, otherwise PHP would fall over in a big heap: https://www.google.com/search?q=php+memory+leak

I haven't had any problems with memory leaks running things like Django or Bottle.

According to him there's no explicit build step the devs have to perform and they're just writing PHP and using open source packages--meaning they are in fact making use of the "write once run anywhere" ideal at least in some places since the open source packages were made to run on Zend and now they don't. The "write once run anywhere" ideal is kind of a myth anyway since there's always configurations to do, and language-wise was even more of a myth when PHP 5.3 was new. (Some hosts still don't support it, and I'm sure a lot of us remember hosting services who dragged their feet just getting off PHP 4.)

It seems like you think the Zend backend is the One True PHP runtime and anything else isn't PHP. This is like saying PyPy isn't Python. It's just a bad argument.

Now, as far as I understand it the Zend backend takes the PHP code, creates opcodes and executes it in a VM, whereas HipHop takes the code, compiles it down to C++, compiles it again with G++ then runs the resulting C++ binary instead. To me at that stage HipHop is no longer a backend, but an entire build system transforming the language away from PHP.

Like I said, I'm not as intimately familiar with the system, but I thought it was along the lines of they have a dynamic system for local development, and when they serve it up it's run through the HipHop compile process.

Hey guys, Jeff said his piece about PHP, everyone else shut up about it now.

I sense this is probably done quite a lot in journalism, so you can write 'interesting' articles without coming off like a completely biased douche.

I don't even get the part where he says that we need to come up with better solutions. So, if we want better solutions when are they going to arrive. It's not like that the solutions are getting baked in some oven or something.

We have new solutions that we can use. We may even call them better, but I don't think that I will quit a language just for the fun of using something new.

PHP might be st, it might even break at times, but there are some wonderful frameworks which have come up lately. Laravel is one of them and a number of developers are contributing to the code. One cannot just ignore the fact that so many people have gone mad and not even a single one of them actually felt the need to quit PHP forever and build a new language that is better than it.

- why the lucky stiff

- Packaging in python seems to have been a nightmare up until quite recently. It appears things are a little more sane now that pip is emerging as the new standard but there's still documentation all over the web referencing easy_install. Of course, then there's distutils2 to muddy the waters...

- The Python 2 to Python 3 transition was and continues to be an almighty upheaval. At the moment huge swathes of the python ecosystem have yet to introduce python3 support (e.g. Flask).

- Virtualenv is a fairly ugly hack in itself but even worse than that, trying to move a virtualenv directory somewhere else on the file system turns out to be impossible unless you use another third party tool.

- The python language has no switch statement. I refused to believe it when I first discovered this but it is actually true.

So, two weeks or so in and those are my main gripes thus far. Apart from that, I'm enjoying python. My favourite "python thing" discovered so far is all the cool list iteration syntax.

----

Simplicity: The design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.

Correctness: The design must be correct in all observable aspects. It is slightly better to be simple than correct.

Consistency: The design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either complexity or inconsistency in the implementation.

Completeness: The design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

----

I don't know about you, but IMHO, this is PHP in a nutshell.

Edit: One other little thing I forgot to mention. PHP is like Java in that it is really hard for a metaprogramming or type system nerd to do something tricky and clever that another novice programmer brought in to replace him would not have a chance of unravelling.

. . .

I don't know about you, but IMHO, this is PHP in a nutshell.

If you had read some of the criticisms of PHP that had been posted to HN (like http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de..., which was even linked to in the current article), you'd realize that PHP is nowhere near consistent. I'm not sure simplicity, correctness or completeness apply either. I think the only thing PHP has going for it is momentum (in having a large userbase and being installed almost everywhere).

The result is that a lot of PHP is awful, cargo-cult stuff glued together by people who have no idea what they are doing.

It's possible for talented developers to create really good programs in PHP, but I don't see how a new language is going to solve the essential problem. People who don't really know how to program and just want to accomplish some simple goal are going to use whatever language is the quickest means to their ends.

Copy/paste spaghetti is a nightmare to maintain in any language. And the people creating it are the same people who are /not/ going to read Atwoods post, don't understand very much about how programming works in general, and will continue to create cruddy programs no matter what language it is written in.

And it isn't just a bad programmer thing. PHP's bad habits encourage novice (or uncaring) programmers to pick up bad habits, especially if they are not particularly inclined to study how to use their tools well. Given a language where the obvious thing to do is right vs. one where it's wrong (see PHP < 5 database queries - no prepared statements, mysql_escape_string) vs. an environment where the obvious thing, encouraged by the introductory tutorials, is right, I think that the more correct/safer language will encourage programmers to write better code.

But reading the comments here and on Jeff's post, it is humbling to remember that people are using it, every day, to build more and better software than I ever have. I may have a visceral dislike for the language, but good programmers are able to do good work even with a double-clawed hammer.

I'm pleasantly surprised at the high rates my PHP consultancy work commands; it's obviously helped by the number of hit-it-till-it-works web devs out there.

Granted, for larger projects where you run your own ruby/python services, it could surely be easier. But for larger projects you probably want to spend more time on your deployment setup anyway.

I am a full time Rails Developer. So here we go...

If you want to produce free-as-in-whatever code that runs on virtually every server in the world with zero friction or configuration hassles, PHP is damn near your only option.

That is the crux of this whole debate summed up in one beautiful sentence. I almost cried.

Until someone builds a better solution, where better includes as easy or easier to setup on than php. Php is going to be the defacto standard.

And for the love of God please don't say well all you have to do install Blub then configure foo server and...

You've already failed to be easier to get started on than with php. And if you want php to go away you have to do just that.

Where do I install Blub? What happens when there are 30 different servers that can run it which one do I pick? Why? What are the trade offs? Version Y is on the website but everyone really uses version X because the the dependencies haven't been up dated to Y yet. And the major framework just had a huge fork/merge/catfight and now its future is uncertain ...

Fuck it I can pay Shithost $5 a month for php and I can toss a few variables in this html <insert wysiwyg editor> crapped out.

Your average person who needs something to show up on a website

and lets be very clear if you want to see php go away these are the people you need to go after

does not care about: - lambdas

- good language design

- namespacing etc,

they don't read Jeff Attwood, Hacker News or any of that.

One thing the php community as a whole has always focused on is ease of getting started. Take Wordpress. The 5 minute install? That gets up an running an allowing me to do what I care about (getting my client's content on the internet) I still use it long after converting to other languages for most development.

If you can't compete with that it does not matter how many templating languages or css precompilers or what the hell ever you got. You don't stand a chance.

TL, DR: Long Story Short. php and its children make it easy to drop in and play. Thats what you are up against. Not language design beauty/ purity or features. Ease of getting started.

Because honestly the only people who care enough to switch are people who care enough to overcome that in other languages.

But yes, we get it, you don't like it. Move the fuck on. These "This is what's wrong with PHP" articles are starting to get redundant... Everyone shouting in to a empty cave that nobody cares about.

ASP.Net MVC version 4. Yeah, actually I'd say that it is. But YMMV. All I'd say is avoid commenting on frameworks that you don't know much about.

Full disclosure: I am an average programmer compared to many here. I come to this site to improve my self and read about what brilliant and amazing things you all do. Now you have a reference.

I use PHP on a daily basis, have been for years. I am a freelance developer who has been able to carve out a living with a lot of hard work and a lot of luck. I just met the right people at the right time. Over the last 7 years since I started developing professionally, I have seen nothing but people shitting on PHP constantly. I am in no way suggesting PHP is a perfect language, but I still never get the hate. It just seems so ivory tower to me sometimes. Let's look at reality.

I'm starting a small project for a client. They are keeping track of all their scheduling and doing all their reporting in excel. They want to move this to the web with basic security so the right people can see the right information with ability to access it from anywhere. That's it. You know what works for that? PHP does. It works fine and it works on almost any server in the entire world with no issues. I don't need a .vimrc file with a million special configurations, I don't need a hot new framework where my time is spent figuring out how to do basic CRUD operations, it won't matter if PHP is statically typed or not, it won't matter if... you get the idea. I just need to start developing and getting this project done so this business can start saving time and money. That's what matters most to me.

PHP works, and it works damn well for millions of situations every day. No one is suggesting you use PHP to build a super computer. If your project requires something different than use something different. PHP is not the "Nickleback" of programming. PHP is useful. PHP is practical. PHP is easy, and that's not a bad thing. Facebook, the biggest site in the world, uses PHP. Think about that.

Finally, let's use his tool analogy. PHP is a double-clawed hammer. What if your job was to remove nails from wood all day? What a wonderful tool a double-clawed hammer would be! You wouldn't have to worry about which way the hammer is facing! That would save you real time and real effort. It's the right tool for that job. Tools are about how you use them. If someone uses a tool incorrectly it's not the fault of the tool.

PHP can use improvement. Every language can. I imagine a meeting of otherwise incredibly smart people sitting around in smoking jackets and sipping fine brandy standing around with smug smiles on their face. "PHP is horrible!" One will say. "Hmmmm... Yes... Quite..." A small laughter emerges. They all pat themselves on the back and enjoy their intellectual circle-jerk. All the while countless developers are using it every day for the right reasons making real applications that help real businesses save real time and real money. Laugh at me all you want, I get Christmas cards from my clients. They like me just fine.

I don't write rants about it but that's just because I left the language behind years ago and never looked back. But if I had to write for my job? Yeah I'd write a rant every other month probably. I would need some kind of outlet for all that pain.

It looks like in Jeffs article his rant was sparked by having to take a close look at php again and all that pain just bubbled back up.

Aside from happiness, there are things that make Ruby more powerful. For example, you can cleanly implement the reactor pattern (think: NodeJS) with EventMachine and with EM-Synchrony you can avoid the callback hell that comes with NodeJS.

If you want, you can look at Sinatra to provide the common functionality that the PHP framework provides. With Sinatra you're not all-but-forced to use an ORM like you are with Rails, as Sinatra doesn't include one. If you really want, you can go closer to the metal and look directly at Rack, which is middleware between web servers (Apache, Nginx, etc) and the actual application.

There's really no right way to do it, but the best thing is to learn and explore. Some people will recommend Python, and while it's a decent language, it's got some things I consider to be rough edges -- lack of useful language features, such as switch/case statements, and badly implemented parts of its standard library that handle network requests.

The next language on my learning list is Go. I've heard nothing but good things about it, but I'll reserve my judgment until I have some experience with it.

PHP was ok for me I spent a ton of time looking up functions in the docs but I could get stuff done. Once I had to edit/work with 3rd party code it was a nightmare.

I've developed in PHP, Ruby, C#, Java, ActionScript, and Python and Ruby's gem system is by far the easiest package management system I've used. Making your own gem is really easy.

Great ideas seem to pop up in Ruby first and then are ported to PHP, so why not use the original (see Rails, Cucumber, Bundler).

Here's a better idea. Take a very simple problem - say user fubar enters his name, you say "Welcome, fubar!", populate a backend database with his name because he's a new user. Otherwise you tell him "Welcome back, fubar!" and don't mess with your database.

This involves what ? Handling a GET, making a database insert, doing a select on name in a database, that's it.

Now go do this in atleast 5 frameworks, and time yourself. PHP obviously, but do try RoR, Django, Play2, JSP and ASP.NET

I actually did the above exercise and came away with a lot of valuable insight. In my case Play2 was a breeze because on Heroku its trivial to set up, and each GET xxx request mapped directly to a xxx scala method in the Controller, so no magic. The others were a little more painful, but not a whole lot. I enjoyed the exercise.

Most frameworks almost feel like they're tuned to solve these basic problems and give a fantastic first impression that doesn't sustain.

Developing a complete project in each is a better way to move forward IMHO.

Also, s/peaked/piqued ;-)

Ruby or Python would probably be the best choices if you don't have anything else in mind.

Besides Viaweb?

Now count > 1m visits per day websites done in PHP.

The number of hits a website receives isn't the product of the language it's written in, but primarily a function of its marketing (and other factors that appeal to its users).

There are also more websites with their foundations in PHP, so it's reasonable to expect a higher number of successes. You can't therefore logically conclude that the language influences success. It's like comparing the number of millionaires in the US with the number of millionaires in Canada; the US has a bigger population compared to Canada, and all things being more or less equal, it's reasonable to expect that the US would have more millionaires simply because of its shear size.

Yes, me and all Analytics and SEO guys. You either sell ads or stuff. In both cases you want as many eyeballs and wallets as possible.

>The number of hits a website receives isn't the product of the language it's written in, but primarily a function of its marketing (and other factors that appeal to its users). There are also more websites with their foundations in PHP, so it's reasonable to expect a higher number of successes.

Yes, but your logic is circular. The question is WHY are there "more websites with foundations in PHP", and not just trivial amateur personal stuff but highly successful ones too.

You seem to assume PHPs expanse as just a fact of life, totally arbitrary, and thats why you say we must not draw conclusions based on it.

>You can't therefore logically conclude that the language influences success.

Sure I can. Here are some ways:

- Php is easy for newstarters, so got more adoption. - Php is trivial to deploy, so got more adoption. - Php was there, targetting the web specifically (with libs and features), in 199x, while Haskell, CL, what have you were not yet. - Php, because of the above, had amassed a huge ecosystem of projects and engines (Nuke, Wordpress, Drupal, EE, etc). - Php, because of that, has alo got huge adoption. - Because of th adoption it built a huge ecosystem of programmers, projects, tools, books, etc.

And, putting it all together, what makes PHP more likely to power most high ranking sites, is that you can easily find components and engines to base your site on, AND you can easily find tons of programmers to employ, AND you can easily find support for it, etc. All those make it a no brainer for a lot of uses.

And all of those are interdependent, based on some initial language attributes, not arbitrary like the US vs Canada population argument (which is not that arbitrary and size based itself, but thats another story)

I wasn't disagreeing, and in fact I didn't even express an opinion regarding this. Success means a lot of different things to people; I was stating your definition of success for clarity.

The user doesn't care whether I write a website's back end in PHP, Ruby, Python, Haskell, C++, Ada, Clojure, or even Erlang. The success depends on how useful the site is and how well it's marketed. This isn't circular reasoning.

There are more websites written in PHP because PHP is an easy language for beginners and therefore more common compared to Ruby or Python, for example.

It's an absolutely untenable position to assert that the programming language itself affects how much traffic an site receives, which is what you originally defined as "success".

Oh, alright. Thought you meant it was not a good metric.

>The user doesn't care whether I write a website's back end in PHP, Ruby, Python, Haskell, C++, Ada, Clojure, or even Erlang. The success depends on how useful the site is and how well it's marketed. This isn't circular reasoning. There are more websites written in PHP because PHP is an easy language for beginners and therefore more common compared to Ruby or Python, for example.

Yes, that second argument is not circular reasoning because it searches for the causes.

But the argument in your previous post, I read it as: "PHP is used by more of the popular sites because PHP is used by more sites in general" Which is kinda circular, mostly repeating "PHP is popular".

>It's an absolutely untenable position to assert that the programming language itself affects how much traffic an site receives, which is what you originally defined as "success".

I did the opposite: the success of the site affects the programming language.

That is, I am a pragmatist: I see every successful site built with a programming language as one more verification that said language is good for building sites with (whatever the reasons).

If we have 200,000 high volume sites in PHP and 0 in X, as a pragmatist, I will avoid using X in my next high volume site project.

Working from that, one can also see why it is so. For example:

1) it's because X is obscure, so I wouldn't be able to get a team easily. Perhaps even no one in my city, at least without adding the overhead of teaching them X first.

2) it's because X is more expensive to host. I'll need to get a VPS whereas I can just put PHP on a $10/year server.

3) it's because PHP has more libs and stuff. This DB/service API/etc I want to use does not have X drivers (or has a semi-abandoned project).

4) it's because PHP has Drupal/Wordpress and I can have a high traffic portal/news style site in minutes, whereas X has only ho-hum solutions for that, or I would have to build one from scratch.

and so on.

Surprisingly, many so called "scientists" and "engineers" choose to argue from first principles. "X is a bona fide academic language, and has all those meta programming features, higher-order types and such, so you are crazy to use PHP over X for your project".

So, instead of reading the situation pragmatically, and finding the real pain points PHP eases and why it's used, they resort to idealistic rants about how masses are ignorant, "beating the averages", etc etc.

Well, this Zuckerberg guy, with his average PHP, beat Viaweb's Lisp by about 100x better valuation. If, according to "beating the averages", ViaWeb's success was a pro-Lisp point, why isn't that a pro-PHP point? Or does it only work when Lisp wins (as in, "ViaWeb won because of Lisp but Facebook won despite of PHP"). Talk about having it both ways!

You misread what I wrote in that case. I said "There are also more websites with their foundations in PHP, so it's reasonable to expect a higher number of successes." This isn't circular reasoning, and let me show you why:

Lets pretend I'm superhuman and create 10,100 unique, high quality websites in one day. Let's assume also that my skill and experience remains constant throughout building these 10,100 websites; I'll get no better at marketing, design, etc and all my decisions are of equal quality. The only difference is the programming language I use to develop some of the sites.

For the sake of this example, let's assume that 1% of websites created, on average, end up with one million page views per month after six months.

In this fictitious example, let's say that for grins I build 100 sites in Lisp and 10,000 sites in Perl. 1% of my Lisp sites will be successful (a grand total of one successful site) and 1% of my Perl sites will be successful (100). From this data you're erroneously concluding that Perl is more likely to result in a successful site. This is wrong, because the number of sites created in each language varies wildly, but the odds of hitting "traffic gold" are still 1% with everything else being equal. The language, therefore, doesn't impact success rate.

Seeing something built in PHP doesn't make it a good choice, just a common one, just like smoking in the 1970s was a common choice, just not a good one.

Facebook, while it's mostly written in PHP, is actually transcompiled to C++ (HipHop compiler) because PHP was insufficient. They're not actually running any PHP code in production. Also I keep hearing that their codebase is an unholy mess and that the only reason it hasn't been re-written in another language is that the codebase is just now too big to rewrite. Zuckerberg wrote Facebook in PHP because it was the language he knew, not because it was the best tool for the job. Marketing and user experience made the site successful, not the language.

Don't just look at PHP and say "huh, it's common!" and conclude it's good. It just doesn't make sense and it's a logical error to do so.

Does Hacker News count?

Note also that the mention of one site is too literal and meaningless interpretation of my question, which is more rhetorical, and should be read like: "There are TONS of high volume PHP sites and very very very few high volume Lisp sites".

That said: the "no true Scotsman" logical fallacy is only a fallacy half of the time, like most of those so-called logical fallacies.

They assume a perfectly logical world, where you have infinite information at your disposal and infinite time to check it. E.g I'd rather listen to my doctor on my medical condition over a random guy on the subway, even if that's "appeal to authority".

Similar cracks in the "no true Scotsman" fallacy. There ARE cases where a category/taxonomy is used badly, and no true member of said taxonomy would so something. That is, membership in a taxonomy is not always 100% solid, and you can have true and less true (fuzzy) membership.

E.g

- No KKK member would attend a NWA concert. - But I just saw a KKK member rocking it at a NWA concert. - Well, no _TRUE KKK member_ would ever attend one.

It's obvious that the first guy is correct: no TRUE KKK would ever attend a NWA concert.

Now, a random KKK member could possibly attend one (say, out of curiosity). The "no TRUE" argument in this case, says not so much the impossibility of an event happening, but that it is against the very concept of the taxonomy under discussion for it to happen.

Hackers shouldn't touch the "logical fallacy" stuff with a ten foot pole. They presuppose that conversations and argumentation can just go "by numbers", without examining each individual case.

I use PHP as my main language for web development, but also am a frequent C user. I have done projects in C# and Python.

While I like C# and Python - actually for scripting I tend to go for Python rather than PHP, prefer the CLI modules of Python- , I found that in context of web dev PHP still get the job done faster and in a maintainable manner. As for C, I use it for writing PHP extension -or generally fucking around with PHP source code- and writing non web stuff, so not as relevant.

The difference between people like me and people like you, is I don't go around constantly mocking other language. It is pointless, I'd rather spend my time and energy delivering products, or actually doing something productive.

Based on experience I asserted that many programmers feel that PHP is an inferior language because they've experienced "cleaner" languages such as Ruby. It's not wholly unreasonable that chez17 had only programmed using PHP, as PHP is commonly a programmer's first language. I therefore wanted to find out if chez17 had used other languages and to see what their thoughts are on PHP vs those other languages.

I also don't go around "constantly mocking" other languages. Why did you make that assumption?

Good engineering design vs bad engineering design is what prevents bridges from collapsing or Mars landers from crashing.

But I hear you: sure it's quite possible to do arithmetic using Roman numerals, and if that's what you're used to, you probably don't want to hear that you've been doing it suboptimally. And all these people clamoring for a change to decimal are just an unbearable nuisance.

Brilliant.

Except that, if you're removing nails, there are much better tools than the claw on a hammer. [1][2] I've done demolition, and I've had to pull a lot of nails, and the claw on a hammer is about the last tool I'd use for the job. I basically only use the claw to straighten or remove a partly-hammered nail that's gone wrong.

So yes, the analogy is brilliant.

[1] For really big nails, more leverage is good, and the hole in the flat part can be used to pull longer nails out than you can pull with a hammer claw: http://refer.ly/abwW

[2] To get a nail started, something sharper with points, and that (here's the important bit) can be HAMMERED under the nail head: http://refer.ly/abw2

I think the original analogy was indeed brilliant, given the context.

Also, you never find yourself in a situation where you're just pulling out nails. A large number are too difficult to pull out, or will damage the structure you're pulling them from, so you hammer them down.

The analogy is almost perfect! Except that PHP doesn't pull out nails very well.

More like a game between different sports teams. Are you going to go to the fans of the opposing team for an honest opinion about yours? Are you shocked they have nasty things to say about your team? Or that you have nasty thoughts about theirs?

What gets to me is this air of objectivity ... that part is most certainly ivory tower and is arrogant to boot.

What I want to read is a critical article on PHP by somebody who uses PHP and loves it. That would be useful.

A hit piece by somebody on a Microsoft stack is just boring!

That said, there are popular languages worse than PHP for most web development tasks, Java for example.

    <?php
    $hackernews=file_get_contents("http://news.ycombinator.com);
    $hackernews =str_replace('Hacker','Interwebz',$hackernews);
    echo $hackernews; 
    ?>

Not to say you should write a webapp in it, but I think you're wrong; there's intrinsic overhead in using a Real Language. It has nothing to do with "knowing how to do it," doing things properly takes time, a half-assed but mostly functional solution can be whipped up in minutes.

So:

* It's horrible code

* It has bugs

* It's not secure

...

* It's downright elegant

See the discord there? It's not elegant at all. It's easy, but easy != elegant. It's just easy.

  require 'net/http'
  puts Net::HTTP.get(URI.parse('http://news.ycombinator.com')).gsub('Hacker', 'Interwebz')

Or, even simpler,

  require 'open-uri'
  puts open('http://news.ycombinator.com').read.gsub('Hacker', 'Interwebz')

Simple and short are two different things. I value PHP over Ruby here because it's much clearer to the layman what's going on. To explain the PHP, all I have to explain is functions, variables, and the echo statement.

To explain the Ruby, I have to explain functions, variables, Objects (everything is an object), Libraries, I/O, and method invocations.

Also, in classic code golf form, your code eliminates a couple things that will make it do exactly the same thing as the PHP - you're missing your #! line, and you're not actually writing a CGI script, which is a second library you need to include and explain to your hapless newbie. And honestly, it's not just a newbie thing. I've written Ruby similar to that (with good error handling, etc.) Ruby only makes sense if you're going to do the job properly and put in error handling, etc.

[1] https://github.com/jayferd/balls/

Definitely see what you're saying but the flip side is that in my experience once you figure out the basic CRUD operations in a good framework, the amount of time it takes to implement them decreases hugely compared to repeatedly writing boilerplate in PHP.

Being able to get something functional up and running extremely rapidly was exactly what caused me to move most of my projects away from PHP although it would be fair to say I didn't give the corresponding PHP frameworks much of a chance as I had other reasons for wanting to consolidate codebases into either python or ruby and I hear Zend, Symfony and various others have come on a long way.

I agree with your metaphor relating working with PHP as "pulling nails from wood all day."

Bjarne Stroustrup

The barrier to entry with any other popular language such as Python or ROR is that's it's hard to just toss a script up and see results.

But which open source language ecosystem? Is he talking about mono? ruby? python? erlang? something else?

Either he thinks it's obvious what he's talking about (hint: it isn't to me) in which case it's probably mono; or he's being deliberately coy and holding back for a big reveal later.

You can't do:

$something->doStuff()[0]

if(empty($something->doStuff()))

Overload fucking functions. Fuck.

What sucks:

The namespace separator.

The naming conventions of the core functions.

The speed.

But, overall it works and elegant solutions can be written.

Also, being competent in a market full of incompetents makes you valuable and getting a well paying job is easy. What's not to like about that?

I like the namespace separator, but I'll accept I’m in the minority on that one.

I also understand the technical need for a new character (which doesn't exist for static languages or some other dynamic languages) and once you need a new character then the backslash is a reasonable choice.