Why Google App Engine Shouldn't Include PHP
blog.jeffhui.net
Why Google App Engine Shouldn't Include PHP
1–10 of 10 posts
Re: Why Google App Engine Shouldn't Include PHP
#2The argument being made is unclear. Is the author saying that Google App Engine should not support PHP because PHP is not a robust language? If so, that's not a very persuasive argument.
More importantly, this is a very poor piece of writing, the worst I've seen in some time. For starters, the author would do well to learn how to write a thesis statement:
Re: Why Google App Engine Shouldn't Include PHP
#3He seems to be saying "PHP shouldn't be supported because its a bit of an ugly language and somewhat insecure"
But then should they only support Scheme? :]
The problem is theres so much useful {badly written} PHP code out there, its going to be hard to ignore.
I guess they'll _have_ to adopt PHP, Python, Ruby/Rails in order to get user volume.
Which language is better is probably irrelevant.
Re: Why Google App Engine Shouldn't Include PHP
#4He seems to be saying "PHP shouldn't be supported because its a bit of an ugly language and somewhat insecure" But then should they only support Scheme? :] The problem is theres so much useful {badly written} PHP code out there, its going to be hard to ignore. I guess they'll _have_ to adopt PHP, Python, Ruby/Rails in order to get user volume. Which language is better is probably irrelevant.
Actually, the amount of (badly written) PHP code works against PHP in this case. Not due to esthetic or subjective opinions about PHP, but for very pragmatic reason - SQL. AppEngine does not support SQL as we know it, but uses the google database and GQL. Changing that huge amount of PHP with interspersed SQL statements is not worth it.
As for now, it supports Python and JVM languages (that includes JRuby). But even for these languages, third party libraries can be a problem.
Edit: typo
Re: Why Google App Engine Shouldn't Include PHP
#5He seems to be saying "PHP shouldn't be supported because its a bit of an ugly language and somewhat insecure" But then should they only support Scheme? :] The problem is theres so much useful {badly written} PHP code out there, its going to be hard to ignore. I guess they'll _have_ to adopt PHP, Python, Ruby/Rails in order to get user volume. Which language is better is probably irrelevant.
Well, the OP seems to point at PHP developers generally being poorly educated and clueless, mostly deploying other people's apps rather than writing their own. In short, they won't have a clue how to use GAE if it provides BigTable rather than MySQL so out-of-the-box LAMP apps fail to work without a rewrite.
Does GAE really want user volume if those are the sorts of users they'll get?
Re: Why Google App Engine Shouldn't Include PHP
#6While the comment that many PHP applications depend on a MySQL database (I'd seriously expect WP to have some sort of DAL by now) is true it wouldn't be impossible for someone to write an extension to support Google's BigTable.
Article was a little confusing(ly structured) but surprised me by not completely bashing PHP.
I haven't actually used GAE and assume BigTable is another database platform.
Re: Why Google App Engine Shouldn't Include PHP
#7Has blatant PHP bashing been made so taboo around here that we must now endure passive-aggressive PHP bashing?
Re: Why Google App Engine Shouldn't Include PHP
#8While the comment that many PHP applications depend on a MySQL database (I'd seriously expect WP to have some sort of DAL by now) is true it wouldn't be impossible for someone to write an extension to support Google's BigTable . Article was a little confusing(ly structured) but surprised me by not completely bashing PHP. I haven't actually used GAE and assume BigTable is another database platform.
> I haven't actually used GAE and assume BigTable is another database platform.
Background: GAE doesn't provide access to BigTable. It provides access to GAE Datastore which is built on top of BigTable. Both are key-value stores. I don't know how much indexing that bigtable provides, but datastore has a fair amount (under user control).
There are no joins or aggregations in the GAE query API and queries can only return one type of object. (The provided subclass/roll-up model seems a little odd.) These constraints seem baked-in.
The transaction model is basically "all objects under a given root name can be updated/created/deleted as an atomic operation." (Within said atomic operation, a given object can only be written once and I forget whether reads see writes.) This makes it hard to do certain sorts of real-world transactions. (Imagine transferring money between two accounts.)
The datastore also has certain size and "number of object" limits. Then again, the platform limits the amount of time that each operation is allowed to take.
Re: Why Google App Engine Shouldn't Include PHP
#9Wow, this is a horrible article. Where does the author get his facts about the quality level of "most" PHP developers? Sounds like typical religious flaming and half-arsed fud.
Re: Why Google App Engine Shouldn't Include PHP
#10It may already be too late, PHP on the JVM:
http://www.caucho.com/resin-3.0/quercus/
Note, I know nothing about the project, just first result from Google. I knew something existed because I'd read about IBM's Project Zero, but I think their implementation of PHP on the JVM (called P8, iirc) is closed source.