Bed-Jumping

Been there, done that. (reminded of Bed Jumping HQ from Tim Bray's post)

 

PHP is Doomed: a rebuttal

Imagine my horror, to take a new job in IBM doing some PHP stuff two weeks ago, only to find out last week that PHP is Doomed. Man, what crappy timing on my part, eh?

I'm kidding of course; I don't think PHP is doomed. But the author of the article, Justin James, doesn't appear to be kidding to me; he seems quite earnest in his beliefs. So I figure I'd offer a rebuttal to some of his points.

PHP does not allow the programmer to multithread their application.

This point is brought up multiple times in the article. And of course, Justin is right. PHP doesn't support threads as a programming library capability like Java and other languages do. The reason Justin thinks this is the primary reason for PHP's demise is that you need multi-threading capability in servers; web servers now, when serving up pages, are going to be getting data from a variety of sources, and the only way to scale is to allow these separate pieces of data that make up a single page be retrieved simultaneously with multiple threads.

Justin uses Java as an example of a language that can do this multi-threaded processing on the server. Except, as it turns out, in Java Servlets, you are advised to not spawn your own threads. I won't go into the reasons, but found a message board entry here @ dWorks that provides the usual warnings: Re: Spawning Threads In Servlet. So, the fact is, you really shouldn't be spawning your own threads in a server.

Now, for the Java programmer, there's probably a way around this; your web container may provide extensions to allow you to spawn threads. For WebSphere, for example, you can use Async Beans. Or your container may support the WorkManager API. Or you may get some level of async processing through your middleware, such as asynchronously invoked web services. These bring additional complication, and in cases of container-provided extensions, may prevent you from writing completely portable code (portable across different web containers).

But there's still a problem. And it has to do with this thought (from the article).

If you are a Web developer, would you prefer your application to continue to process its work (for example, retrieving data from the local database, dynamically creating images, etc.) while waiting on the third party chunk of code (such as a Web service), and only have part of the page show a "Sorry!" message? Or do you think it is better for the entire page to take forever if the third party data source has a problem?

Threading is not simple. For example, how long are you willing to wait for that chunk to timeout, before using "Sorry!" as the content instead of what's supposed to be there? You're going to have to have a timeout. This implies that you actually need to synchronize on all the threads getting the individual chunks. Do you have a way to cancel a task that's taking too long? This is complicated stuff.

The obvious way around this, from my view, is to use AJAX to actually handle the parallel calls on the client. You've moved the problem from the server to the client, but it's safer to have it on the client anyway. And a user could, in theory, individually cancel pending requests, based on their ability to wait for them, instead of relying on presumably static timeout values in the server. But Justin doesn't appear to like the way of AJAX at all, which rules that option out for him. (Aside: he doesn't really explain why he doesn't like AJAX; I'd like to hear that argument).

Now, just thinking about moving your async tasks to the client brings up another point. JavaScript doesn't support threads when running in the browser; so how do they handle making HTTP requests in parallel? The model provided to the programmer is that of asynchronous programming with callbacks. When I make a call that would otherwise block, you pass in a function that the underlying code will call back on when the call succeeds or fails.

This style of programming is also available in the Twisted framework for Python (which I've never had a chance to use, personally; looks like fun though!). You can typically simulate threaded programming with asynchronous, event driven programming. With no threads. So, there's an answer for PHP straight off: they actually don't need threads, they need a port of Twisted. You of course need to have basic asynchronous i/o capabilities to build something like this, and it appears to me PHP already supports this for socket i/o.

Ruby is another language that Justin points out has thread support, but, in fact, it's probably not quite what he's thinking about. See Threads and Process from the online Programming Ruby book. Ruby's thread story is the same as VisualAge Smalltalk's: what we call "Green Threads"; they aren't operating system threads, but a threading system built into the virtual machine. As such, they will have limited capability to take advantage of multi-core machines, which is counter to part of Justin's argument that threaded applications can take direct advantage of multi-core machines.

There are things you could find to do with all those cores though; say ... virtualization.

Moving on ...

Its documentation is not very good, and frequently the comment threads provide the information that the documentation should have included but did not.

I would agree that the doc could use some work; I think a reorganized view of the existing doc might be enough to keep me basically happy; but doc quality is a constant issue (even with Java and Ruby). I actually like the end-user comment threads; someone tried this with Java a while back (@ JavaLobby?); wonder what happened to it? The one thing that I've not seen anyone compare with is the number of translations available for the base php docs: English, Brazilian Portuguese, Chinese (Simplified), Chinese (Hong Kong Cantonese), Chinese (Traditional), Czech, Danish, Dutch, Finnish, French, German, Greek, Hebrew, Hungarian, Italian, Japanese, Korean, Polish, Romanian, Russian, Slovak, Spanish, Swedish. Wow!

It lacks high quality tools such as IDEs and debuggers in a "ready-to-use" state.

Besides the well-regarded Zend Studio, if you enjoy the Eclipse lifestyle there are two PHP IDEs under development: PHP IDE Project and PHPeclipse.

I will give PHP this: it is easier to install on top of Apache or IIS than any J2EE server that I have encountered.

You sold me!

---

Update: fixed a broken link to the Creative Commons search page, linked to at the bottom.

---

Photo "Impending Doom", with a nice CC license, by Dr. Stephen Dann. Found using the Create Commons Search Site.

echo "Hello, Blogosphere!";

Note that this post was my first post in my blog @ developerWorks. I've moved all the entries over here, so the context is a bit wrong, but I figured I'd leave the post here, and just add this note - pmuellr - 2007/11/07

Who are you?

Patrick Mueller, check out my brief bio at my wiki @ developerWorks.

What are you doing here?

Well, I just took a new position in IBM that involves 'community' (as in programming communities) and so I thought I should set a good example of how to do that by creating a blog here.

In addition to doing something regarding 'community', my new assignment also involves PHP. While I won't quite claim to be a PHP n00b, I'm pretty green. I thought I could let you learn along with me, and hopefully some more knowledgeable folks will happen upon the blog and correct me as appropriate.

I've been blogging for a while; my old blog is here. Before blogging, newsgroups; before newsgroups, VM/CMS FORUMs. Whoops, just dated myself!

Anyway, besides the usual stuff I blog about (maybe I'll drop the movie reviews), expect to see PHP stuff.

By taking this assignment, I left another very cool one: Jazz. My hall-mate Bill Higgins talks about Jazz quite a bit, so go there to learn more. I'll probably do some blabbing about it myself, eventually.

Radio Paradise

Have I plugged Radio Paradise before? Maybe; if not it's time for another plug.

This is simply the best radio station I've ever listened to. It's not like there's much competion in the RTP, NC area. At Purdue, we used to get some pretty good stations out of both Indy and Chi-town, and DC/Baltimore had some decent stations when I was there.

But RP beats them all. Plays new stuff I can tolerate, and generally like. Old stuff I love. Non-intrusive, commercial-wise.

Time to donate again.

Click here to see what they've played recently.

We get DirecTV at home, and so also have some of the XM channels, but none of the ones I get compare. In a pinch (I'm upstairs, don't have a computer plugged into speakers), I'll listen to the XM traditional Jazz or Blues channels. The closest channels to RP play too much crap.

RP has actually turned me off of buying music. I'd much rather have the variety from them than to have to manually switch what I'm listening to. Yes, I am rather lazy.

I've done the emusic thing, a few years back, when they had unlimited downloads. I downloaded LOADs of stuff, mainly older jazz, but the first 1/2 of Elvis Costello's catalog more than made up for the $45 I paid for unlimited downloads for 3 months. Not really played with anything else, like last.fm, or as Mark suggested in his blog, OpSound; RP is just too easy.

If I could only get RP in my car, I'd be set.

Playing right now: SCOTS - Fried Chicken And Gasoline (link) . A "local" band.

MacBook Random Shutdown

You'll only 'get' the image above if you have a MacBook that suffers from Random Shutdown Symptom (aka RSS or RSD). You can read all it about it Apple's MacBook Discussion Board. I'm an early adopter of the RSD technology, first experiencing it over two months ago.

Luckily, Apple has provided elaborate information regarding this problem in Knowledge Base Article 304308. What a relief!

My machine has decided it's time to start Randomly Shutting Down again, after it's second extended repair job less than a month ago (which took 10 days). Funny story: when I picked the machine back up at my local Apple Store, the Genius brought it out and powered it up, and the display filled with colored vertical lines. He took a look at it, and said "oh no, we're going to have to send it back to get repaired again". I replied "Nope, I can fix that". And proceeded to fix it. (I'd been reading the MacBook discussion list a bit too much).

That was a mistake, of course, since having it sent back right then, for another repair, would have meant instead of going in now for a 3rd repair, I'd be going in for the 4th, and would have gotten a new machine instead (Apple won't repair a machine more than 3 times, supposedly).

So, now I have to decide what to do; here are some options:

1. I can stay up late some night so I can get a reservation at the Genius Bar at my local Apple store to drop the machine off for repair; but I absolutely have to be able to have the machine shutdown, in the store, in front of their eyes, before they will accept it.
2. I can wait 60 minutes or more on the phone on hold with AppleCare to get a problem report open or hopefully re-open my previous problem report. And they'll send me a box to send the machine back to them.

In any case, current wait time for MacBook "Random Shutdown" repairs is about 3 weeks, according to reports on the message board.

Yes, I've learned my lesson. Never by rev 1 of an Apple product.