Presumably he means allowing users to thoughtlessly work with unsafe values. One way that XHP could mask this problem is clear by looking at:

    echo <span class="username">{$_POST['name']}</span>;

Now someone comes along and decides the span is unnecessary, turning the code into the (erroneous):

    echo $_POST['name'];

However, I don't think this is a problem with XHP's approach, except in the sense that XHP doesn't go far enough in fixing PHP's faults.

If PHP gave all unsafe values the type "unsafe string" and disallowed all implicit conversion to safe types, then XHP's approach would be a welcome way of doing the right thing by default. Programmer-introduced errors like the above example would result in fatal type errors instead of exploits (presuming "echo" won't take unsafe strings and so requires a conversion function, like htmlspecialchars or the hypothetical unsafe_cast).

One could simple write their own "echo" function which only takes an XML object parameter.

    // This works
    write(<span class="username">{$_POST['name']}</span>); 
  
    // Where as this wouldn't work
    write($_POST['name']);

I think perhaps the use of echo in these examples is just a simplification. More than likely, in Facebook, these XML classes are outputted by another function.

The separation of presentation and logic.

Anyone who's spent the 1990s coding Perl CGI will tell you just how big of a step backward this is.

That seems to be unrelated to the concern here (as belied by the grandparent citing magic_quotes). XHP (like plain PHP, for that matter) can be used in a way that, for all intents and purposes, separates the concerns of presentation and logic. It's more a matter of convention than constraint.

> separates the concerns of presentation and logic

WHAT? The explicit purpose of this is to combine the presentation (HTML) and logic (PHP) layers.

The purpose of a "layer" is not determined by the language it's implemented in, but by what the code actually does. Code that handles nothing but presentation is by definition separate from the business logic, even if the presentation code and business logic are implemented in the same language. It is trivial to implement this architecture with PHP and even easier with XHP.

Lazy/bad developers will always find ways to put business logic and presentation in places they don't belong. I like systems that -- rather than enforcing arbitrary and inevitably leaky constraints -- aim for maximum productivity and power in the hands of capable developers.

Let's take a real case: Smarty. To my eye, XHP is going to take a huge slice of the PHP template system market away from Smarty. The reason is that XHP gives you the native constructs of PHP (sans mind-bending hacks -- try referencing a class constant in Smarty) while staying at the right level of abstraction for fast development: chunks of valid XHTML.