| >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. a) didn't make that assement
b) ??
c) difficult, yes >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. No, my assertion was that PHP is only a good economic choice, when you choose to hire low-skilled, cheap employees. That's its niche. >Twitter and Facebook have problems you and I are unlikely to have. Agree. But that does not make what Facebook did with PHP, anything less than working around the issues caused by the initial commitment to PHP. >JavaScript is another language that has a crazy-ish type system, but it doesn't get the hate that PHP does. But it did. Even now, claiming that Javascript's language design isn't optimal isn't somethign people will argue against. Say the same thing about PHP, and you get threads like these... >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. Now, the type of problems I'm pointing at, are the ones that read their head when the datasize gets larger. For example, an algorithm interacting with an array in PHP. Every loop it inserts or removes an element. Now depending on where that data can be found in the array, and if it's key is a number or a string, if these number-keys are close together in range or not, the algorithmic complexity is anything from O(n) to (2^n). In other words, the normal fauna of sorting algorithms are very hard, if not impossible to correctly implement in PHP. This is not very relevant, if you just need a good sorting function for your array, since that is build-in. This is not relevant if you datasizes are always small. So, this is not relevant in the small-scale world. But if there is a chance that will need to be implementing a complicated algorithm in PHP, that perhaps needs to interact with large datastructures, than PHP is a dangerous choice. Beyond the limited scope of a database powered template with a bit of logic, it is simply not suited. It is not designed well enough to be 'general purpose' programming language, and its civic duty of all to warn those who think it is. (like the authors of this Node.php project) |
I generally agree with your technical criticisms of the language (I generated a bit of heat and light a few months ago with a blog post called "PHP is not an acceptable COBOL"), but I don't think your assertions about the economics are entirely correct. I don't think most companies choose PHP because they expect it will let them get cheap help -- I don't think most companies actually choose PHP. They end up with PHP for any number of reasons that don't have anything to do with long-term planning. (Also, if you were putting together a database-backed web site in the early 2000s, there's a very good chance you'd go with either ASP or PHP unless you had a lot of experience in web programming in another language. After you built up sufficient inertia, switching would be difficult.)
On the flip side, there are a lot of companies out here in Silicon Valley using Ruby on Rails because it fits very, very well into the niche you describe: take a bunch of Rails gems and learn just enough Ruby to hold it all together with spit and duct tape. If I were starting a company and wanting to hit the "low-skilled, cheap niche," the only downside to choosing Rails is that low-skilled Rails programmers frequently don't recognize that they're low-skilled, because the mere fact that they've chosen Rails makes them think they're definitionally awesome.
(N.B.: I like Rails a lot, but gosh, it's attitudinal.)