I'm a Facebook engineer who works on the HipHop compiler and HipHop virtual machine. It's in PHP, absolutely full stop.

It's amazing how much the fact that g++ is involved somewhere in the toolchain confuses people in this matter. C++ is just an intermediate representation; the source language really is warts-and-all PHP.

IIRC Facebook engineers must use HipHop for all their development, with PHP.net's php being now incompatible (hence the push to speed up the interpreter.) Wouldn't that make the language-supported-by-HipHop a PHP flavoured superset at the very least?

In the absence of a standard, saying what is and is not PHP is necessarily a practical matter: useful PHP implementations are those that run non-trivial PHP applications. HipHop qualifies.

FB's dependence on HipHop is because of backwards-compatible extensions to the language (like yield, e.g.). These extensions don't prevent HipHop from running normal PHP programs, though our use of them does prevent us from using Zend. The extensions are under flags that default off, if you don't want to use them.

eval does have one huge, honking problem though: it permits text to be interpreted as code. This is just asking for code injection attacks.

If you really need incremental/multi-stage evaluation, see MetaOCaml (http://www.metaocaml.org/) for the proper way to do it (without exposing yourself to injection vulnerabilities). It's a consequence of PHP's by-the-seat-of-your-pants approach to language design that the PHP devs settled for eval instead.

User input of code. It's hard to implement a REPL without it. Even if you do implement without it there's still an "exec" implementation hiding in there somewhere.

Also, on rare occasions, it is actually an optimization when used carefully, like the Python nametuple example mentioned nearby.

I'm just answering your challenge. I totally agree that in general it's a bad idea and that's an unusual case. While for it to work properly it has to ship with the interpreter, if I were designing a language I would move it out of the global namespace at least, and require some sort of explicit module import with lots of dire warnings in the documentation.

The problem with using eval for a REPL is that you want an interpreter, but eval gives you unprincipled incremental compilation.

Javascript (and I'm sure other languages) is moving in the right direction with sandboxed evals, but those are very difficult to get right in an imperative language, where a lot of code relies on global state (e.g. the DOM). Purely functional languages solve this problem well by disallowing side-effects. Of course there remain the issue of unconstrained resource usage but this is much easier to solve.

I use this in my Python data processing scripts. That is, when I generate data, I generate it as Python literals, either lists or dictionaries. When I have to process it, minimal parsing needed, I just eval it into my code.

  def parse_and_append(line, seq, str):
    if str in line:
        seq.append(eval(line[line.find(str) + len(str):]))

  nums = []
  mappings = {}
  for line in data_file:
    parse_and_append(line, nums, "nums: ")
    parse_and_append(line, mappings, "mappings: ")

Or a compiler at run-time.

If you write code in Java, but compile it to native format (using gcj, for instance) instead of using the JVM, is it still Java? In doing so, you lose what is probably the language's biggest selling feature.

Or, perhaps less relevant now, but I remember the days where people would go on about how Ruby didn't support native threads. Except there were interpreters that did use native threads with the exact same Ruby code. Was Ruby code running under one of those other interpreters still a Ruby application?

PHP too comes with expectations about the environment, like how it integrates into the web server stack, which if not met, is it still PHP? I'm not really familiar with HipHop, but, for instance, if you have to compile your code before deployment, you're not meeting one very prominent expectation of PHP: The ability to edit the code in-place on the live server (best practices notwithstanding).

So, what does define a language? Is a language just the syntax? Standard library APIs? Standard library behaviour (see Ruby example)? Runtime environment? I'm not sure you will find a generally accepted answer.

But the lines got very much blurred by the rise of scripting languages, in which - typically - the language was defined by the implementation. So for a few years there, it really was difficult to tell whether this was Python or CPython.

Fortunately, nearly all the languages to which this applies matured and got new implementations. Rubyists often to refer to the C ruby implementation as MRI (Matz' ruby interpreter), and there are lots of different Ruby implementations now. Python went out of its way to document behaviour which was specific to CPython, and put a lot of weight behind Unladen Swallow and Pypy.

But your Java example is bonkers. Compiling Java to native is still Java, its just not JVM. Compiling clojure to JVM is just JVM. The language feature is not the language. In Java's case, the language is specified, the VM is specified, the bytecode is specified. There really should be no ambiguity at all there.

Most people without a proper CS background mix the language with the implementation.

A language is defined by:

- syntax

- semantics

- libraries

Everything above can be made available as:

- bytecode interpreter

- text parser based interpreter (like the earlier BASICs)

- compiler

- JIT

That is why it is absurd to discuss language A vs language B in regard to implementations, because any language can have all types of implementations.

It is always a matter of cost/benefit which type of implementation is used as default for a given language.

Of course, I'll trust what an actual engineer from Facebook is saying over some article that I can't even cite. Is this not the case?

Well, you're the authority, but is that really a fair assessment? Has HipHop diverged from PHP enough to really still be considered PHP?

From the free dictionary:

poetic license n. The liberty taken by an artist or a writer in deviating from conventional form or fact to achieve a desired effect.

> empowered amateur

PHP is a gateway drug to web development. And that's awesome.

With almost every other popular web development language I've heard of[1], there's this grey area between "my app works on my local machine" and "my app works on the server" that is really hard to grok as a beginner. There's a reason entire businesses are built on the idea of making this easy.

With PHP? You get an apache box with PHP, you put the files up, and you're done.

For a professional web developer? PHP is probably nuts. I've purposefully left out things like PHP frameworks, setting up a database, or doing any sort've advanced web development. And yes, it is possible to create a large, successful, stable web app with PHP. It seems kind've hard given the legitimate criticism in the article.

But, honestly? Once you've started doing web development, you should be able to improve your own skills without the community pushing you. It's the people who are just starting out who need all the help they can get.

[1] Which isn't at all exhaustive. I'd love to hear about alternatives that are beginner-friendly.

Why? For PHP I sign up for one of the million LAMP ISPs, I upload a .php file with .php embedded in HTML and I'm done.

Where's the Ruby version of this? The Python version? The JavaScript version? The Perl version? THEY DON'T EXIST. You wanna use Perl or Python. You either have to use slow slow cgi or you have to RUN YOUR OWN SERVER. (virtually or otherwise)

PHP sucks, I hate it. I don't code in it unless I absolutely have to. But it's not the language that makes it popular. It's the combination of pre-installed + no setup + plus faster than cgi + works on a shared host + inline templating that's made it popular.

mod_perl? mod_python? As far as I understand them they're not useful on shared web servers so they don't fit the niche PHP is filling. Node? Ruby? They are the server rather than a plugin for apache. Again, not filling the same niche.

Someone with some chutzpah needs to step up and bring the EXACT SAME COMBINATION OF FEATURES except with a different language to the Web. They can be rich writing books and running conferences.

--

Ok, now, I suspect most would want this to be in Python or Ruby but I'd argue if you really want it to succeed make it JavaScript. Because most PHP programmers have to learn JavaScript as well for their webpages. Less to learn = more likely to succeed.

But honestly, if anyone could get any of those languages to fill the niche PHP is providing it would be a huge boon over today.

heroku ? you don't even have to upload anything manually, a single command deploys your app.

With PHP, you have a file with a .php file suffix on your server.

That file has code in it. Navigate to that file on your browser. You have a dynamic website.

No installation of external programs is necessary. No terminal. Often, you don't even need an FTP client, since you can use your hosting provider's GUI.

That blinding level of simplicity gets the non-programmer started in under an hour.

To run Heroku (on a Mac), you need to download (1.8GB) and install XCode (or another version of GCC for Mac, but the moment you say GCC, the beginner's eyes glaze over). Once you install XCode, you need to open up terminal (no GUI). Then you install homebrew in order to install the dependencies that Heroku tools require (some JSON libs, if I recall). Once that's installed, you need to install the heroku cli tools. Now you can deploy your heroku app, which requires registering (or, in the case of beginners, generating) ssh keys.

Every single one of those steps is too difficult for the beginner. That is why PHP wins.

The reason you have trouble deploying Python is purely that the hosts you are trying to use CHOOSE not to support it.

You can get really excellent, easy $10/mo Python hosting but if you ask for 'free,' beggars can't be choosers, so you will get whatever they feel like giving you. This is not a function of the underlying technology.

Don't blame other languages if you have not ever figured out how to do anything other than PHP

Well this is why I guess php wins. Because the other communities have complete disregard for what the common newbie considers valuable.

The question is whether something matches php's economic model. If the answer is no, its no.

You can get the hosting for $x/mo is not an answer nor a solution for most people.

Any recommendations? I need one for a small biz (in the US), so this is a serious question. I would pay 2-3x that much for a "really excellent" platform I could build a business site on without having to be the entire sys admin.)

If you need more reliability than shared hosting can give you, then you either head into the VPS/IaaS/dedicated space (and need to do your own sys admin stuff), or you head into the GAE/Heroku/PaaS space (and need to pay a lot more).

There are always tradeoffs. :) (And no, I have no reason to recommend them other than being a happy customer. <shameless>...unless you want to use my affiliate link[2] to sign up, of course.</shameless>)

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

[2]: http://www.webfaction.com?affiliate=chaos

http://www.masonhq.com/?AmazonDotCom

Also, PHP is not helpful in local development. I think there's a built-in runserver in the newest versions, but for all of history, to develop PHP you had to install (and set up) apache and all your required modules locally.

With python and Django, I use virtualenv+pip to get a consistent environment, manage.py runserver to test locally. I can pretty much start developing everywhere (my desktop, my VPS, my laptop, that same laptop after I reformat it and install some new distro to test) with 3 commands.

Only later did I install a local dev (now made very easy with MAMP), learn about version control, PEAR etc.

Something like, e.g., Heroku is awesome, yes, but not only do you need to learn how to debug a thing which you can't really touch in production, not only do you have to master the distinction between "the file I just edited here" and "the file on the remote machine"… but you have to use Git for that. I love Git, but years of watching PHP devs try to figure out Git have taught me just how intuitive it isn't.

Although PHP suffers from this, I'm not sure it is alone. I suffer a lot of pain setting up Ruby environments (I don't think I've ever managed it the same way twice) and getting everything to play nice. Even Python, a language I am about as familiar with as PHP, has it's annoyances on this front.

I suspect the difference is familiarity; I can deploy a working PHP environment in my sleep, because I've done it so many times.

The other day I had to set up Java/Tomcat - literally the worst experience of my life...

Also, PHP is not helpful in local development. I think there's a built-in runserver in the newest versions, but for all of history, to develop PHP you had to install (and set up) apache and all your required modules locally.

You're thinking like a seasoned pro :) For a newbie there is xampp - a familiar looking windows installer configures the Apache/PHP/MySQL (and others) stack, then it disappears into the backround and, largely, can be forgotten.

This is huge for a new developer.

Think about it this way; if you had a class called "Learn to Write Websites", for absolute beginners, I argue PHP is a good initial choice. Because you don't have to worry about the environment, how to server it, command line, package management - which, say, Ruby would require. You just chuck in a brief overview of how servers work in general, and then get them working on some PHP scripts, with instant results.

I love this!

I like Ruby, of course - it's powerful, has modern standards, and Rails is brilliant. But for a beginner, and even moderate, developer it is a bit of a pain to work with.

With python and Django, I use virtualenv+pip to get a consistent environment, manage.py runserver to test locally. I can pretty much start developing everywhere (my desktop, my VPS, my laptop, that same laptop after I reformat it and install some new distro to test) with 3 commands.

This sort of thing (http://pypi.python.org/pypi/virtualenv) is non-trivial for a beginner.

I'm not trying to defend PHP too much here; I like it, but it is a horrible language on many levels (as are other languages).

It also just works, especially for beginners.

I'd consider myself a seasoned PHP dev and it always takes me a few hours to figure out what happened when I get the white screen of death.

XAMPP isn't any sort of solution to this, because not all servers are configured in the same way that XAMPP is (and the fact that they compile in most packages doesn't help).

Developers at a local makerspace did a project last year using PHP, and even though there were tons of very smart guys, mostly everybody we brought onto the project took a whole afternoon to get set up. To me that's unacceptable.

Understanding how to set up virtualenv isn't trivial for a beginner, but that doesn't stop a beginner from jumping into my python projects with no pain. All they need is to get easy_install (which is included in all distros I've seen) and do a git/hg pull (both probably also available from distro). The rest can be handled by a shell script in the repo that grabs pip+virtualenvwrapper, sets up the virtualenv and installs all the required packages. Then you tell them "if you need to work on this project, just type `workon projectname`", and with that they're ready to start hacking.

That's precisely my point! :)

and even though there were tons of very smart guys, mostly everybody we brought onto the project took a whole afternoon to get set up. To me that's unacceptable.

As mentioned, I can rattle out a PHP environment in minimal time (basically as long as it takes for the installers to run). But task me to work on a Python project, or Rails, it will take a lot longer.

I think my larger point was that for an absolute beginner PHP offers some key advantages over other languages (even you simple description of jumping into Python involves some major pain points - like using Linux, the command line, package management, what is git/hg?).

The advantage to PHP is purely that it is intended as a web language; Python, Ruby et al require additional steps to get to that stage (or, at least, steps that are not braindead-automated for beginners).

I started writing a long rant which essentially boiled down to exactly that - PHP may be shit, but so is everything else. I hate all the languages that we're stuck with, and every time I start a project it's more a matter of picking the least shittily inadequate tool for the job than a matter of picking a language that I actually like, because there are none. They quite seriously all suck, very badly in most cases. The pain comes in different places, in varying degrees, but it's always there, whether it's coding pain, tools pain, ops pain, installation pain, documentation pain, etc. I have yet to find a development stack that didn't make me want to scream "fuck!" at least a dozen times over the course of a week of using it.

The real problem with most non-PHP stacks is that they front-load that pain: I have to say "fuck!" and hit Google many more times before I see a page generated from Ruby, Python, Scala, C, Java, or Haskell running on my webserver than I do to see a dynamic PHP page. Is it any surprise people tend to go with PHP pretty often, given that?

I think detractors would be wise to focus a little bit more about what's awesome about PHP, rather than what sucks about it (there's a lot, nobody argues otherwise). Because there's got to be plenty that's great about the language (or perhaps the environment overall) if it attracts people in such large numbers. We should be trying to add that to other languages/environments, not merely looking down on the newbs that still use PHP.

While the beginner will love being able to open up an FTP client (probably one that's a browser extension) to upload a few files they've changed, that's not going to fly for us.

We want proper deployment, source control, and for it to be used properly. We don't want to go anywhere near patching code directly on the live server. Just make sure the fixes are committed, nothing's broken, and run the deployment script of choice.

The requirements for 'simplicity' are completely different. And it's for this reason I think Rails and Django* and the like become attractive prospects for developers who want a more reliable, consistent environment.

* I'd struggle to list a PHP framework here because each one has a different vision of what the 'PHP way' is, probably because there is no 'PHP way'.

Keep your source in a svn or git repo, export the new release branch or bug fix release to a testing box and once you're happy move it over to production. What does any of that have to do with PHP itself?

If you're talking about moving from one version of PHP to another, just compile the new version of php in a different directory from the old version (e.g. /var/lib/php/5.4 ), create a new virtual server definition in apache and point it to the newly compiled php version (e.g. using Apache's mod_fcgid) and test your site. Once you're happy, make that virtual server live to the public and retire the older one.

Even those that do run their own server many linux installations have options to install the AMP part of LAMP by default. Again, nothing to do

I worked at one place where our hardware guy who wanted the dev test and live systems to come from the same production batch from SUN just to make sure there where no strange MB rev problems.

Ok having identical hardware is high end but seting up a system where your running the same linux distribution an the same version of mysql php etc is not exactly rocket science.

Unsurprisingly, most PHP applications end up in this state. Cf. http://web.nvd.nist.gov/view/vuln/search-results?query=phpbb... - and phpbb is one of the popular ones with an active community...

The current state of information security: basically, we're screwed.

http://www.google.com/search?q=php+mysql

Searching for PHP and MySQL yields tons of tutorials, code examples, and documentation related to the now-deprecated mysql interface. When I wrote my first comprehensive PHP application last year I spent half a day trying to determine best practices before finally settling on PDO. Newbies won't go through that effort, and will naively land on mysql rather than PDO or mysqli as likely as not.

PHP has been around forever and Google has a long memory. Unfortunately, for every good blog post/tutorial on PHP development there are 100 or more bad or out of date ones.

Also, if you've reached the point where PDO is too restrictive for what you want to do, you should be knowledgeable enough to write your own db class that incorporates sql injection protection (since all that largely consists of is escaping strings).

As was pointed out by djmdjm below, there are Real Consequences when amateur hour overflows into the real world. In many cases it simply would be better had many of these apps not been made by the unskilled - even if that means they hadn't been made at all.

What's so wrong about a barrier to entry that is effective against those who have not yet figured out what the fuck they are doing? We learned despite such barriers, did we not?

But most of the world will tell you where to stick that certification and will cheerfully walk around your "barrier to entry". Then they will hack together a web page using whatever programmers and tools they can find, certified or not, because web pages are very important in the twenty-first century and even the lousiest, slowest, buggiest PHP site is often more valuable than a paper sign stuck on the wall, an entry in the Yellow Pages that nobody reads anymore, a bunch of people sending individual text messages to friends-of-friends, or a static web page from 1997 with a little animated GIF on it.

I wonder what the costs of, say, the Gawker password database breach were? Or perhaps the Sony DRM rootkit on CDs? (Or Apples unpatched Java bug?)

What if the people who wrote and/or deployed the code knew (before they shipped/installed it) that they were going to be held responsible for the costs of any future failures? My guess is we'd then have training and certification and insurance, and professional organisations rising up to certify people as being skilled enough to qualify for insurance for themselves and/or their companies. Much like "Engineers" (who's titles the software industry loves to assume) or "Pilots".

I can torture the "Pilots" analogy further - much like you can do very little training to get a car license, perhaps you'd be allowed to write software that affects only a few people at once, your family and friends, perhaps a colleague or two, even occasionally a stranger, but never more than 6 or 7 other people at once. If you want to store data for more than 6 or 7 people, you need a different class of license - a mini bus license for a dozen or two, then a full bus license, then a train or passenger jet license...

Who _should_ be held responsible for a website's password database getting compromised? At what stage in the progression from "shared GoDaddy hosted out-of-date-wordpress blog about my cat" to "Gawker network with a million or so login credentials inadequately secured" do we draw the line and say "Here is the line in the sand across which more care needs to be taken, and lines of responsibility drawn up and accepted"?

'Cause _surely_ there _should_ be that line somewhere, right?

We are not good at this.

With PHP, you have to develop a coding style that naturally avoids PHP's weird areas. It's not really that hard to avoid the mines, but you do have to be aware of them.

In exchange, you get a scalable web server and a language that requires minimal babysitting. Instead of automatically throwing a 500 on a random, unimportant, uncaught exception, PHP makes a best effort, and most of the time the result is fine. 99% of the time, this is better behavior from a user's perspective as long as functioning perfectly isn't mission critical. It may feel offensive to your OCD programmer nature, but from a pragmatic engineer's standpoint, it's oftentimes a better choice, especially when dealing with the dirty data that's so common in webapps. Do not use PHP in a banking setting.

Compared to running a rails app, administering and scaling mod_php is pleasantly hassle-free. A single webserver with a modest amount of memory can handle an large number of concurrent PHP processes and requests without needing to resort to reverse proxies or anything more exotic than a simple apache install. That's nice not only for the ease of setup, but also because it means fewer moving parts, and less maintenance. That's a very real plus, and I'd say that the shared-nothing architecture of PHP was great engineering choice.

Yes, the language is weirdly architected and oftentimes inconsistent. It can also be extremely productive, and many of its weird choices are extremely pragmatic. The security holes are pretty horrifying, though - the defaults should be much more locked down, and I've always been a bit mystified that they're not.

And how precisely does PHP "know" which exceptions are important and which are not? In my experience of 6 years as a web developer, the faster and the more explicitly something fails the better. If the user gets a 500, that's a pretty clear sign of a problem, I get an email notification about it, including user id, session data etc. Then, in most cases, I can easily see what the problem was, decide what the correct behaviour is and create a fix immediately and even notify the user after releasing it if I wish to do it. If there is no exception there is a case in the code I was not aware of when writing it and it will still not be brought to my attention. In the best case, the user will report some problem with the functionality and I will have to spends hours trying to find the logs for this user and reproduce the problem, which will now be much harder, quite some time could have passed since the error, the database entries for the user could have change meanwhile (including corruption caused by the system continuing to operate despite an error) and so on. In the worst case, the bug will continue to affect users (which might not even know what the intended behaviour was) and I will learn about it a year from now, accidentally.

Reproducing bugs is hard enough in web applications due to their distributed nature, some of the applications I worked on had serious business-affecting bugs that went unnoticed for months and failure to clearly signal errors is one of the common cases. It doesn't matter whether you are in banking or just building another social CMS/CRM "kind of thing", if you have bugs you loose users and with them money.

See also: http://en.wikipedia.org/wiki/Fail-fast

If there's an issue that affects business logic I'd like my app to display "Sorry, something blew up. Please leave a message and we'll get back to you." instead of chugging along quietly. If the error is not critical (some external feed gone, whatever) _I_ as a developer can decide to catch the error and handle, log or even ignore it. But it's not PHP that can decide to do so.

I completely agree with most everything in this post, too. It can all be summarized in this sentence later down the page:

> PHP is a minefield.

You can measure a language's design by how often you shake your head at something. I've run in to pretty much every problem he outlines in the Operators section alone. Too often, a problem I'm having is due to a quirk in the language itself and not in my logic. Too often, I find myself needing to check the docs to see which order I need to supply arguments to core functions.

It's hard to imagine the pain of working in PHP without working in it. All those little things you take for granted in Python, Lisp, Ruby, etc. are gone. The only consistent thing about PHP is its inconsistence.

If you don't mind, I'd like to save this for future reference when someone tells me, "PHP isn't that bad." Yes, as others have said, it was beating a dead horse, but we shouldn't forget just how bad a language can be and still become wildly popular.

"I wrote PHP as a hammer to do my stuff. Around 1993, the only way to write web apps was by hacking C and Perl. This was extremely painful, and you would have to do the same thing over and over again. So I started writing a tool which would make my work easier."

"I never thought while writing PHP that someday millions of people will be looking over my shoulder into my code. If I would have known that, I would have surely done a few things differently. But nobody knows that. Some appreciate the language, some don't. I don't blame them."

"PHP is a hammer. Use it for the right purpose at right place. Learn Python, Ruby, Haskell, Scala, etc. every language and use them where they fit. No language is perfect. There are trade-offs involved in each of them."

"When anything is too popular, criticism naturally follows. When people compare a language which is used in, say, 35% of the web apps to a language which is used in, say, 5%, their comparison is highly skewed because then they directly compare the number of things that have gone wrong in one with respect to another. They don't scale them to the same level and then see the faults. I don't blame anyone for that."

"You can scale horizontally with PHP as much as you want. There are many companies doing that, and they have been very successful."

"I can teach a semi-intelligent monkey to code in PHP in three hours."

There were many other cool and brilliant things he pointed out. What I learnt: Accept what it is. If you don't like it for your purpose, use another language which fits in.

P.S. In the new release of PHP, there are even driven servers (libevent), Support Vector Machine (SVM), Traits, Instance Method Call, built-in web server for testing, improved error messages, broad performance improvements, and many others. This language is not going to go away soon.

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.” ― Bjarne Stroustrup, The C++ Programming Language: Special Edition

I wish people spent as much time creating new things as they did bitching. As well written as this article is, it contains absolutely nothing that hasn't been said ten thousand times already- in fact, most of this seems to be regurgitated from those other articles rather than being actual original thought. Some of the issues brought up have been depreciated and removed a long time ago- too bad the author didn't limit his google search to the last year when looking for other people's examples to post.

2. It's symptomatic of a general "good enough" mentality that makes software development much more difficult than it needs to be.

3. It breeds bad habits in novice developers that are likely to be my colleagues one day.

4. It steals mindshare and time that might much better be spent improving better alternatives.

5. It provides LAMP detractors with ammunition to shoot at the entire open source web stack.

6. I may one day have a half-assed PHP mess dumped in my lap to clean up.

Like I said, I wrote it to get this /out/ of my system; I am now impervious to PHP arguments. Either this will convince someone or it will not. Done.

What I'm saying is disregard that guy.

Well done. Nice to get it out.

This is not a language, where you expect intuitively on what method to call unless you do a StackOverFlow search on existing problems, raised by others like me.

Yet, I currently develop a web app on PHP. Certainly, I can't wait to move over to Ruby or other languages in my next project.

The author is stating the obvious. But he/she has every right to do so, because PHP is simply not user friendly enough to programmer. If PHP truly targets non-programmer, they totally succeed in their goal.

The point is the PHP circle jerk is getting old. I don't see the value in repeating the same discussions every day, and most of these posts just reek of exploitation- these authors know php bashing will get upvoted, so they write an article, submit it here, and wait for the traffic to pour into their otherwise unknown blog. I just think we'd all be better off if they actually wrote something useful.

Actually, I would state that, "a summary of the same posts we see here week after week," does indeed have value. Now you can bludgeon the next guy who posts a PHP rant with a link to this one.

I was once talking to our Systems people about, why not allow Python applications. They said that every time they have experimented with allowing CGI scripts in any language supported by their Web servers, someone has always found a way to exploit their sandbox. With PHP, the applications can still get exploited, but they have never had a breach that affects the servers themselves.

So if you're a startup or a major tech company who can spend time customizing a Web server and trust everyone who has access to it, then you're crazy for using PHP. But if you're a college with 8,000 students, almost 1,000 faculty, and a bunch of support staff in addition, and a good quarter of them need Web sites, PHP's pretty much the only option that will keep you sane.

In my opinion, that's something that seriously needs fixing. But it's certainly an explanation for why PHP is still around now.

(I also haven't seen any Joomla installs.)

If I could get away with it, I'd never again trust my credit card number to a system based on PHP, but I suspect that that's about as easy as never trusting your credit card to an ATM/point-of-sale machine based on Windows.

http://www.0php.com/php_easter_egg.php

Would you visit a dentist that used tools as bad as PHP? "Hey, it's not about the tools," they'd scream while you're running away.

1. http://www.php.net/manual/en/ini.core.php#ini.expose-php

Sometimes we can't forget that it exists, so we try to educate people so that with a little luck, they won't pick PHP for their next project.

I don't really have a choice. I can't afford to move (no, seriously, I can't), and there is no other work that I'm able to do.

I dislike PHP. I wish my boss would let me explore alternatives. :(

He just won't let me.

No offense, but you should really find the time to learn. That's not a hit against PHP (which I don't care much about one way or another; anything good enough for Facebook but full of such a large number of gotchas can obviously be read either way) and it's not even a comment about the marketability of your particular skill set.

Instead, it's just intended as a friendly reminder that you, not your boss, are in charge of your life. :)

It's not that I don't know how to do other things. It's that the things that I'm capable of doing put me in a narrow niche. With a long-standing back injury and medical problems resulting from exposure to chemical allergens, there's very little work I can do in the light industrial sector.

I have training as a carpenter (and I can do everything from foundation and framing to roofing and finishing - I have the training), but I'm no longer physically able to do it.

The list of programming environments I'm comfortable in is quite long, too. It's just that my choices are PHP, C#, and Ruby. And the PHP guys are the only ones hiring. I really should move to Seattle or something, but the cost of just getting there is a little over what I can do.

I've attempted to learn Ruby. I know C++/C#/Java/Objective C. Yet I still come back to PHP. I can't explain it. I like PHP. I understand PHP. There are nice people willing to help me with PHP. PHP does what I ask.

It's not the greatest. It's no MIT Graduate. But I like working with it. PHP works hard and fast, plus it's a little fun.

I feel there is more important stuff for me to do with my life than worry about the structure of a common language.

I don't know, if anyone can help me understand my attraction it would be most appreciated.

You should give Ruby or Python a shot as an alternative. C# comes with all the .Net baggage, it's a whole different game, and Java is far too enterprise for someone living in PHP-land.

There are things that are stupidly easy to do in Ruby and Python that are virtually impossible to do in PHP, and these are things you do all the time. PHP's feeble list transformation routines, which are a fundamental operation in even Perl, are a huge problem.

If you think PHP is fun, you would love a well designed language.

I've never done any sort of web development at all (no HTML, CSS, JavaScript, etc.), but I set up a local Django server to do stuff with, and I absolutely love it. I learned Pyton for web development, but I can really see it coming a part of my future projects.

PHP isn't sexy, hell, it might be classified as a backwater these days. Fact is, it is a simple language, it works, and a whole lot of useful tools are built on top of it. I've done many bad things with PHP, some I will admit to, some I won't. Hell, I built a bunch of authentication services and prototyped a storage backup system using PHP because it was the most mature language at the time (this was years ago, and mod_php was light years ahead of mod_python, ruby wasn't even in the discussion). It worked, the security issues were known, and we knew how to scale the system.

The first post on http://anodejs.org a couple of weeks ago was pretty amazing. The title "We work at Microsoft and we use node.js". That statement in itself was amazing (you wouldn't have seen that 5+ years ago), but the use of Javascript in a large company/large team environment is an interesting exercise. My experience is that a team of 4-6 people working in the Javascript/Node server side have to put tools in place to ensure code quality and consistency that was never needed in PHP.

Each language has it's strengths and weaknesses. In the case of PHP, it isn't sexy, it is pretty homely, but a lot of people are still getting a lot of stuff built using it.

If you look behind each one of the features you will find that they aren't 'design decisions' but rather a consequence of circumstance.

Most of what is being discussed in this post doesn't really matter because:

a) most PHP developers will never touch some of the smaller nuances

b) newer versions of PHP are changing things (and people still keep using older version. there was an entire holdout movement with version 4). this entire post could have been pulled from the PHP issue tracker.

c) super duper huge websites and web applications are being built with PHP

I don't consider myself a PHP developer, but the argument about it being useless in spite of all the evidence is just ridiculous.

Really, PHP is excellent for what it was originally designed for: little server-side scripts that do relatively simple things. I know that its authors would currently like it to be used for more than that, but, well, don't.

As long as you're not making a massive application, PHP's massively filled global scope, decent batteries-included approach, documentation-with-examples, and its support on virtually every web host (and then some) make it an excellent choice.

Therefore, I disagree with the author's notion that it's bad for everything. It's excellent for little scripts, which is was mr Lerdorf originally intended it to be for anyway.

I tried writing a little one-off Python thing in Flask last year and was actually surprised by how little effort it took. I spent more time learning Flask (and Flask is really, really simple) than I did actually deploying the thing to a VPS with spare cycles. It could stand to be slightly more turnkey, but running a tiny app server isn't nearly the nightmare it's made out to be.

…no template system. There’s PHP itself, but nothing that acts as a big interpolator rather than a program.

As if that was a bug and not a feature. PHP succeeds because there is one PHP templating syntax and it is called "PHP".

PHP started life as a templating language, and that's where its soul lies. Which is important, because if a non-programmer wants to start editing dynamic HTML pages, most likely the first thing they open in their text editor will be a template. And if a customer wants to change the website, but doesn't want to pay a highly-trained programmer (we're very expensive, especially because none of us really wants to be paid to edit templates all day), they'll hire someone who knows how to edit the theme. For every seasoned programmer in the world, there are half a dozen themers who know how to edit HTML and CSS, and maybe how to embed a "foreach" loop that calls a stock WordPress function, or edit an argument list, or swap one Drupal function name for another. And for every themer there's a dozen non-programmers who dream of knowing enough to be themers.

This class of user is what every other platform tends to neglect. Ruby and Python programmers tend to design tools that are intuitive to other programmers. We build "frameworks", where one must tinker and monkey-patch and fork to such a degree that only another programmer can download and assemble a working system, let alone customize it. (One word: Gemfiles.) We write programmer-centric documentation filled with jargon terms from Javaschool, like "object". (PHP themers often do not understand OO, and often don't need to. This, all by itself, could be why PHP is so popular.) But one leaves a lot of money on the table when one designs software systems exclusively for users whose programming education entitles them to six-figure salaries. There aren't enough such people on earth; that's why they earn six-figure salaries.

Designing the minimum viable product for borderline-non-programmers who want to tinker with dynamic web pages is hard work, though. PHP evolved into that niche, but if you don't start there it's hard to steer there deliberately. For me, trying to remember when object inheritance and version control and function definitions were mysterious is like trying to remember when I didn't understand algebra. (And, believe me, I really didn't understand, once. But I'll be damned if I can remember why not.) It's so hard to keep one's eye on that ball that even the PHP developers lost the plot long ago: PHP has long since bulked up with features borrowed from other languages. But if you ignore its newer features the soul of PHP is still a little templating language that you can edit into the HTML on your server; change a filename extension and reload and you're good to go. And, the thing is: You can write a crazy-complicated core system in PHP, but then expose it as an API at the template layer, and those tinkerers hacking at the HTML on their servers will be able to use it.

Is there something about consistent naming, or consistent behavior of different library functions, or consistent syntax and operators -- they can be lenient and type-coercing, but consistent, like Javascript's -- that would make it a worse language for people to wade into in the form of templated HTML? Of course not. That's what irritates people, the endless parade of bad design decisions that appear totally bad, with no upside, where they could have just as easily made a good decision and didn't.

But these irritations are only apparent once you're inside the PHP conversion funnel. And, as I have observed time and again as a pro PHP developer, once a PHP programmer knows ten lines worth of PHP it is easier for them to struggle through the eleventh line than to start over with another system.

The entrance to the funnel matters, a lot! Everyone passes through it, and the bulk of your user base will never even leave it. That's my theory of PHP's apparently inexplicable success. (It also explains a lot about every other platform's userbase, by the way.)

And it's not as if one can't master PHP to the point that one could build, say, Facebook: It's empirically evident that one can build Facebook, WordPress, and Drupal in PHP. And, though PHP eventually turns into one gotcha after another - almost immediately, actually; the array() semantics are an absolute horror show - at every single step of the PHP experience there are ten people stuck on that step along with you, and you're all being coaxed ahead live, on the internet by the ten people who are stuck one step above you. So it eventually works out, at least as well as any good hack does, and trying to pretend otherwise doesn't fool anyone. You can try to tell people that PHP can't possibly fly, like the scientists in the urban legend who allegedly tried to claim that the bumblebee can't fly, and they'll smile at you and go back to struggling with PHP.

The question implicit in your comment is: Could we design a system that offers the ease of accessibility of the first few steps of a PHP programmer's career but, as one climbs the learning curve, eventually blossoms into Python or Ruby or even Lisp? I wish I knew. My best guess as of this morning is that a demigod could design such a system, but it's very difficult for mortal humans to do so, because once you know how to program it's hard to avoid overdesigning, putting in things that will eventually be useful in year two but are discouraging in year zero. We make terrible pedagogical mistakes, like turning everything into an object. (Does your ORM seem intuitive to you? That is why PHP is beating your system in the marketplace.)

For years I consoled myself by calling myself a "Drupal developer". I'm not a PHP developer; if I weren't using Drupal I wouldn't touch the language with a ten-foot pole.

But I agree that basic PHP is optimized for the style of web development that dates back to 1996: Server-side rendering of HTML templates. (More powerful PHP - the underpinnings of the PHP frameworks, the stuff one gets in the latest versions like objects and namespaces and closures - basically turns the language into the equivalent of every other scripting language, though obviously much more inconsistent; there's no great reason to choose any of that over Python or Ruby except that it degrades gracefully to PHP, which may actually be very important, but only so long as what you're building looks superficially like a server-side-rendered HTML template from 1996.)

One reason why I'm spilling 10,000 words on PHP is that I've been working with it for five years now, but I'm having trouble getting excited by its future. It has a long future, because 1996-style web sites are not going anywhere: WordPress.com has a zillion users and Drupal is taking over the enterprise and, well, Facebook. But one eventually gets tired of living in 1996. And PHP is useless for client-side-rendered "HTML 5" views, or mobile app client development, and its advantages as a templating language become moot if your server-side code is just an API coughing out JSON objects RESTfully. No newb can figure out that stuff today - even wizards can't agree on the proper semantics of REST, for example - and if ever we do develop a framework for designing RESTful APIs that's as easy for novice programmers to pick up as PHP is for 1996-style templating, I'm betting that framework won't be built in PHP.

But maybe I'm wrong. Hence, deep thought.

My experience running PHP cloud services suggests that, operationally, PHP is a dream. It's the least problematic layer of the LAMP stack, at least once you've learned what the words "APC cache" mean.

Given my past experience I was planning to use PHP as it is the only language I have any experience with and while the functionality I'm shooting for is totally different, I don't envision it being any more difficult to code than the blogging platform. I will be interacting with a database.

Are the other options as easy to pick up as PHP? Is it as easy to google for help?

Of course, that was my impression given my prior knowledge, which of course influenced my start with that environment. But i found it to be great almost instantly.

[set Greenspun Cynicism Level to MEDIUM HOT]

Other platforms wrap up SQL to the extent that you are encouraged to pretend it does not exist. This is an irreplaceable killer feature if you are trying to encourage new programmers to design things that will eventually prove difficult for them to optimize, or are trying to drum up membership in the NoSQL-silver-bullet-of-the-month club, but in the end what was good for 1996 is still pretty good for 2012: Pull the data from the database using classic SQL from the 1970s, loop through the result set, paste each row into the template, and ship it out to Apache.

PHP does this transparently, which makes it relatively easy to figure out what is going on. Of course, what is going on may be "the novice PHP programmer is staring directly at the SQL but still cannot optimize it", but hey, at least now you can see the problem.

[set Greenspun Cynicism Level to LOW]

How are any of these not fit for building an MVP in 2012?

http://silex.sensiolabs.org/ http://twig.sensiolabs.org https://github.com/nrk/predis

There are also modern libraries for a plethora of other RDBMS and NoSQL systems (I think PHP is even going to support mongodb natively soon i.e. no third party client library required).

But PHP has either missing or NOTORIOUSLY inferior Memcached/Redis/Mongo/Cassandra/HBase/Riak/etc clients. They get the job done, but they underperform, say, Python or Java versions in benchmarks and introduce far more bugs and quirks than I've experienced in other languages.

This has actually been a positive thing, because when you're using these data stores/queues/etc at scale and you need bulletproof client libraries, you naturally are led to a SOA. You end up with Python/Erlang/Clojure/Java services that interact with the datastore, that you consume from PHP using Thrift et al.

But being so bad that it pushes you into building a better architecture is kinda a preverse benefit

Having said all of that, if you are building a site that uses NoSQL and needs to scale to millions of simultaneous hits you'd be insane not to develop it with SOA in mind. Using just PHP (or any other single language) wouldn't make sense.

But Memcached, certainly (and even doubly so for the `Memcache` extension that ill-informed developers install instead of the better `Memcached`), and the others listed, either are slower/etc or just don't exist.

Yes, you can enjoy these wonderful modern tools for PHP at home meanwhile you suffer with old-tier libraries at work because everyone refuses to move forward.

I contend that learning a proper language will be of greater benefit to a person just starting web-development, and putting in just a few extra hours at the beginning to get a solid foundation will in fact save them time in the long-run.

Also, giving complete amateurs this loaded, rusty .44 magnum and pointing them at the battlefield is bad for web security and the web in general, they will inevitably lose all the plaintext usernames and passwords they have in their database.

PHP is a blight on the web.

Now you have two options. One is to learn the entirety of automobile engineering before touching your car, second is to learn enough fix the problem for the moment. Needless to say any normal person will prefer the second approach.

Now some mechanical engineer may make an argument that this small quick fixes are harmful for long term mechanical engineering practices. But for the guy who does this quick fixes, none of this matters or is even relevant.

Also, the tires are likely to explode every 16 left turns unless you know about the secret tire fixing button under the dash.

It is true that PHP may save people a few hours in the beginning, but at what expense? How longer does it really take to get a noob running a Sinatra, web.py, dancer or something similar?

http://djangobook.com/

Some people doesn't want to learn web programming. They want to get things done. Think of PHP as an equivalent of Bootstrap on the server side. People don't use Bootstrap because it's beautiful but because they can't design and in fact don't need anything fancier.

There really needs to be a "good" version of PHP.

http://pastie.org/3761953

This article is garbage -- don't be taken by it.

I'm not going to argue that PHP is a great language, but this article is a complete disservice to anyone who has bothered to read it.

I could complain about PHP all day but at least I know what I'm talking about!

The "non-programmers" remark refers to a quote from the PHP 2.0 documentation. I tried to minimize the editorializing.

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

> == is useless.

Actually, it's not useless. It does have a few stupid edge-cases and I will admit that. But in most common cases actually does the right thing and the truth table isn't too different from JavaScript.

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

I just discovered this recently and it's a great feature. Obviously an attempt to use the reference will result in a notice but isset() and empty() operate it on it correctly. This can be very handy.

> 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; I'm not sure what kind of module system you think it needs. Most projects don't use include() directly and instead have autoloaders.

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

You state this like it's a bad 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.

Yup. I find it very useful on 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. How is this different from any other language?

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

Then you go on to be 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.

> 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. You could that 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.

I am unsure where you got this idea from. 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 you take 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 this out. I thought the solution provides was actually a rather simple way of resolving the problem.

> clone is an operator?!

Of course! Why wouldn't it be.

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

> 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. A non-static call can be made that way and passed on $this. This can be useful and isn't terribly confusing -- similar syntax as calling parent methods.

> 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

PHP classes are basically statically compiled. The class code isn't run, it's compiled into byte code before the execution of the script. This is similar to if you just ran the Java compiler on Java code before each run. It's a design decision that has it's pros and cons.

> 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

Again this is the definition of a static variable in any language!

> 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. Of course, this entire API is pretty much depreciated with both the mysqli library and PDO.

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

How would you expect that to work?

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

Unless you use a code cache like APC. It will eventually be built in but an easily added option. I suspect most people, however, 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. Why would PHP be any different.

> Insecure-by-default

Only if you're using an ancient version. Some of these things are now removed from the language after being depreciated for years.

I'm actually getting a bit tired so I'm going to bed. I didn't comment on everything in the article: some of them are right. But some of them are just different. Some of them have even been replaced by newer methods of doing things.

PHP has been around for a long time -- I remember when I switched from Classic ASP (yes, VBScript) to PHP and it was a dream. Many of things to complain about now, like the kitchen-sink standard library, were a godsend. It also evolved very quickly during that time and I suspect if it hadn't then it wouldn't have caught on enough to be bitched about now.

For the most part you've defended PHP's behavior as design decisions or offered workarounds. Workarounds just demonstrate that the language is Turing-complete. Design decisions are only okay if they actually make a useful tradeoff; these generally do not.

I can give you individual responses if you really want, but I suspect you won't be swayed no matter what I say. I will comment:

PHP doesn't need a module system? What? Once your program consists of more than two files, you're going to want to import stuff from one into the other in a structured manner.

But a few things are weird to you but not some objective view of weird. Many of your points I didn't comment on are not unique to PHP at all (such as octal numbers)

> For the most part you've defended PHP's behavior as design decisions or offered workarounds.

You could say that unifying PHP error codes and exceptions is a "workaround" but the language provides specific support for it (The ErrorException class) so it's pretty much a standard pattern. The end developer has the choice of development style.

> PHP doesn't need a module system? What?

I have projects with thousands of files -- as someone else said, Namespaces and Autoloaders covers this.

Also you should check out what Alan Storm has to say about this: http://alanstorm.com/python_imports_for_php_developers

Mr. Storm is a crackerjack PHP developer: perhaps you will listen to him.

PHP does things differently; you don't import things before you use them -- PHP loads modules/classes as necessary when they're used. If you don't use a class, it's not loaded.

Other features of PHP make things like "import *" impossible (or at least very expensive) but at the same time it's also much less necessary.

PHP has a module system: Namespaces and the class autoloader.

> Because of the @, the warning about the non-existent file won’t be printed.

So your complaint is that when you use @ to suppress an error it... suppresses the error?

> The language is full of global and implicit state.

"Global" is one of those dogmatic points. Nothing is truly "global" in PHP. The "global" in PHP just means it is request-scoped (ignoring $_SESSION, which is explicit anyway).

Do people complain about request-scoped data in any other language? No. The PHP haters just decide to hate this largely due to the (somewhat incorrect) label of "global".

> There is no threading support whatsoever.

That's a good thing. It forces you to use async HTTP programming or something like beanstalk, both of which are better than the complexity of threading.

> array_search, strpos, and similar functions return 0 if they find the needle at position zero, but false if they don’t find it at all.

So, it's a problem that array_search returns 0 when something is at... position 0? And returning false is just a sentinel value, much like functions in other languages might return -1. So what?

> In, say, Python, the equivalent .index methods will raise an exception if the item isn’t found.

I, for one, hate throwing an exception when an item isn't found. This sucks:

    try:
      index = a_list.index(a_value)
    except ValueError:
      # do something

Yes, you have to use --- and basically understand that otherwise 0 == false. So what? In C/C++ you also have to remember to use == not -.

> [] cannot slice; it only retrieves individual elements.

Much like Java/C/C++. PHP has array_slice() if you want it.

It's since been redacted but the OP originally claimed that Facebook doesn't really use PHP (because, hey, that fits his world view).

Look, I could go on but really what's the point? Haters gonna hate.

Sure it would've been nice if PHP had been consistent with, say, parameter ordering (needle, haystack vs haystack, needle) and function naming (sometimes using underscore, sometimes not) but really none of that matters. If you use it, you soon remember. Humans are built to understand inconsistent languages. If we weren't, we wouldn't be able to speak to each other.

Some like to argue that PHP is a beginner's language. I disagree. I think PHP is a fine language for just throwing something together... if you know what you're doing. Otherwise it's just a recipe for SQL injection and XSS vulnerabilities.

A common mistake with PHP is people try and turn it into Java with complicated object frameworks. There is typically lots of hand-wringing about OO'ness.

The procedural style is actually very natural for serving HTTP requests. The core of PHP is a stateless core of API functions. This is incredibly useful for keeping resource usage down. Much like the old CGI model, the entire environment is created, used and destroyed on each request.

This is a feature not a problem. Anyone who has done Java Web development (with stateful servlets or any derivative) should know this as it is virtually impossible not to have come across resource leakage and concurrency issues at some point. The stateful model, while useful, has a significant cost.

I really don't understand this need to complain so vocally about something like this. Possible reasons:

- It affirms the OP's sense of superiority somehow;

- It's about "street cred" with [Python, Ruby, Node.js, insert other language here]; or

- One is so obsessed with "purity" that one spends all one's time complaining about how everything isn't Lisp.

Use it or not. I don't care. If you're not going to use it, why complain about it? If you are using it, what does the public snobbery (which is really adding nothing new to all the other PHP rants) really add?

I'm a big fan of pragmatism and the fact is that 4/20 of the most visited sites on the Internet are written in PHP.

EDIT: /sigh/ I get the inevitable "you must be a PHP programmer" retort (like that's actually a retort and not just more snobbery). For the record, I've only used PHP for ~6 months. My main experience is Java (~14 years), Python (~2 years), C (~5 years) and C++ (~4 years).

From your edit, you've only been working with PHP for about 6 months, so you may not have seen some of the code most others have. Can you imagine, then, diving into a website's back-end to see @ all over? It turns out, the previous developer realized all those nasty notices and errors stopped happening if he slapped a @ on everything. Now your client/boss/friend is pissed because when someone submits their form and they have a space in their name, the entire site crashes, and you have to figure out what's causing it through a tangled web of spaghetti code with no errors.

This is the norm in PHP because, like the author said, it makes it incredibly easy to write bad code.

> If this one thing that annoys me on HN it's the pervasive anti-PHP snobbery.

This isn't anti-PHP snobbery. To write it off as such is an attempt to dismiss most of the (quite valid) complaints. And complaining about someone complaining is really only highlighting your own hypocrisy.

As you said, you really don't understand his need to complain. That's fine, but many on HN do. This was a great write-up for all of PHP's downfalls. Some of it is really only complaining about how PHP isn't Python, but there are a lot of fantastic points about language design and how PHP sacrifices consistency for... really no reason at all. So don't assume every complaint about a language is "snobbery" or an attempt at "streed cred" (wut?) Instead, ask yourself why there are so many people writing so many complaints about this one language. Then, ask yourself why you're writing them off.

I do maintenance for a lot of PHP sites at my job, and the code is staggeringly difficult to debug or modify. It's punishment for my sins.

PHP was a tool for generating textual data structures (HTML) and it should've been leveraged by another tool for control flow and business logic, but it wasn't. The code I maintain is pre-frameworks; it's got no DRY, no separation of concerns, no design forethought at all. It's just HTML generation that satisfies its needs as they arise.

Now PHP is a quirky, mediocre, and capable language that's still really good at generating HTML.

You've turned something that's a person's fault into something that's the language's fault.

Other languages have some sort of warning suppression as well, like Java's @SuppressWarnings or C#'s #pragma warning disable. Although they won't suppress all errors like PHP does, it can still bite you if you don't fix them.

It IS snobbery. You're taking a look at other people's code, and judging the language from it. I've written PHP for about 3 years and I've never once used the @ to suppress errors.

> You're taking a look at other people's code, and judging the language from it.

At some point, you have to start blaming the language for fostering an environment where that code is acceptable.

Not to mention that I have no idea why the original commenter picked on this. It was listed as one of the 7 or so things that can go wrong with that one single, not unusual line of code. It's not like he had a whole paragraph about why @ is bad.

Nonsense. The @ error suppression is a tool, just like any other. It should be used sparingly, but it does have its uses. I have been writing in PHP for over a decade and I have used it exactly one time. And yes, it irritates me when I see it in other's code all over the place ... which is why I refactor all external PHP code before I place it inside of mine.

The amazing thing about PHP is that it has a plethora of tools available and the language doesn't force you to write code in some constrained manner according to what some snob perceives as the right way. The only right way is the way that works and works well.

You don't like a feature of PHP? Don't use that feature. Simple as that.

> I refactor all external PHP code before I place it inside of mine

> You don't like a feature of PHP? Don't use that feature. Simple as that.

I don't know anything about you, but judging from that attitude you haven't worked in many teams. Of course it's not as simple as that. If I had a penny for every time I had to fix someone not checking that strpos() === FALSE, well, I could fund my own startup. You may have the luxury of refactoring all over the place, but the reality out there is that horrible code like this is left to fester until it causes real business damage.

Well, that means you have zero experience with the majority of concerns expressed in this thread, and so are not qualified to opine on them. You work in a happy bubble and I envy you for it, but in the real world you very very rarely get the go-ahead to refactor old code. So in the real world, you very very rarely get to see a quality code base. In any language, really, but PHP compounds this problem with its idiosyncrasies. But you wouldn't know about that.

But there is a huge difference here. PHP directly encourages it, making it so easy to do "just prefix it with @" and dedicating a part of the core language syntax to it (thus spending such a nice character for such a triviality). I believe (correct me if I'm wrong) that in Java, it is just another annotation, and in C# just another preprocessor directive.

And I think that's what the article is about - so many things are wrong in the very foundation of the language.

To get the same effect as @ you'd have to use try {} catch {} blocks all over the place and leave the catch blocks empty, as with any other language with runtime exceptions. Sadly this is done more that one would think...

PHP programmers have only one single thing in common. PHP.

Is it so wrong to use @? I've always used (@$_REQUEST['foo'] === 'bar') as a shorter way of writing (isset($_REQUEST['foo']) && $_REQUEST['foo'] === 'bar') - I'm curious if there's a problem with that approach.

You'd probably be better off creating a function to do what you want succinctly rather than using the suppression operator.

Out of curiosity, where do you side on the C-is-an-unsafe-evil-language-because-of-pointers debate?

PHP makes it extremely easy to write ANY code. But since article saying "I've noticed this piece of good code in PHP" is not going to get on HN anytime soon, you get much more attention to bad one. That's like saying Internet is the source of filth because it makes easy to post bad stuff. It makes easy to post all stuff, that's the point.

"This was a great write-up for all of PHP's downfalls."

These "downfalls" are known and discussed 1000 times. Really, who needs another article about "PHP sucks because I can find 3 functions with inconsistent parameters"? How exactly it is going to make anything better? What exactly does it contribute to the world?

No. PHP makes it easy to write bad code and between normal and challenging to write normal code. This is why Doctrine, the closest thing PHP developers have to SQLAlchemy, needs three ways to declare table and column metadata: a separate YAML file, a separate XML file, and in PHP comments. All three of those methods are awful, and only one allows you to keep the metadata and class in the same file.

> These "downfalls" are known and discussed 1000 times.

And, like a wiki, it's useful to have them all in one place.

I write code in a number of languages, and there's nothing "challenging" in writing proper code in PHP. The fact that your example has nothing to do with code quality or language only underlines that.

> "And, like a wiki, it's useful to have them all in one place."

Maybe, but that article isn't it. PHP has a wiki: http://wiki.php.net/. You want to list things you want fixed in PHP and have it in one place? Ask for an account and maintain a page there. Rehashing old tired "strpos doesn't have underscore and str_rot13 has, oh noes!!! I can't use language with missing underscore!!!" is really stale by now and doesn't contribute anything new.

Maybe my point wasn't clear. It's not a difference in how those two ORMs accomplish their goal; it's that PHP doesn't let you do what SQLAlchemy does, even if you wanted to. Want to write an ORM that uses YAML, XML, or comment annotation in Python? Great! Want to write an ORM that uses classes or objects as column declaration in PHP? Too bad.

> Rehashing old tired "strpos doesn't have underscore and str_rot13 has, oh noes!!! I can't use language with missing underscore!!!" is really stale by now and doesn't contribute anything new.

Now I think you're just being petty. Obviously an underscore isn't what we're talking about here. Take your straw man elsewhere, please.

I'm actually doing just that; it's not as clean as you can do in Python but it's not outrageously verbose either. Trying to map one languages features onto another is not a valid critique.

Different language has different limitation. Just because you can not have SQLAlchemy in C, does not mean C encourage bad code.

What prevents you from doing that in PHP?

https://github.com/gigablah/fsphinxphp/blob/master/src/FSphi...

Note the $getter parameter.

> Now I think you're just being petty. Obviously an underscore isn't what we're talking about here. Take your straw man elsewhere, please.

What he's talking about here is known and talked about for 10 years. It's just function names, it's not that big a problem. Yes, we know old function names are inconsistent. No, we can't change them because that will break code. If that's what makes or breaks language for you, PHP is not for you, and most languages are not for you, because you're obviously not interesting in solving the problem, you're interesting in boosting your self-esteem by boasting shiniest tool out there. Nothing wrong with it, but PHP is not created for that. If that means for you that PHP sucks, fine, but for 99.99% out there shininess is very low on the list of priorities. So if you want to discuss important stuff, leave old stale stuff like ranting about strpos alone and discuss important stuff.

You must have missed the rest of that paragraph. I specified what it does.

> What he's talking about here is known and talked about for 10 years. It's just function names, it's not that big a problem.

Again, missing the point. Python has these same minor inconsistencies in its stdlib. It's the combination of all these minor inconsistencies with a language that gives you more tools to write bad code than good that makes PHP torturous. It's everything that the author wrote about in one neat little package.

Any old tired issues for you could be something new for someone else.

> So your complaint is that when you use @ to suppress an error it... suppresses the error?

This was one bullet-point from a 7-item list. Also it didn't say that @ is bad in any way (perhaps its use is), it was there only to demonstrate error configuration which is clear by the bullets after it.

> > There is no threading support whatsoever.

> That's a good thing.

You are right that for many tasks not even thinking about threads is a good idea, but there are cases where threads are very appropriate. Having the feature wouldn't hurt, would it? (Considering how tied the php is to C)

> So, it's a problem that array_search returns 0 when something is at... position 0? And returning false is just a sentinel value, much like functions in other languages might return -1. So what?

He explained the "so what" in the next few lines. I'll cite it for you: "If you use FALSE as an index, ..., PHP will silently convert it to 0 for you. Your program will not blow up; it will, instead, do the wrong thing with no warning"

Having a try statement is same as having to check for the value to be FALSE/-1/whatever, we can agree on that. But letting users write code that appears to work (yet it does not) is not a good property of a language.

> Much like Java/C/C++. PHP has array_slice() if you want it.

PHP's arrays are very different (uniform types) from those of C/C++/(Java?). So why compare them? Other than that, I agree, having slice function is enough. The author could've left this one out.

So two of your points were taken out of context, one was your opinion (two if we count your preference of if over try when checking for errors), and only two were probably justified. Rather strange choice considering you had dozens of options.

I still don't see the point that's trying to be made here. Whether it returns -1, FALSE, or you need a try/catch, the programmer still needs to check. To successfully program in any language with an 'index of' function, a check needs to exist regardless...