note 50179 deleted from faq.languages by sobak

Note Submitter: symcbean ---- I really must take issue with (Cash at nospam dot thesilverside dot com)'s comments regarding enterprise applications and PHP. Yes, PHP is an interpreted language (but...PHP Accelerator? also you can write caching *with* PHP, also checkout http://shootout.alioth.debian.org/, and have you seen the benchmarks for Pharrot?). Adding more tiers into your application is a recipe for disaster since it reduces scalability by creating bottlenecks/crossovers and has a big impact on transparency. I'll admit that for a very few applications, then server hardware is more expensive than developer time - like if you're turning around more than 500000 hits/hour, then it may work out cheaper to develop in 'C' with half the servers than PHP, but this is far from the sort of volume I've seen on an enterprise application. There's a lot been written elsewhere on PHP and scalability which I won't repeat here. There are issues with using PHP for this kind of application. Firstly managment of privilege - but that applies (AFAIK) to any web-based system. There's also the problem of namespace collisions in large apps. Since I regularly develop embedded applications with PHP using HTTP as the communications substrate for transactions spanning 6 or more origanisations, I'd like to know whay I shouldn't be using PHP / processing synchronously, and how I can create a near real-time system without synchronous operation. It'd be a sad world to live in where there was only one programming language/methodoly/idiom - diversity is a great thing. Java provides beans and struts, Coldfusion provides fast development and .NET....(suggestions please). PHP comes closest to solving my problems, many of which are very much in the enterprise applications domain.