Why Enterprise Web Scalability is Science Fiction:

1. You Use PHP to Troll WHOM?!. The wherefore of this article and an introduction.
2. Even the Pros are Cons. <——THIS POST Why PHP’s advantages in enterprise are a form of backhanded compliment.
3. Sinking a fleet of FAIL. Reasons for why PHP should not be used in enterprise fail you.
4. Time to set my phasers on “kill”. Deconstructing the use of the word of “enterprise” as an adjective modifying “web development.”
5. Defensing the indefensible. Don’t bother defending your B.S. it only makes you look more stupid.

Looking at the “compliments” served to PHP by the article as “advantages”…

[Takedown Part 1 after the jump]

Understanding HTML

Several dynamic or “scripting” languages, including PHP, Perl, Java and others, have their roots in the C language…

In fact, its full name is PHP: Hypertext Preprocessor (one of those famous Unix recursive acronyms), which means that it understands hypertext (HTML) without any special API or modifications.
—CIO Magazine

Three errors:

The first two can be confirmed by looking at a page linked from the PHP homepage:

PHP succeeds an older product, named PHP/FI. PHP/FI was created by Rasmus Lerdorf in 1995, initially as a simple set of Perl scripts for tracking accesses to his online resume. He named this set of scripts ‘Personal Home Page Tools’. As more functionality was required, Rasmus wrote a much larger C implementation, which was able to communicate with databases, and enabled users to develop simple dynamic Web applications.

PHP is more a grandchild of C, via its “roots” in Perl and shell scripting, and the language itself is written in C. Its recursive acronym didn’t come about until 1998, ex post facto.

The third error is really both confusing and misleading: an assertion that PHP “understands hypertext (HTML) without any special API or modifications.”

Ken,

PHP is a server-side scripting language, not a web browser.

Loves and kisses,

terry

PHP and databases

PHP has enjoyed a long-lived association with databases, especially MySQL. However, PHP plays equally well with Oracle, DB2, SQLite, PostgreSQL, Sybase and Microsoft’s SQL Server. Migrating from one database server to another is usually quite simple since most of PHP’s functions have a common naming convention. A programmer can do simple global pattern replacements to change from one database brand to another.
—CIO Magazine

Three errors:

First, There is no doubt that PHP plays better with MySQL than any of the other databases (other than possibly SQLite).

1. The MySQL extension was bundled and on by default in PHP
2. The cost of database connections starts and stops is much less in MySQL than the other databases. One way around this is to use persistent connections, but what if connection starts, stops, and usage is very expensive like in Oracle?
3. Who introduced the ANSI92 SQL-defying LIMIT clause in mSQL (and thus mySQL)?

Second, Perl (with DBI) and .NET (with ADO COM) do a better job longer of abstracting database portability than PHP which has mimiced it with PDO and ADOdb respectively:

PHP, like all other web development languages, has an advanced data objects layer. It’s called PDO, and offers single-point database portability.
—commenter on the article

Third and most importantly, anyone who has had to do database migration…

Anybody who has done any sql programming will know that changing from one database vendor to another is not as simple as query-replace’ing mysql_query with mssql_query.

Ever heard of SQL dialects?
—Rasmus Tofthdahl Olesen commenting on the article

This is why I advocate data access and database portability over database abstraction and database independence.

(The fact that database independence is not only encouraged, but is sometimes required in enterprise applications is evidence that possibly the database is not the bottleneck, or, far more likely, that performance and scalability is not a priority in enterprise. More on that later.)

I think what is going wrong here is that PHP and database extensions are installed by default on many computers (Mac OS X, Linux distros, etc). While Perl and Python are also often installed by default, when I say PHP I really mean mod_php, the same cannot be said for mod_perl or mod_python. This means, out of the box, PHP is available and ubiquitous on web servers. Almost all hosting services provide that as well as a database to talk to (most likely MySQL). This, in turn, has made PHP and apps written in PHP hugely successful.

Of course, none of that has any relevance in the IT world.

Choices have consequences

In programming design pattern literature, a design pattern has consequences. This term, when used correctly, means what sucks about using a particular design pattern.

I do see a disadvantage of PHP. For java, there is a natural barrier…PHP on the other hand is so easy to learn that it’s extremely easy to build rubish. That’s why it’s important to educate developers.
Ivo Jansch commenting on the article

If you look at the pros listed (in neat CIOs-must-be-morons) bullet form, you’ll find the answer to the theme: why PHP “has its strengths and its weaknesses like any other language.” Taking the article’s “pluses of PHP” and showing they have consequences (minuses):

• It is easy to learn. A lot of PHP applications out there are poorly architected and poorly secured.
• It blends well with HTML. It naturally mixes business and presentational logic which may make rearchitecting a poorly designed application a chore.
• PHP has a vast library of functions and APIs. PHP lacks a top-down conventions making programmers dependent on a code-sensing IDE or frequent references to PHP.net website. Such extensions are erratically supported, sometimes requiring intimate knowledge of its quirks. The huge library of functions makes ICU support (PHP 6) very difficult and has made thread-safety a problem that will probably never be addressed.
• You can rapidly create Web applications and database-backed applications. PHP is the web world equivalent to nuclear proliferation—putting web development in the hands of everyman. Talent in the PHP world is spread amongst a greater breath of ability than almost any language making hiring difficult. In economics, this is known as the “signalling problem.”
• It is cross-platform capable. But it has codependencies with the rest of the LAMP stack—it works best when your operating system is Linux; your webserver is Apache; and your database is MySQL. This predilection to “push problems down the stack” to another tool, creates an setup and configuration problem at the operational level, instead of adding functionality in the language itself.

What the author and the editor don’t seem to understand is:

Language consequences flow directly from the strengths of a language.
—me

But I guess they believe such subtlety and insight is too much for their readers, from this I can only infer that CIO’s building “enterprise” applications must have the intelligence and experience of a five-year-old.

Websites for dummies…

Don’t believe me? Let’s take the author’s very next set of bullets which explain where php should be used:

• Creating an intranet site.
• Prototyping an application that will be converted to Java or some other language.
• Creating a Web database application.
• Deploying an inexpensive or quick solution.
• Using ready-made apps from Sourceforge.net or other sites.

Intranet sites are often built better with a framework independent of language. This means things like J2EE in Java, Ruby on Rails in Ruby, Mason on Perl, Django on Python, or Zend Framework, Codeigniter, CakePHP, Symfony in PHP. Why? How many people are going to be using the site in the first place? Of course, before you jump on the framework bandwagon, you would do well to ask yourself if the application is simply mappable to an existing solved, downloadable or purchasable application: Trac, WordPress, MediaWiki, FUDforum, etc. Of course, not all of those “ready-made apps from Sourceforge.net or other sites” necessarily need to be built in PHP, do they? 😉

The idea of prototyping comes from Frederick Brooks’s advice to “plan to throw one away” has remained one of the most controversial advices in the history of programming. In general, we all agree wholesale rewrites are an expensive task and that Big Up Front Design is equally stupid. Advocating PHP as an advantage in prototyping is no different than me advocating using Ruby on Rails for prototyping a large social network: it’s controversial at best, company-destroying at worst.

Instead consider the company I work for, we have a 200+ server infrastructure built with PHP as the glue, but many of the performant parts are written in Java! Of course, I consider SendMail, Oracle, Memcached, etc. as also performant parts, none of which are written in Java. We have a mixed infrastructure serving 60 million registered users, but PHP was definitely not prototyped and converted away to Java.

[Continued in Part 3: Sinking a fleet of FAIL]