Coding Horror: The PHP Singularity - <AUTHOR> http://www.codinghorror.com/blog/2012/06/the-php-singularity.html <comment><USER3> The irony of this post is boundless.

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

<comment><USER4> "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."

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

<comment><USER3> No, PHP is a language with some framework-like aspects. Your nitpicking is quite poor.

<comment><USER4> I'm just saying that Microsoft offers tools(languages or frameworks) for web developmet that are open source. And yes you have Mono project also.

</comment></comment></comment></comment><comment><USER5> As time goes by, I think the time to get started in a new system (which for PHP is almost 0 time) is one of the most important things.

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)

<comment><USER6> Another part of what makes something "best" is... size/scope of developer community. PHP quickly gained a foothold, and, for better or worse, continues to be popular in part because it's popular. I don't mean that as an insult at all, but it's a continued factor. If tomorrow everyone stopped releasing open source code for PHP, it would gradually die off in several years while people transitioned to alternatives, and we'd end up with some other 'largest minorty' tech/stack getting a lot of attention.

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.

</comment></comment><comment><USER7> Sorry Jeff. The only thing broken with PHP is you (and other people like you).

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.

<comment><USER8> "I prefer Python". Why did you say that? To me it feels like you said it do people would take you seriously as a "real" developer. Because surely a "real" developer wouldn't actually enjoy using PHP or use it unless they were forced, right?

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.

<comment><USER9> _"I walk to work because there are no bike paths, but I prefer biking."_

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?

</comment></comment></comment><comment><USER10> From the post:

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

<comment><USER11> _Basically, Jeff just agreed that PHP is simply better than the rest._

Easier != better. Nice try.

<comment><USER9> Debatable. What's your end goal? If your primary goal is making money (through the web) and you are non-technical, easier does in fact equal better. The GP's brother isn't going to stop what he's doing and learn Ruby so he can rewrite his whole website in gloriously succinct and elegant code.

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

<comment><USER11> Life is full of tempting shortcuts. Take them at your peril.

<comment><USER9> Well that's basically saying nothing at all.

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.

<comment><USER12> Simple versus easy [1]. Getting started with minimal friction is a great virtue for the beginning of a project's life, particularly when it allows amateurs to produce something of value. Software development professionals with stronger requirements (reliability, maintainability, ease of code reading) are not always going to reach for the easiest tool. There's a reason most of the software on your machine isn't written in Visual Basic.

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>

</comment></comment></comment></comment></comment></comment><comment><USER13> Hey Jeff, let's throw down the gauntlet. You're obviously an experienced developer. I've been in the game for over 11years so should have enough experience to tackle you on this bigoted rant.

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.

<comment><USER14> Congratulations! You just Blub Paradox'd yourself. At this point in your knowledge cycle, you are unable to understand something more complex than what you already know.

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

<comment><USER13> I'm sorry, but at what point did I say I was refusing to "expand and learn something new"?

<comment><USER15> The subtext of your challenge is that no language could possibly exist that is substantially better than PHP at expressing a solution to any problem, which would mean there's little to be gained by learning anything else. That's not a claim I'd ever make about my favorite languages, even though nobody makes huge lists of indefensible design gaffes in those.

</comment></comment></comment></comment><comment><USER16> Cue legions of PHP drones blubbing about how it does the job just fine, it's available everywhere and how it's used by Facebook and half the internet. We get it. We used to be PHP developers too. We took the time to learn other languages and now work with them. We enjoy our jobs significantly more than we used to. You might too.

<comment><USER17> I'm a full time PHP dev. My work is in PHP, my personal projects is in PHP, I even have a PHP framework (like everyone!) that I maintain.

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.

<comment><USER16> Good for you! In my case I moved to ruby but I would imagine the transition is similar to other languages at a similar level of abstraction. I went through a long phase where I was trying to bring patterns from ruby into 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.

</comment></comment></comment><comment><USER6> "make the alternatives so outstanding that the choice of the better hammer becomes obvious."

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.

</comment><comment><USER18> I'm a php user. I got involved in programming because I wanted to control my websites and build new ones.my first exposure to php was through modifying open source platforms (eg Wordpress and phpbb).

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.

<comment><USER6> agreed. i don't think many other non-php supporters _get_ how ubiquitous PHP (and even has been, for a decade or so) in terms of coming pre-installed everywhere. And apps - yes, have replacement apps that play nicely in shared hosting environments without requiring 30% of the machine's RAM per user/app, and you'll see a replacement.

</comment></comment><comment><USER19> Oh great. Another PHP article, where we get to watch all of the defenders of Rasmussen's misbegotten spawn come out from under their rocks...

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

To address the article's point somewhat - there are already easy to deploy frameworks and languages for the web, and everybody who cares about development is already using them.

<comment><USER20> Who's Rasmussen?

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

<comment><USER19> > Who's Rasmussen?

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.

</comment></comment></comment><comment><USER21> This rant boils down to a tweet "If you don't like PHP then use another language or build a better one". What a revolutionary concept! That has worked wonders for languages since. Except not one has come out that is as simple as PHP thus PHP will continue to exist. Everyone that invents a language now focuses on abstract concepts that do not help the everyday developer do anything useful. Is it so shocking it's still around? If these rants are supposed to be rally cries they are really just awful attempts. Who wants to follow a whiner?

<comment><USER22> > If you don't like PHP then use another language or build a better one ... > Everyone that invents a language ...

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"

<comment><USER21> If an existing language already has potential to replace PHP then I don't see why it wouldn't have already. What would/could you tweak that would get you there without fundamentally changing the language capabilities and syntax?

<comment><USER23> Setup costs - PHP has a low barrier to entry in the sense that Apache's mod_php5 is a simple "a2enmod php5" command away. Even PHP-FPM with Nginx is only a few well-documented configuration options away from working.

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.

</comment></comment></comment></comment><comment><USER24> I just don't understand why this is a problem. If the goal of a web language is to _build websites_ then JUST BUILD WEBSITES. Who honestly still gives a shit what you build it in?

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.

</comment><comment><USER25> I've been coding for nearly 30 years and have seen this rant for every major language I've coded in. The reality is there is no perfect tool even in construction as Jeff tries to draw parallels to you will find that many different tools are required for many different situations. Often a hammer can be used to make a hole in a wall and other times you use a saw to cut a nail head off and just pound it into the wall because your hammer has a broken claw!

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! :-)

<comment><USER26> Why is python or ruby too hard for your dad to learn? If anything I would think something like ruby would be even easier than php since things are a bit more consistent.

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

<comment><USER27> Try getting Django to run on various hosting sites. Dreamhost - been with them for ten years, gave up trying to get Django to work after a month of poring thru the docs, trying to get tab A into slot 3x. Mind you, I really like Python, but it's not worth the effort for a couple more years.

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

<comment><USER28> For pretty much every language these days, there is a hosted service that will handle deployment for you, and you can just push code to them and they'll take care of the rest. Better yet, they're _perfect_ for beginners, who usually don't know much about database tuning, firewalls, etc.

<comment><USER27> Which kind of leaves me not understanding _how_ it's deployed, etc., which I kind of feel like I need to know.

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

<comment><USER28> Yeah, but the average person doesn't really understand how their PHP is set up either. It was done for them, or they copy and pasted some instructions.

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.

</comment></comment></comment></comment></comment></comment><comment><USER29> Everyone's jumping on the PHP bashing. I don't think that's what this blog post was really about. Did you read to the end?

      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.

Kind of a cliffhanger ending... What are you building, Jeff?

<comment><USER30> Whatever it is, it better be fucking perfect after all that. This post is PHP bashing with a cherry on top. But mostly PHP bashing.

</comment></comment><comment><USER31> I seriously groaned when I saw this post (title).

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

<comment><USER32> > default to HTML escaping on output

??? 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 - <USER2> none of them matter!

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

Microsoft's Razor and Python's Django templates have both shown that HTML- escaping-by-default can be cleanly done in a way that is not magical and that is highly reliable. I'm not honestly sure what you're protesting here.

<comment><USER32> If I make a string: '<P>' . $var . '</P>' - does it know to encode the variable, and not the entire string?

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.

<comment><USER34> Just needs a bit of type system magic. Don't use the same type for escaped and unespaced strings. (And don't use the same type for user generated input before and after it's scrubbed / escaped of any nastiness.)

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.

<comment><USER35> > Don't use the same type for escaped and unespaced strings.

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.

<comment><USER36> This reminds me of Charles Simonyi's classic article on Hungarian Notation. I know that style gets criticized a lot, but that's usually when it has been used inappropriately. If you have a language with a weak type system then a sensible variable prefix convention can help a lot.

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

</comment></comment></comment></comment></comment></comment></comment><comment><USER37> _When you don't create things, you become defined by your tastes rather than ability. Your tastes only narrow and exclude people. So create._

\- why the lucky stiff

<comment><USER38> I will always upvote/retweet/point and jump at this quote when I see it. One of the most important lessons anyone can learn.

</comment></comment><comment><USER39> I'm a PHP guy (started in the PHP3 days) and a few weeks ago I decided to finally have a go at building a non-trivial site using uWSGI, Flask, sqlalchemy and mongrel2. I knew a bit of python (from having written a few trivial sysadmin related scripts) but apart from that I was starting cold. I'm now a few weeks in and while I'm not ready yet to jump ship back to my PHP comfort zone, I can say I've been surprised to find that Python (one of the "better, grown up" languages that's always cited in these PHP bashing threads) has quite a few warts of its own:

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

</comment><comment><USER40> PHP is basically the latest example of "Worse is better"(<http://en.wikipedia.org/wiki/Worse_is_better>).

\----

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.

<comment><USER41> _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._

. . .

 _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...](http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/), 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).

<comment><USER42> PHP's inconsistencies are _minor_. The problem with quoting the fractal article is at least a third of it is totally wrong and another third is misunderstandings by the author.

</comment></comment></comment><comment><USER43> I hope Jeff succeeds in promoting an alternative to the level of ubiquity of PHP. I think PHP is a generally awful language, eclipsed in sheer programming linguistic badness only by such systems as MUMPS (which, fortunately, I have never had the opportunity to work with). Fractal of bad? Check.

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.

</comment><comment><USER44> I agree that it's rather surprising that in this day and age, nothing comes close to the out-of-the-box ease and performance that PHP gives for web development. Install a couple of packages, and BANG, you're up and running. It's been a year since I've taken a look at the rest of the webdev landscape, but it seems that you either lose out to an overly-complex setup (by comparison), or suffer with a memory hog that makes bootstrapping on a 1GB VPS a nightmare.

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.

<comment><USER45> Agreed. I can set up a VPS with debian/nginx/mysql/php in about 10 minutes and have a site up and running. Python? Ruby? There just doesn't seem to be an easy way of getting them running on a web server. At least, I haven't figured it out yet if it is easy to do.

<comment><USER28> `git push heroku` style deployment is pretty easy. And for anything where having a site up and running in 10 minutes is the primary driver, Heroku is probably good enough.

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.

</comment></comment></comment><comment> wh-uws Since lately folks have been attacking the people instead of their arguments I also have to preface my comment.

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.

</comment><comment><USER46> We get it, you don't like PHP. Don't use it. Nobody forces you to use it... If someone does, it's most likely a client, and that's nobodies fault but your own for seeking clients that want PHP work done. And if that's the case, you shouldn't be scolding PHP for keeping food in your mouth and a roof over your head.

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.

<comment><USER47> He's really one to talk.... ASP.NET is so amazing, right?

<comment><USER46> All languages have their purpose, use the one you want and prefer. I'm getting sick of people bashing other languages because they don't like it. Especially people who have never really used the language...

</comment></comment></comment><comment><USER48> Ok, so here it goes. I haven't commented on this site for over a year.

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.

<comment><USER49> What other languages besides PHP have you used? I think a lot of us dislike PHP because we're putting it in the context of better designed languages.

<comment><USER48> Sorry to respond twice to your post, but I realized this was a great opportunity to learn something. Given my basic example in my post, what language would you recommend I try to accomplish this task? I like to stay away from frameworks so basically I'm asking you to not suggest Rails, however don't be afraid to suggest ruby. If you feel like typing something out, let me know why you suggest it and what advantages it has over PHP.

<comment><USER49> Ruby. It's the cleanest language with the most sensible standard library I've come across to date. Ruby doesn't necessarily mean Rails, and in fact I'm not a fan of Rails' overly prescriptive paradigm. (As an aside, any time you hear Rails is an MVC framework, discount it because it's really an MVA framework.) One of the things you'll find coming from the world of PHP is Ruby has consistent method signatures. For this and a lot of other reasons you'll almost certainly be happier with Ruby.

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.

<comment><USER48> Thank you for taking the time to write this. You have sufficiently peaked my interest. My next personal project will be done in Ruby.

<comment><USER50> >My next personal project will be done in Ruby.

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.

<comment><USER49> The only trouble with this is that trivial applications tend to only give a superficial feel for the framework and aren't representative of a "real" development experience. For example, I wrote a trivial application in Flask. Python's Flask, while it looks great on the surface and has fantastic documentation, rapidly becomes unwieldy in the face of more complex problems. The same is true for Ruby on Rails.

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.

</comment></comment></comment></comment></comment></comment></comment><comment><USER51> There are only two kinds of languages: the ones people complain about and the ones nobody uses.

Bjarne Stroustrup

</comment><comment><USER52> The problem is that the barrier to entry with coding PHP for the web is to open up notepad for 30 seconds and then upload a file. It's hardly more complicated than writing a static HTML page.

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.

</comment><comment><USER22> Mr Atwood says "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. "

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.

</comment><comment><USER53> PHP is broken in many little aspects but if you use a high quality framework, it's quite enjoyable to work with. The main gripes I have with it are in the details, like:

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?

<comment><USER54> Speed isn't an issue, at least in my experience, compared to similar languages. Raw PHP usually beats Rails handsdown, and most PHP frameworks are usually comparable. PHP performance has increased markedly over the past few years, and particularly in v5.4. And if you really need a speed bump you can use the APC cache or HipHop compiler. Its never going to be as snappy as, say, C, but in the class of languages its in these days it holds it head up high.

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

<comment><USER55> >Raw PHP usually beats Rails handsdown, and most PHP frameworks are usually comparable

Being able to keep up with the slowest competitor in existence isn't very good.

<comment><USER54> The reason I cited Rails is that its usually proposed as the better alternative in these anti-PHP threads. Most "high" performance PHP doesn't use one of the usual-suspects in the framework world and can easily beat Rails (and usually plain ruby too).

Edit: I should add "in my experience" to the end of that, I have no stats to hand.

<comment><USER55> >Most "high" performance PHP doesn't use one of the usual-suspects in the framework world and can easily beat Rails (and usually plain ruby too).

If you skip a framework on both languages, they end up as the two slowest languages. Hard to say if either is faster overall, but they are both awful. Using jruby provides a huge performance increase, and PHP really has nothing to compare with that.

<comment><USER54> To be honest I've not used jruby. It would be interesting to see how it compares to implementations PHP on the JVM such as IBM's WebSphere sMash, and Caucho's Quercus. Do you have any views on the performance of jruby vs hiphop'd PHP?

<comment><USER55> Hiphop doesn't really compete in the same space, as it only converts a subset of PHP into C++, and has very limited support for various PHP modules. I don't think any of the common PHP apps like wordpress, joomla, etc work under hiphop. Stuff like Quercus is the jruby of PHP, being an actual implementation of PHP rather than a source -> source translator. But I haven't seen any benchmarks showing it actually beating regular PHP. It does have a much better security record than the official PHP though, and is probably a worthwhile project on that grounds alone.

</comment></comment></comment></comment></comment></comment></comment><comment><USER56> a few years ago a graphic designer asked me for some help using PHP to query a database.

I wrote a little thing that worked, and then said, "oh wait, this could be a problem with SQL injection, here's how you fix that".

And his response was "umm can you just send me the first thing you wrote".

<comment><USER57> I completely agree with you. The problem with PHP (besides the myriad warts of the language and libraries) is the average kind of programmers that use it: 0 code reuse, lots of cut & paste, insecure-by-design philosophy and the culture of 'immediate results': if there's an error fix it fix it for the current page so that the next time you refresh it'll be gone; then fix it on the other pages _later_. Rinse, repeat.

</comment></comment><comment><USER58> I'm not saying PHP is so great, not by a long shot; but if it's 2012, and people are still writing "OMG PHP SUX" posts, yet PHP is _still_ everywhere, the only thing I can see that meaning is this: the things that matter to people who write "OMG PHP SUX" posts don't matter to anyone else.

</comment><comment><USER59> > code that runs on virtually every server in the world with zero friction or > configuration hassles,

Quit being so fucking lazy, entitled, and expectfull of silver bullet.

Good tools require maint, they require good environment, they require a modicum of skill and/or effort.

The problem with PHP is not PHP. It is the PHP community. Which is filled (not all) with ignorant, don't wanna learn/understand, minimal effort expending schlubs.

The attitude "I'm a dev shouldn't have to know about sysadim", is fail, is fucked. No, you create a product. Should be aware, if not knowledgeable, of every aspect of that product and the team that creates it.

</comment><comment><USER60> I notice PHP has really bad rep amongst people who blog about building web apps. People who build web apps still seem to choose it, though.

I agree with Jeff that the way to replace PHP is to create a better alternative. Not just for PHP itself, but more importantly to stuff like Drupal and Wordpress and Magento.

Yet this is isn't happening. Django and Rails are about 7 years old (Python and Ruby both pre-date PHP) and haven't produced any CMS or blog engine remotely comparable in popularity.

How come? Maybe because perception of PHP differs so greatly between people who code and people who write about coding.

</comment><comment><USER61> Give me a non-PHP alternative to Drupal, and I'll switch in a second.

<comment><USER62> I found this one to be the better of Python's, IMO anyway.

<http://www.merengueproject.org/>

<comment><USER63> Merengue isn't that great. Save the headache and stick with Drupal.

</comment></comment></comment><comment><USER64> I work with PHP everyday at my job. Is it my favorite language? No. Are we in a position like others (e.g., Facebook) where we have a ton of code and infrastructure build around PHP? Yes. Do I love my company? Yes. We have strict coding standards and high requirements for code quality. Gradually, we are changing out some of our code for Python, where it makes sense, but I doubt we'll re-write our entire applications anytime soon.

We've taken our two-claw hammer and done some fairly nice work with it.

</comment><comment><USER65> My favourite part was when Jeff said that his article wasn't another post getting on the PHP hate wagon and then he takes pot-shots at the language, classy. I'd equate Jeff's article to that of squirting a water pistol into the ocean. Everyone knows PHP has some downsides, but it also has its upsides. PHP does have its positives, but of course pointing out the negatives of anything is a sure fire way of getting a response opposed to writing positive things. You can fault every major language, no language is perfect regardless of what anyone else says, JavaScript even has downsides but you'll be hard pressed to find as many hating articles on JavaScript as you would on PHP.

PHP is simple to configure and deploy, I can get a client Wordpress site migrated from my local environment to their server all setup and ready to go in less than 5 minutes. I'm tired of the argument of: "Well, I just use Heroku to push my Python and RoR projects live so your argument is invalid" the real issue here is that the only argument haters of PHP have against it being easy to deploy, is using a third party deployment app like Heroku which costs you money as opposed to being able to push a Wordpress site live via SCP or FTP without paying a cent.

I think when people hate on PHP they're confusing applications like Wordpress or PHP frameworks with the language itself. Wordpress is not PHP, it's an application built on PHP and we all know WP is poorly written but works this isn't the fault of PHP.

Don't like the language? Improve it or shut up. It's like being who complain about the war, but keep voting for the same political party..

</comment><comment><USER66> I'll start off by saying I don't know shit all about PHP on a fundamental level. What I have noticed is there there is a sweet-spot of developers, engineers that need to be involved.

Comments for "Adobe confirms it won't support Android" [1] are typical. Achshar writes[2], "I think the problem isnt flash itself but the fact that it's proprietary. This is the reason we have such news in the first place. If adobe drops support, it's dead. No such thing with open stuff. No one entity has all the control. This is where html5 upper leg, no one can suddenly start charging you for using it or dictate it's development."

K, so if being open is what prevents crap, then why are we here talking about PHP? Maybe its that there are too many hands in the cookie jar. Maybe too many people working on fundamental design is the problem.

Whether its A/B testing of choices or how many people should work in a group together – numbers matter. And maybe being too open, rather, too many (different) people working on the same spec, can also be bad as well.

[1] <http://news.ycombinator.com/item?id=4175399>

[2] <http://news.ycombinator.com/item?id=4176485>

</comment><comment><USER67> As fun and easy as it is to take potshots at PHP, and as much as I am against personally working on any medium-sized or larger project that is written in PHP, I feel like a bit of a hypocrite because I probably owe my career to PHP.

One "feature" of PHP that really no other language or platform has touched is the vast amount of pre-existing software that is out there written in it that you can quickly and easily tweak to suit your needs. This is how I got started programming in the mid-to-late 90's as a kid in high school.

There was some auction software written in PHP, and I setup an auction site and spent tons of nights making small tweaks to the software to make it a really cool and fully-featured auction site. Nobody listed a damn thing on the site, of course, but I was hooked.

\- Bad habits can be unlearned (I've unlearned enough to know)

\- You can go back and learn CS basics

\- You can gain an appreciation for well-designed languages and tradeoffs in design

But it is really, really hard to replicate that awesome feeling when you start out with some substantial piece of software and are able to incrementally make it better - making bigger and bigger changes as you learn more and become confident. The fact that so much open-source PHP software exists, the development cycle is so short, and it is so quick and easy to host makes it pretty good for that. Honestly, as much as I like Java now, if I'd started out trying to use it, who knows what I'd be doing now.

As crappy as the language is, it is good enough at a lot of things. You won't "kill" PHP by making a better language any more than you would beat CraigsList by designing a better UI.

</comment><comment><USER68> I guess I'll chip in here.

The handful of advantages that make PHP popular are also some of its worst liabilities. Yes, you can deploy with just FTP... but then you have upload security to worry about, and have to protect all your library files, and yadda yadda. Yes, you can do SQL right off the bat... but you have to take care of SQL injection yourself. Yes, you can stick your code right in your HTML... as hard to read as that may be. Yes, there's no resource leakage... but every request has to recompile the code and reconnect to your database.

None of these things are problems _at first_ , but they become problems quickly once your software expands beyond two pages or a hundred hits a day. Some of them may not even be obvious problems, but you'll pay the cost anyway when some kid steals your database.

Other platforms, meanwhile, tend to have fairly simple solutions to all of these problems, for the price of a minor increase in upfront learning. But since the problems are all things that happen later on, newcomers will just see that language X is harder.

This poses something of a difficulty. How can other languages introduce the ease of PHP that everyone's demanding? We can't just port exactly the same features over, or we'll have exactly the same problems. mod_python was a bad enough idea that it's dead now. Heroku is a neat thing, but still requires writing configuration files, and nobody enjoys doing that. Nothing is really well-suited for single-page fire-and-forget, either.

I _have_ been thinking about this since writing that damned fractal post, but I'm not clever enough to have thought up a solution yet. So, you know, it would be useful if we could brainstorm on how to fix the learning curve and deployment instead of "just turn everything else into PHP!"

</comment><comment><USER69> I worry that these kind of articles are not just annoying. They can cause real damage.

// A Dramatization //

Consider a young developer that knows a bit of PHP and wants to get started on her project. Then she (or "he", or "they" .. whatever) reads HN and finds out that PHP sucks. HN is Mecca to her, so she now spends the next 3 months figuring out that (truly) superior language. She picks whichever framework most HNers are (innocently) promoting at the time.

What she doesn't know is that those karma-gods took their sweet time to figure out 10 other things (== 1000 hours) before using said superior language and framework. It's supposed to be easy, she thinks. She gets frustrated because no-one had told her about those 10 other things. Time is running out on her savings. "I'm not a real hacker", she thinks. She never airs her project.

// End Scene //

Now run the same story, only she doesn't read HN and just codes the thing in PHP. It's actually a pretty cool project and ends up on first page of HN ...

<comment><USER70> "she doesn't read HN and just codes the thing in PHP. It's actually a pretty cool project and ends up on first page of HN ..." This happens alot. I see cool PHP projects on first page all the time.

</comment></comment><comment><USER71> Anyone have a full article on how to build a site with just Python and not using Django? This would be more helpful than bashing PHP.

The article would have to show us how to install Python, configure it, get it working on the server, what to upload, how to deal with forms, cookies, etc. I've yet to see this kind of article. I wouldn't mind learning Python for web use, but every book I've seen suggests you just use a framework or has a very small chapter composing of a few pages. Such an article or even a book, would get more people off PHP, if that's what people want. Until then PHP gets stuff done and that's all clients care about, no one cares if I use Windows, Linux or Mac OS X when I work. Granted I'm not a l33t programmer like most on here, I'm just here to learn from better coders.

</comment><comment><USER72> <http://xkcd.com/927/> s/standards/web app platforms/

<comment><USER73> <rant>Okay, not directed at you, but... It was posted yesterday. Does this really have to be posted EVERY SINGLE DAY?

Every time anyone suggests improving anything, or make another product in a crowded space, this comic is posted. The author of this article doesn't even suggest a new platform - he suggests improving a platform that exists to enable easier deployment. It was posted yesterday for Chocolat... do we really have to stop making editors?

In a site targetted to hackers and startups it is disturbing that people are so unwilling to learn something new, support a new product, improve the world, do anything new. Yes, redundant standards suck sometimes, but it's not always the case.

I wish that the comic author would consider deleting this from the server, or maybe pg could ban it.</rant>

<comment><USER72> Well, not exactly. The author does suggest a new one:

> I'm starting a new open source web project with the goal of making the code > as freely and easily runnable to the world as possible.

<comment><USER73> Nope. In this line he's talking about a web app he's writing and how he considered writing it in PHP to boost adoption. Here's it in context:

"I'm starting a new open source web project with the goal of making the code as freely and easily runnable to the world as possible. Despite the serious problems with PHP, I was forced to consider it."

</comment></comment></comment></comment><comment><USER74> One thing that keeps me coming back to PHP after trying out RoR, Python (Django), node.js is the deployment.

All I have to do is create a new directory, create a new vhosts file run a few apache commands, reload apache and I'm done. In total, it should take less than a minute to get a directory set up for deployment.

With other languages, they haven't gotten the deployment part down as smoothly as the PHP/Apache experience.

Sure, I can go with Heroku or other IaaS solutions, but I want to run it on __my __server, I like being able to back up an entire directory that houses all of the sites and projects I'm currently working on, and not have to figure out how to use API's of different services.

</comment><comment><USER62> Ex-PHP developers that bash PHP are like the poor kids that win the lottery and then start bashing poor people publicly.

Sad and kinda small of them.

I'm willing to win the lottery, mind you, but I'd never waste my time or lower myself down to bashing poor kids.

<comment><USER75> Surely that'd be

"Ex-PHP developers that bash PHP _programmers_ are like the poor kids that win the lottery and then start bashing poor people publicly."

or

"Ex-PHP developers that bash PHP are like the poor kids that win the lottery and then start bashing _being_ poor publicly."

? Very different, IMO.

<comment><USER62> The first one. I think the language is pretty fair game. However, the bashing seems to carry on over to the programmer often enough.

<comment><USER75> Yeah, it's a fine line between just bashing a tool and bashing its users as well. I feel the submission came down on the bashing-the-tool-only side, but that's a judgement call.

</comment></comment></comment></comment><comment><USER76> I'm a long-time PHP programmer and have been programming with Lua (for gaming) for the past year and Python for command-line (NumPy) based scripts for the past two years. Obviously, in comparison, the syntax in Lua and Python are a thing of beauty as are the data structures (Lua tables FTW), but I always fall back to PHP for web projects since I haven't had the chance to completely grok the Python deployment process.

Is there a simple guide to deploying Python web applications (preferably with Flask)? I know there are quite a few options (WSGI, FastCGI, mod_python), but what is the best way to do it.

<comment><USER77> Better: Deploy a Lua-based stack. [1][2]

I've tried to get a Python stack to build and it's huge, complicated to set up and get running well, and so _slow_ compared to LuaJIT as to be pathetic. A friend was at PyCon surrounding by a bunch of Python hackers who spent more than an hour _trying_ to get Django installed on his server an they _failed._ If the so-called experts have a hard time with it, then I don't feel so bad for finding it hard myself -- and I wouldn't recommend it to anyone.

Both Lua solutions I linked are easy and fast to install and configure (if you've got a shell, at least), and the Lua stacks are like Node.JS done _right_. You get coroutines so you get non-blocking code without having to code everything as an awkward callback. And of course you get the awesomeness of Lua instead of having to deal with the mess that is JavaScript.

[1] <http://tir.mongrel2.org/>

[2] <http://openresty.org/>

</comment></comment><comment><USER78> PHP is like the English language, full of inconsistencies but everyone speaks it.

</comment><comment><USER79> I used to really like Coding Horror, but everything Atwood writes now days he sounds like a damn broken record. And his twitter feed is nothing short of immature and childish.

</comment><comment><USER80> >Guess what? It was just as horrible in 2008.

I don't do much PHP these days, but PHP has actually added some good stuff in recent years: functions as variables, traits, etc.

</comment><comment><USER81> _Yawn_. Can someone explain to me why this sort of post keeps getting written? It seems like it's just snooty hipsterism. "I want to make sure people know that PHP is bad!" Please, point out to me the developer who has not heard this _a million fucking times already_.

Serious question: besides "cred" and just stirring the pot, what is the _point_ of writing a post like this?

</comment><comment><USER82> PHP got Facebook up and running, so it has that to its credit. And that's a huge credit.

As a result, Facebook engineers developed things like this: <http://en.wikipedia.org/wiki/HipHop_for_PHP>

Which is an impressive piece of technology, but makes you wonder if Facebook engineers wish their website wasn't written in PHP.

<comment><USER20> It surprised me, considering the original developers of facebook (Zuckerberg, Moskovitz) were doing Computer Science degrees why they chose PHP to build it in initially. Did they consider other languages, or frameworks.

I'd be surprised if they chose PHP because of future hireability / scaling up. I'd guess they didn't give it much thought and PHP was just there.

<comment><USER83> In the early part of this century, PHP was basically still _the_ free language for writing dynamic web content.

The second place choice was probably perl (via cgi or mod_perl).

I guess Tomcat was around too.

Both Django and Rails were released after facebook.

</comment></comment></comment><comment><USER84> My 2 cents: <http://ianlandsman.com/2012/06/29/PHP>

</comment><comment><USER85> The whole web development thing is broken. Even with cutting edge tools like asp.net mvc, or rails or whatever we're still using half a dozen different technologies to build a web page and to me it feels like I'm fighting around the http protocol trying to hack my way through various inconsistencies.

</comment><comment><USER86> Unfortunatley, from language design perspective, both PHP and JavaScript are down right horrible. But they get the work done. In general dynamically typed scripting languages are playgrounds for errors - a statically typed paradigm might help - but we are too late for that.

</comment><comment><USER56> Do the PHP frameworks help at all?

<comment><USER87> I would say yes, although to varying degrees depending on the framework. IMO, the safest bet would be to use an 'enterprise' level framework (Zend, Symfony2). But, as jrgnsd mentioned in his reply, even within the context of a framework, an inexperienced developer can still make plenty of mistakes and poor design choices. Learning the framework isn't enough, the developer must also take care to adhere to best practices in software design.

</comment></comment><comment><USER88> Other languages need to work on making application deployment easier. Often, you can deploy a PHP app without ever opening a terminal. Heck, some hosters didn't even give you access to a terminal.

</comment><comment><USER89> Jeff has buried the lead.

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

That's a terrific point. Alas, it is at the bottom of what is basically another of the "PHP sucks" posts, of which he says we already have too many. And now this comment thread is hip-deep in "Shut up, PHP works fine" posts.

I'm self-taught on Python, and I love it, but as I've moved freelance I've had to learn PHP, and I . . . don't love it. It is what many of my clients use, for reasons that seem good to them, so there you go. I don' enjoy learning it and using it the way I enjoy Python, but as a professional that's Just Too Damn Bad. So I'm kind of with the people irritated by the PHP bitching.

But I wish that Python had those characteristics that make PHP ubiquitous. I'm too new to really state what these are, and I imagine there are some good design reasons for avoiding some of those patterns. But anyone preferring that something like Python or Ruby should see wider adoption has to consider the aspects of PHP that have supported its prevalence, and compete on those aspects.

I am going to guess that Jeff felt the need to critique PHP because he thought there must be some justification for duplicating those functionalities of PHP. I think the community is at a consensus that there isn't, and shouldn't / couldn't be, One True Language, and that it's okay to choose the proper tool for a particular job. And if that's the case, why would it make sense to revise Python or Ruby to duplicate stuff that's already done well by PHP? Why insist that any one language do everything? The best argument would be that PHP gets a lot right, but couples that to a lot it gets wrong. And whether or not that is so drives the question of whether some other language should trouble itself to duplicate the stuff PHP gets right.

It might be enough to say that some people / many people don't like PHP very much and wish that other tools were more prevalent. Among such people, the questions then are: 1) are we just being jerks, is there really that much to be gained by getting away from PHP? and 2) how do other languages have to change (technically, the installed base / trained developer population arguments are beyond this discussion) to compete? And I think the two questions are related. If it isn't hard to make Python as deployable as PHP, then we needn't gain much to make it worthwhile. But if those changes are hard, or they somehow introduce into Python anti-patterns of some kind, or shift the community focus in some negative way, then we would have to see much larger gains to make the shift worthwhile.

I hope Jeff reviews the reaction to this and responds with another post, one that explores why PHP is so frequently adopted. (Again, it's best to put to one side the issues of widespread developer knowledge and default configuration in support of it, if a better alternative is built those things will move.) And, what are the challenges of adapting Python / Ruby / Perl to competing on those technical aspects? And what are the technical / community risks of making those adaptations? At that point I think he's moving the discussion in a much more constructive direction.

</comment><comment><USER90> And you know the saddest thing, I'm sitting here reading all these comments instead of actually programming... if I'm not getting anything done, does it really matter which language I'm using?

</comment><comment><USER91> Here we go again...

Maybe it does suck. You can certainly tell it was not designed by computer scientists. In many ways, it throws away years for programming language best practices.

This being said, what are the practical alternatives? JSP? Servlets? ASP? Python/Django? Ruby/Rails? What?

I am sorry but JSP, Servlets, ASP, Python/Django, Ruby/Rails are just shit of a different kind. But they do not deserve that holier-than-thou aura.

I suggest bad programmers keep blaming their tools for their own shortcomings. I suggest that when bad programmers have produced enough horrors to sully a tool, they blame the tool and move on to the next tool.

<comment><USER92> Python's Flask is a good, lightweight web framework that works fine. It was a breath of fresh air compared to PHP, and I can understand it, unlike Django.

<comment><USER91> I am open minded. I will give Flask a try.

I doubt it'll be easier to deploy than a LAMP server, though. I already recoil at the idea of having to figure out why Passenger is not working as it should, or why I should run a terrible HTTP front just to try this out.

<comment><USER92> It's a little bit more difficult (especially since if you want to use Apache you'd have to configure it manually), however there are plenty of Python WSGI hosts out there that should make it simpler.

</comment></comment></comment></comment><comment><USER66> > PHP is the Nickelback of programming languages.

Look at this script that uploads a photograph. Every time I see it, it makes me laugh.

</comment><comment><USER42> I wish bloggers would stop quoting that fractal article. At least 50% of what's written in there is totally wrong/false. Other information is terribly out of date. And even more information is merely half-truths and lack of understanding of the language. The article author clearly scanned through PHP bashing articles and took material from them verbatim; mistakes and all.

I'm not going to argue that PHP is a great language, but the article is a complete disservice to anyone who has bothered to read it. I'm disappointed, but not surprised, that Jeff Atwood linked to it.

Just a few errrors in that article:

> Operators are very fragile in the parser; foo()[0] and foo()->method() are > both syntax errors. The former is allegedly fixed in PHP 5.4, but I can't > find mention of a fix for the latter.*

The latter doesn't need a fix because it always worked. Honestly, how hard is it to test that foo()->method() works?

> Objects compare as greater than anything else… except other objects, which > they are neither less than nor greater than.

Strict-equals on objects compares the references; but regular equals compares the contents of the objects. Two objects compare equal if the contain exactly the same fields and values. Seems pretty reasonable to me.

> \+ is always addition, and . is always concatenation.

This is a good thing; JavaScript gets this wrong.

> There is no way to declare a variable. Variables that don't exist are > created with a null value when first used.

Variables that don't exist issue a notice. You can deal with that just like any other error.

> Global variables need a global declaration before they can be used.

Actually there is also the $GLOBALS array for this. I'll agree that's not much a solution. Globals should just not be used; if you want to use static class variables, it's a much better choice with a sane syntax.

> there's no pass-by-object identity like in Python.

I'm not sure if I understand this but all objects are passed-by-reference in PHP (since 5) and PHP references act appropriately when used as function parameters, etc.

> A reference can be taken to a key that doesn't exist within an undefined > variable (which becomes an array). Using a non-existent array normally > issues a notice, but this does not.

An attempt to use the reference will result in a notice but isset() and empty() operate it on it correctly.

> Constants are defined by a function call taking a string; before that, they > don't exist.

You can declare constants in classes and namespaces with the const keyword.

> There's an (array) operator for casting to array. Given that PHP has no > other structure type, I don't know why this exists.

You can cast scalars to single element arrays and objects to arrays with the same structure. Both are actually very useful.

> include() and friends are basically C's #include: they dump another source > file into yours. There is no module system, even for PHP code.

PHP is interpreted -- namespaces and autoloaders are PHP's module system.

> Appending to an array is done with $foo[] = $bar

This is a good thing.

> empty($var) is so extremely not-a-function that anything but a variable,

Empty is equivalent to the not operator but will also work on undefined variables -- that's why it requires a variable.

> There's redundant syntax for blocks: if (...): ... endif;, etc.

Useful inside of templates where matching { } is much more difficult.

> PHP's one unique operator is @ (actually borrowed from DOS), which silences > errors.

Sometimes you don't care if a function succeeds; like with the unlink() function which will raise an error if the file you're trying to delete doesn't exist.

> PHP errors don't provide stack traces.

Not true. Debug_backtrace() will give you a stack trace in an error handler.

> Most error handling is in the form of printing a line to a server log nobody > reads and carrying on.

Assuming, of course, the programmer doesn't do anything to handle errors.

> E_STRICT is a thing, but it doesn't seem to actually prevent much and > there's no documentation on what it actually does.

E_STRICT (or lack of it) is for compatibility with PHP4. When enabled it will "warn you about code usage which is deprecated or which may not be future- proof." -- quote from the manual.

> E_ALL includes all error categories—except E_STRICT.

Unfortunate naming here -- E_ALL is from PHP4 and prior and E_STRICT is all about PHP5. Including it in E_ALL would break PHP4 scripts running on PHP5.

> Weirdly inconsistent about what's allowed and what isn't.

This author is confused why syntax errors would be parse errors but logic errors are not.

> PHP errors and PHP exceptions are completely different beasts. They don't > seem to interact at all.

This is sort of true; PHP errors and exceptions exist in different universes but it's easy to unify them and PHP even provides a built-in exception ErrorException to do so. You can turn every PHP error into an exception with 4 lines of code complete with stack traces. You could even turn exceptions into errors but I wouldn't recommend that. PHP supports both procedural and OO programming styles -- this is not a bad thing.

> There is no finally construct

C++ also doesn't have a finally construct. But C++ and PHP support RAII -- class destructors run when the stack is unwound so you can do your cleanup. Finally would be a welcome addition to both languages.

> function foo() { return new __stdClass(); } leaks memory. The garbage > collector can only collect garbage that has a name.

PHP is reference counted with a cycle-detecting GC. That would not leak memory.

> Function arguments can have "type hints", which are basically just static > typing. But you can't require that an argument be an int or string or object > or other "core" type

This is true, but it's an ongoing discussion on how to correctly handle scalar type hints. For all the discussion about how PHP isn't designed the author takes issue with the thing they're taking their time on.

> Closures require explicitly naming every variable to be closed-over. Why > can't the interpreter figure this out?

Because of the dynamic abilities of PHP, there is simply no way for the interpreter to ever figure out the variable to close over. The solution is actually a rather simple.

> clone is an operator?!

Of course!

> Object attributes are $obj->foo, but class attributes are $obj::foo. I'm not > aware of another language that does this or how it's useful.

C++ does it. $obj::foo doesn't make any sense, if you're accessing class attributes then you use the class name Class::foo.

> Also, an instance method can still be called statically (Class::method()). > If done so from another method, this is treated like a regular method call > on the current $this. I think.

Only static methods can be called statically. The other calling methods statically is similar to C++ ... you can call parent class methods explicitly by name by-passing any overriding.

> new, private, public, protected, static, etc. Trying to win over Java > developers? I'm aware this is more personal taste, but I don't know why this > stuff is necessary in a dynamic language

This is personal taste not a valid critique.

> Subclasses cannot override private methods.

That is the definition of private methods!

> There is no method you can call on a class to allocate memory and create an > object.

You can use reflection to create an object without calling the constructor.

> Static variables inside instance methods are global; they share the same > value across all instances of the class

This is the definition of a static property!

> Yet a massive portion of the standard library is still very thin wrappers > around C APIs

That is, in fact, the point. PHP is supposed to be a thin scripting language layer over C. It's expanded beyond that. Many of the poor naming conventions are not because of PHP but rather are the exact API of the underlying C library.

> Warts like mysql_real_escape_string, even though it has the same arguments > as the broken mysql_escape_string, just because it's part of the MySQL C > API.

Both the C API and PHP have both these functions for backwards compatibility reasons. This entire API is pretty much depreciated with both the mysqli library and PDO replacing it.

> Using multiple MySQL connections apparently requires passing a connection > handle on every function call.

Yes, exactly. That's the only way multiple connections could possibly work.

> PHP basically runs as CGI. Every time a page is hit, PHP recompiles the > whole thing before executing it.

Unless you use a free code cache like APC. It will eventually be built in. Most people don't need it.

> For quite a long time, PHP errors went to the client by default

If you don't handle your errors, they go somewhere.

> Missing features

Most of these are provided by frameworks just as they are in Python, Ruby, C#, etc.

> Insecure-by-default

Most of these things are now removed from the language after being depreciated for years.

<comment><USER68> > Strict-equals on objects compares the references; but regular equals > compares the contents of the objects. Two objects compare equal if the > contain exactly the same fields and values. Seems pretty reasonable to me.

The line you quoted is talking about ordering, not equality.

> This is a good thing; JavaScript gets this wrong.

It IS a good thing, but it stands out when most of the language is extremely weakly-typed and even the original manual claims that separate operators for strings and numbers are confusing.

> I'm not sure if I understand this but all objects are passed-by-reference in > PHP (since 5) and PHP references act appropriately when used as function > parameters, etc.

So some things (objects) are passed by reference implicitly, and some (all else) are not. Yikes!

> You can declare constants in classes and namespaces with the const keyword.

Okay. Why not at top-level?

> You can cast scalars to single element arrays and objects to arrays with the > same structure. Both are actually very useful.

You've practically invented a bug right there: if I write a function that can take either one value or an array of items, and you pass in a single object, I'll get a useless keyed array of its attributes.

> PHP is interpreted -- namespaces and autoloaders are PHP's module system.

What does being interpreted have to do with anything? Python and Perl are bytecode-interpreted (not positive about Ruby) and they both have rich module systems that don't require any fussing around. Heck, shell is interpreted, but zsh manages something almost like modules.

> Empty is equivalent to the not operator but will also work on undefined > variables -- that's why it requires a variable.

Why does it need to look like a function when it clearly isn't one? return and echo don't.

> Useful inside of templates where matching { } is much more difficult.

In theory, but I've never seen any actual PHP code that uses them.

> Sometimes you don't care if a function succeeds; like with the unlink() > function which will raise an error if the file you're trying to delete > doesn't exist.

That's what exception handling is for -- unfortunately, PHP errors are an entirely separate beast from PHP exceptions.

> Not true. Debug_backtrace() will give you a stack trace in an error handler.

I said "PHP errors don't provide stack traces", and you aren't disputing that. Your own code can muck around to give you a stack trace (in most cases), yes, but the runtime doesn't do it for you.

> Assuming, of course, the programmer doesn't do anything to handle errors.

Defaults are important. I sure have a lot of people telling me it's great that PHP does web stuff out of the box -- why is it not then bad that PHP doesn't help you fix errors out of the box?

> E_STRICT (or lack of it) is for compatibility with PHP4. When enabled it > will "warn you about code usage which is deprecated or which may not be > future-proof." -- quote from the manual.

Yes, and that doesn't describe what it does. You can't tell what it's for, either: it's clearly not for compatibility with just PHP4, because even the PHP 5.4 release notes mention the addition of a new E_STRICT. Yet I can't be sure on what parts of the language actually ARE deprecated without reading the entire manual looking for mentions of E_STRICT.

> This author is confused why syntax errors would be parse errors but logic > errors are not.

Read more carefully; the two lists are written roughly in parallel. A bogus object attribute gets a warning, but a bogus class attribute is a fatal error. (Not an exception, either, so you can't catch it with the exception handling that the OO system is supposed to be using.) A string value stored in a variable can be called, but the same string value as a literal cannot. And so on.

> This is sort of true; PHP errors and exceptions exist in different universes > but it's easy to unify them and PHP even provides a built-in exception > ErrorException to do so. You can turn every PHP error into an exception with > 4 lines of code complete with stack traces.

Neat, though my understanding is that this still doesn't work with fatal errors, which are shockingly common.

I have the same kind of complaints about Perl's exception handling -- it's entirely possible to hack it into something more useful, but why on Earth should I have to mess around just to make something as fundamental as errors be developer-friendly?

> PHP supports both procedural and OO programming styles -- this is not a bad > thing.

Exception handling isn't inherently OO. Perl has its own flavor of try/catch that requires zero objects whatsoever.

> PHP is reference counted with a cycle-detecting GC. That would not leak > memory.

I believe it used to, but I removed this due to the short window during which it was a bug. I see this list of counter-arguments hasn't been updated in a while.

> This is true, but it's an ongoing discussion on how to correctly handle > scalar type hints. For all the discussion about how PHP isn't designed the > author takes issue with the thing they're taking their time on.

My issue isn't that they're taking their time, but that they implement _half_ of a feature and _then_ decide to sit down and think about the other half (while now constrained by whatever hack job they've already done).

> Because of the dynamic abilities of PHP, there is simply no way for the > interpreter to ever figure out the variable to close over.

Every other dynamic language ever sure seems to be able to get this right.

> C++ does it. $obj::foo doesn't make any sense, if you're accessing class > attributes then you use the class name Class::foo.

Then why not use Class->foo? Why does this need two operators? $obj::foo is perfectly reasonable if I want the foo attribute of whatever class $obj is; that's half the reason I ever use class attributes.

> This is personal taste not a valid critique.

Yes, which is why I said it's personal taste. Regardless, it's still wildly inconsistent with the rest of the language and poorly bolted on.

> That is, in fact, the point. PHP is supposed to be a thin scripting language > layer over C. It's expanded beyond that. Many of the poor naming conventions > are not because of PHP but rather are the exact API of the underlying C > library.

How many people using PHP today came from C, exactly?

> Both the C API and PHP have both these functions for backwards compatibility > reasons.

No. The C API has two functions because one takes only a value to escape, and the other takes both a value and a connection pointer. Both functions in PHP can be called with merely a value, and the "real" one will use the current global connection. Zend could have merely switched the old escape function to have the new behavior, and all existing code would have been instantly _fixed_ , not broken.

> Most of these are provided by frameworks just as they are in Python, Ruby, > C#, etc.

PHP is praised for its web features, but is missing a whole pile of functionality instrumental for actually writing nontrivial web applications. Either judge PHP only by the core language, or judge everything else by what you get with frameworks.

<comment><USER42> > It IS a good thing, but it stands out when most of the language is extremely > weakly-typed

You only need distinct operators if your language is weakly typed. If you language is strongly typed like Python, Java, or C# then there is never any conflict between addition and concatenation. VB/VB.NET is also weakly typed and has separate operators.

> So some things (objects) are passed by reference implicitly, and some (all > else) are not. Yikes!

Yes, like most ever other language in existence. You know, Java, C#, Python, etc.

> Okay. Why not at top-level?

Because all code should be contained within a namespace going forward. Constants should not be defined in the top-level.

> if I write a function that can take either one value or an array of items, > and you pass in a single object, I'll get a useless keyed array of its > attributes.

No, it doesn't work that way. You have to explicitly cast. If you use an array type-hint you can only pass an array.

> Python and Perl are bytecode-interpreted (not positive about Ruby) and they > both have rich module systems that don't require any fussing around.

PHP is also bytecode-interpreted. I'm not really sure what point you're trying to make. It's super easy to integrate code from different libraries with namespaces and autoloading.

> Why does it need to look like a function when it clearly isn't one? return > and echo don't.

Because it's used an expression not a statement like return and echo. The fact that is or is not a function is insignificant; you use it the same way.

> In theory, but I've never seen any actual PHP code that uses them.

In templates you see it all the time.

> That's what exception handling is for -- unfortunately, PHP errors are an > entirely separate beast from PHP exceptions.

If you convert all errors to exceptions, you could catch it. It's just an additional feature. If you handle your own errors, you can even ignore the error suppression operator if you choose.

> I said "PHP errors don't provide stack traces", and you aren't disputing > that... but the runtime doesn't do it for you.

Oh, you're saying if you don't provide any of your own error handling and let it spill out the terminal -- yes, you're right -- no stack trace by default. Not that you should be doing that. If you really want that though, it can be provided by the XDebug extension.

> it's clearly not for compatibility with just PHP4

The lack of E_STRICT helps you run PHP4 code on PHP5. That's why it's not included in E_ALL. For example, I have an application that runs unmodified on PHP4 and PHP5.

> Yet I can't be sure on what parts of the language actually ARE deprecated > without reading the entire manual looking for mentions of E_STRICT.

Turn on E_STRICT and it'll tell you.

> A bogus object attribute gets a warning, but a bogus class attribute is a > fatal error.

Yes, one is defined and one is not.

> A string value stored in a variable can be called, but the same string value > as a literal cannot.

Calling a string literal is pointless! 'test'() is test()!

> Neat, though my understanding is that this still doesn't work with fatal > errors, which are shockingly common.

Fatal errors are not that common but I won't argue the point too heavily because they _are_ a bitch. PHP developers are trying to reduce the number of fatal errors. Most IDE's will notify you of fatal error as you type.

> but that they implement half of a feature and then decide to sit down and > think about the other half (while now constrained by whatever hack job > they've already done).

There's nothing controversial or difficult about object type hinting. Also since PHP is meant to be typeless there is some discussion over whether scalar type hints are even necessary. Giving you something you can use right now is not a bad thing.

> Then why not use Class->foo? Why does this need two operators?

I suspect historical reasons. They really did do very different things in PHP3/PHP4.

> Regardless, it's still wildly inconsistent with the rest of the language and > poorly bolted on.

How so? It's PHP object system, there is nothing for it to be inconsistent with in the rest of the language.

> How many people using PHP today came from C, exactly?

It's not about whether they came from C -- it's the fact that PHP quickly implemented access to a huge library of existing C libraries (and tracked their changes). This was a _huge_ deal back when PHP was younger.

> Zend could have merely switched the old escape function to have the new > behavior, and all existing code would have been instantly fixed, not broken.

If you've ever complained about security in PHP, you need to give that up right now. Because you just gave everyone a false sense of security.

> Either judge PHP only by the core language, or judge everything else by what > you get with frameworks.

Wait, why? That's ridiculous.

<comment><USER68> tl;dr: I value consistency in my tools because it's a great measure of how frequently they'll trip me up and get in my way while reading or writing code. My biggest problem with PHP above all else, which I tried to write my article around, is that it's an inconsistent jumble from top to bottom.

You're absolutely correct, of course, in that you can write decent PHP by avoiding large chunks of the language, memorizing what things act differently from other things that look the same, not trying to do anything _too_ dynamic, adding boilerplate to every project to fix useless default interpreter behavior, and so on. You can also waltz across a minefield if you just remember where all the mines are. But the necessity of doing all these things is exactly my argument: why bother with all this from a tool that's supposed to help you get stuff done? Because it has $_GET out of the box? You can't even claim "ease of learning" as an advantage after all this, because judging by your own responses, much of the language is pitfalls just waiting to trip up beginners who haven't yet learned the right painful lessons.

Yes, I'm not a PHP programmer. And as a not-PHP programmer, a lot of PHP looks totally crazy. But when outsiders complain about craziness in Python or Perl or Haskell or whatever, at least that craziness can usually be explained as consistent with the rest of the language, or part of an overall philosophy, or the result of some valuable tradeoff. And if not, we're very sympathetic about the ugly warts on our dearly beloved. Yet all anyone has ever been able to tell me about PHP craziness is "well, you shouldn't do that anyway" or "that's how it is in one of ten other languages" or "I have no explanation but here's a workaround so it's like the problem doesn't actually exist, right".

It is hard for me to understand how even someone who loves PHP can't see this as deeply alarming.

> You only need distinct operators if your language is weakly typed.

I don't dispute that: I claim that having separate addition and concatenation operators, but having a single set of equality/comparison operators, is _inconsistent_.

> Yes, like most ever other language in existence. You know, Java, C#, Python, > etc.

Incorrect. Python passes everything by reference (value reference, not name reference) because everything is an object. Passing never performs a copy. I'm under the impression that Java is the same. Perl passes by alias, though the aliases are generally then copied to locals, and it has that whole array- flattening behavior which muddies things.

> Because all code should be contained within a namespace going forward. > Constants should not be defined in the top-level.

Everything in Perl is in the `main` namespace unless otherwise specified. One wonders why PHP could not retrofit its new features onto the language like Perl has done for decades, rather than leaving half the language to flounder.

> No, it doesn't work that way. You have to explicitly cast. If you use an > array type-hint you can only pass an array.

I'm assuming you're using the explicit cast inside the hypothetical function.

> PHP is also bytecode-interpreted. I'm not really sure what point you're > trying to make.

You appeared to be citing interpreted-ness as a reason for having a wonky module system. I am naming other interpreted languages with useful module systems as counterexamples.

> The fact that is or is not a function is insignificant; you use it the same > way.

Unless you want to do other function-y things to it, or any of the other pseudo-functions. The syntax is deliberately designed to make you think something is a function, but it only acts like a function in one particular way. (And as a side effect, there are a ton of simple function names you can't use as method names, because the parser gets very confused -- even though this seems like it should be unambiguous.)

> Oh, you're saying if you don't provide any of your own error handling and > let it spill out the terminal -- yes, you're right -- no stack trace by > default. Not that you should be doing that.

Defaults matter. This is an atrocious default.

> Turn on E_STRICT and it'll tell you.

It'll tell me what things I've already done; I can't easily find out what I should be avoiding proactively.

> Calling a string literal is pointless! 'test'() is test()!

So what? Both are values; why is there any distinction? Hell, you can call methods on numbers in Ruby and Python. I don't care about the practical value here; it's yet another place where PHP is inconsistent for seemingly no reason.

> If you've ever complained about security in PHP, you need to give that up > right now. Because you just gave everyone a false sense of security.

Howso? The problem with mysql_escape_string was that it didn't take the current database handle into account. So: make it take the current database handle into account. It may not have solved everyone's problems, but the exceptions are obvious, and it would have fixed problems for far more people than the actual solution (zero).

If you're using multiple handles and passing them around explicitly, you'll have to fix your code either way.

<comment><USER42> > I'm under the impression that Java is the same.

No, Java is not the same. Scalars not objects in Java and are passed by value. C# is similar, except scalars are value-type objects and are passed by value.

> I'm assuming you're using the explicit cast inside the hypothetical > function.

That's not what we were talking about. It's incredibly hard to have a reasonable conversation about this with you because you clearly only know a very small set of similar languages and have no experience with PHP at all.

> You appeared to be citing interpreted-ness as a reason for having a wonky > module system.

You cited byte-code interpreted as if that's somewhat significant. PHP's module system really isn't very "wonky" -- it works as advertised. But since you don't use it, you wouldn't know.

> It'll tell me what things I've already done; I can't easily find out what I > should be avoiding proactively.

You could read the manual. If you're new to PHP, you'd probably code strictly from the start.

> So what? Both are values; why is there any distinction?

Most languages make the distinction. Why shouldn't there be? That's really ugly code.

> Hell, you can call methods on numbers in Ruby and Python.

That's fine. It doesn't mean _every_ language should do the same. Most languages, especially those PHP is based on, do not do that. Maybe one day PHP will have that but because it's weakly typed, it's difficult to know even what methods should exist. In PHP, it's perfectly reasonable to say strlen(1). Does that mean every number should have string methods? I'm guessing you never considered that?

> The problem with mysql_escape_string was that it didn't take the current > database handle into account.

Yes, because the encoding properties of the current database connection are needed for encoding properly. If have two database connections, then what? It picks the first connection as the default and you encode incorrectly? Or if you had a second connection, do you just break all the existing code? What if the second connection doesn't happen every time? Then you're code is broken only every second Wednesday?

You've got a very singular perspective on things. That's fine. But by critiquing another language without knowing it you're making a lot of assumptions and blowing things way out of proportion.

<comment><USER68> > No, Java is not the same. Scalars not objects in Java and are passed by > value.

How are pass-by-value and pass-by-object distinguishable for immutable values?

> That's not what we were talking about.

Yes it is. You said (array) as a cast is useful because a function can accept either a single value or an array of values, and the (array) cast will produce an array either way. I contend that doing this doesn't really work, because passing a single value _that happens to be an object_ will cause the function to cast it to an array of the object's contents, which will have fascinating but useless results.

> You cited byte-code interpreted as if that's somewhat significant.

I only mentioned bytecode for the sake of pedantry: strictly speaking Python isn't interpreted, whereas e.g. shell is.

> You could read the manual.

I had to do quite a lot of that. It's kind of wordy. :)

> Most languages make the distinction. Why shouldn't there be? That's really > ugly code.

I'm not proposing that people write code like this. I'm objecting to the inconsistency between a value in a variable and a value in source code.

Note that, for the same reason, you also can't chain calls like `foo()()`. There ARE good reasons for that: you could return a function name, or a closure, or an object that supports being called. But because the parser doesn't just allow trying to use parentheses on an arbitrary value, this doesn't work. Just like `foo()[]` didn't work until recently, because it too had to be special-cased.

> That's fine. It doesn't mean every language should do the same. Most > languages, especially those PHP is based on, do not do that.

Really? C doesn't have methods. C++ has methods, but string literals are C strings so they have no methods. Perl doesn't consider builtin types to be objects, but if you turn them into objects with `autobox`, methods work equally well on variables and literals. Python allows method calls on literals -- and will let you try to call them, but of course literal strings aren't callable so this won't do anything. It _parses_ , though. Ruby is the same. "foo".equals("bar") is a common Java idiom.

What language are you thinking of where there's a distinction made -- _in the parser_ , no less -- between a variable and an expression?

> Maybe one day PHP will have that but because it's weakly typed, it's > difficult to know even what methods should exist. In PHP, it's perfectly > reasonable to say strlen(1). Does that mean every number should have string > methods? I'm guessing you never considered that?

Sure, why not? Not that I was suggesting PHP direly needs scalar methods, but if a number responds to strlen(), why not to ->strlen()?

> Yes, because the encoding properties of the current database connection are > needed for encoding properly. If have two database connections, then what?

Then you're screwed no matter what Zend does and still need to fix your code. So the options were: 1\. Leave the existing function totally broken. Create a new one with a confusing and even longer name. Make everyone fix their code and remember to use the new function in the future. 2\. Fix the issue in-place for the vast majority of existing code. Make the edge cases fix their code by doing the same thing they have to do with every other API function anyway. Optionally, throw a warning when multiple handles exist and mysql_escape_string is called with only one argument.

What, then, is the appeal of (1)?

> You've got a very singular perspective on things. That's fine. But by > critiquing another language without knowing it you're making a lot of > assumptions and blowing things way out of proportion.

I'm hearing this a lot, but (as far as I can be trusted to say this) I don't see it. I draw a lot of comparisons to Python and Perl because they're in the same family and I know more about their inner workings than anything else. That doesn't mean they're the only languages I've used or the only languages I think are worthwhile.

Yes, I picked on a lot of little things. It's the little things that _matter_. Every language (ahem, most) has function calls, data structures, and loops. What differentiates them is the little day-to-day stuff.

So what am I missing? What makes these design decisions _good_ , what makes PHP great? I've heard a lot of defenses and a lot of statistics, but not too many outright advantages. Most of your original response is just workarounds, not reasons why the behavior is good or even acceptable. The image I'm left with is that of an overgrown playground filled with active mines, but most of the mines have upturned buckets over them so you probably won't step on them, and that's supposed to make it a great place to send your kids. If even PHP's supporters can do no better than explain how to write passable PHP when I have a gun to my head, why would I want to use it?

<comment><USER42> > How are pass-by-value and pass-by-object distinguishable for immutable > values?

They aren't really. There's no real technical difference, just a terminology difference. All that you need to know is that whether it be Python, PHP, Java, or whatever that passing around scalars and objects works out the same.

> You said (array) as a cast is useful because a function can accept either a > single value or an array of values, and the (array) cast will produce an > array either way.

I never said anything about functions -- just that the cast itself is useful.

> because passing a single value that happens to be an object will cause the > function to cast it to an array of the object's contents, which will have > fascinating but useless results.

People cast objects to arrays in PHP _all the time_ because that can be a useful operation. I understand you point, but I don't really think it's too valid. If you're explicitly doing a cast, you should know what you're casting from. This is sound advice no matter what language you're using.

> strictly speaking Python isn't interpreted, whereas e.g. shell is.

It's an implementation detail that's not significant. The next version of bash should byte-code compile everything behind the scenes and run it (like PHP does) and it wouldn't make any difference. You could write an interpreter for C code (they exist) and it wouldn't change anything about C.

> Note that, for the same reason, you also can't chain calls like `foo()()`.

Honestly, there's no language grammar reason why that shouldn't work in PHP. It's just that parser sucks and they're very slow/careful to make changes to the parser. If it's a function name, a closure, or an object that supports being called they're called the same. If you can do $foo() then you should be able to do foo()(). The same is true about foo()[]. These things don't have to special-cased so much as the parser has to be modified to be more generally accepting.

> What language are you thinking of where there's a distinction made -- in the > parser, no less -- between a variable and an expression?

PHP makes no distinction between a variable and an expression (except as described above). It's make a distinction between scalars and objects.

> Sure, why not? Not that I was suggesting PHP direly needs scalar methods, > but if a number responds to strlen(), why not to ->strlen()?

Then there's _really_ no point in having scalars be objects. You could add syntactic sugar to make strlen($x) and $x->strlen() do exactly the same thing but what would be the point? I'd rather they do something more interesting with that ability. I think it's the only way they can successfully implement unicode.

> Leave the existing function totally broken. Create a new one with a > confusing and even longer name. Make everyone fix their code and remember to > use the new function in the future.

MySQL made this decision, not PHP. They just give you the library to use. Anyway, you seem to have a problem with the concept of backwards compatibility -- it generally does mean "continue to use this broken thing because you don't want to change your code".

> I'm hearing this a lot, but (as far as I can be trusted to say this) I don't > see it.

Someone tells you that you lack perspective and you don't see it -- so ironic! (I'm just being cheeky)

> I draw a lot of comparisons to Python and Perl because they're in the same > family and I know more about their inner workings than anything else. That > doesn't mean they're the only languages I've used or the only languages I > think are worthwhile.

Yes, but going off on public/protected/private as if it's a flaw in PHP because _you don't like them_ is not a valid critique. That's just one example but there are others. Even saying everything should be an object is more personal taste than anything else. I very much like "everything is an object" but it's not clear how best to implement that in PHP yet.

> It's the little things that matter. Every language (ahem, most) has function > calls, data structures, and loops. What differentiates them is the little > day-to-day stuff.

I disagree. I think I probably switch between languages a bit more than you do and the little things don't matter that much. What matters is the big things. Most of the stuff you mention in your article, if I encounter them at all, I don't even notice. It's such a non-issue that unless you bring it up, I wouldn't think to tell you. In fact, in some cases, I wasn't even sure what you were talking about because I don't encounter them (the lack of stack traces on errors, for example).

> I've heard a lot of defenses and a lot of statistics, but not too many > outright advantages.

Indeed. I'm not saying PHP has advantages over other platforms -- it has some -- but, in the end, the differences between any of the platforms aren't significant and mostly personal taste. I continue to code in PHP because I know PHP, I know the frameworks, and I have lots of existing PHP code. If I had to write Python or Ruby, I would. I'm going to be writing ASP.NET code for next 6 months.

I just think your article blows everything out of proportion. Much of it is "look how this crazy unreasonable code reacts in PHP". It's not invalid but it's not really indicative of developing in PHP. Similar lists have been made for JavaScript and yet that doesn't affect opinions too much. Similar lists have been made for C and C++ but everybody knows what they're getting into there.

Here we are talking about mysql_real_escape_string() and that's as legacy as you can get.

</comment></comment></comment></comment></comment></comment></comment><comment><USER93> Obviously we need to write a Python interpreter in PHP

</comment><comment><USER94> PHP is epic. Nuff said.

</comment><comment><USER55> >The best way to combat something as pervasively and institutionally awful as PHP is not to point out all its (many, many, many) faults, but to build compelling alternatives and make sure these alternatives are equally pervasive, as easy to set up and use as possible.

This is clearly not the case. The alternatives are already compelling. They are equal to or better than PHP in every single respect. Yet they are not as widespread. The idea that pointing out the flaws of PHP doesn't help is absolutely incorrect. Demonstrating the flaws of PHP, and the practical impact that has on producing useful software has been very successful for me in convincing PHP users to try something sane. I find only a very small minority of PHP programmers are actually unwilling to try anything else, most of them will give something else a shot if you simply demonstrate why it is in their best interests. Some people certainly get upset when you point out that they are using a bad tool due to ignorance of better tools, but most are able to get over themselves and realize the better tool will make their life easier.

The overall effect of convincing individuals to use better languages is that those alternatives do become as pervasive as PHP. How does someone say "I want the alternatives to be as pervasive as PHP" right after saying "stop trying to make the alternatives as pervasive as PHP" without realizing how ridiculous that is?</comment>