It's interesting that I asked a simple technical question, and rather than just answering it, you threw in a slew of insults and opinions about PHP and PHP programmers. Why do you have such strong feelings about PHP and PHP programmers so much? How long did you actually use PHP, and which companies did you work for that used it?

It's not your assertion that PHP is a crappy language that I disagree with. I fully agree there. Where I disagree with you is in your assessment that a) there aren't many skilled programmers who use PHP, and c) language features of PHP make it very difficult or impossible to write well-designed software.

As to your assertion that PHP is only good for simple projects employing low-skilled developers, tell that to the various PHP startups paying top dollar for skilled PHP developers.

PHP arrays are actually ordered hash tables. This information is readily available. If you really need a real array, there is SplArray.

> Now, we've seen workarounds for these problems. Facebook wrote a PHP to C compiler, and moved all crucial algorithms to C.

At the scale of Facebook, nobody uses scripting languages, so I doubt this is purely because of PHP. This would be like me telling you to not to use RoR because Twitter switched to Scala (people said this, but those people are stupid and I'm not among them.) Twitter and Facebook have problems you and I are unlikely to have.

> You can use unit-testing to supplement the lack of any usable type information, and to combat the automatic casting that PHP does (which creates all kinds of bugs in edge cases, that is hard to track or test against). You can use profiling to track performance issues, and fix code that interacts with frankenarrays, in a sort of trail-and-error kind of way.

PHP's type system is crazy, that is absolutely true. But it's not as hard to work around or as frequently a problem as you're suggesting, at least in my experience. JavaScript is another language that has a crazy-ish type system, but it doesn't get the hate that PHP does.

I have never had a case where PHP's arrays caused performance problems, but that's probably because I've also never written an application that didn't interact with some kind of back-end store like a database that was inevitable slower. I've done a fair amount of work to make apps faster, and the big wins were always in fixing bad data access or caching patterns and algorithms. I imagine that there would be a point when I need to worry about not using PHP arrays, but I guess I haven't hit it. And again, if/when I do, there's always SplArray.

> But people are abusing PHP to write large scale libraries and frameworks. Many riddled with security issues, and unpredictable performance bottlenecks, because the language wasn't designed to actually allow you to write well defined algorithms.

There are some really shitty PHP projects. I suspect a big part of that is that they took off before there was the widespread knowledge of best-practices we have now. (I'm assuming you're thinking of wordpress, drupal and joomla.) I've worked with Wordpress a bit, unfortunately, and the main reason it's so damned slow is because the queries are badly written, and the data access and caching patterns are awful. PHP's arrays never crossed my mind as a bottleneck, because they don't even show up in my profiling tools.

For what it's worth, I used to see a lot of people's code because the company I worked for required code samples when we were interviewing people. I saw a lot of really shitty RoR code, and I do not blame that on the language or the framework.