There’s a very simple question to ask web hosting companies that provides a pretty good first approximation to whether they’re any good or not:
For how long has PHP 5 been available on all your servers?
Simple? Yes. Irresponsible? Absolutely. However, the beauty of this metric is that without the option of time travel, it’s impossible to game, but at the same time, it is pretty effective at sorting out the sheep from the goats.
The key date to look out for here is 13 July 2007: the best web hosts started rolling out PHP 5 when it was in version 5.1 at least, and quite possibly when it was in version 5.0, but cheap and nasty web hosts didn’t do anything about it until the end of life announcement for PHP 4 just over a year ago. Some of them still have servers that don’t have PHP 5 installed on them, despite the fact that PHP 4 is now officially dead, buried, pushing up the daisies, and no longer supported by a lot of popular software.
Now this is not the only matter at stake — you need to take into account questions such as uptime, speed, and technical support. It may also not sound like a relevant question at first glance — pretty much all web hosts these days offer PHP 5.2.6 to new customers — but it does give an indication of how up to date your hosting package is likely to be with future changes and innovations, as well as raising serious questions if they’re not. After all, if a company needs a massive kick in the pants from the entire open source community to give you three year old technology rather than seven year old obsolete technology, what other shortcomings does it have?
Posted at 13:03 in
PHP
I just noticed the other day that PHP 5.3 (now in alpha) has closures and lambdas. This is excellent news — these are language features that can make for much more concise code. The syntax is a little bit more complex than in Ruby, JavaScript or C# thanks to the quirky way that PHP variables work, but it’s nothing drastic, and it’s a one-up on both Python and VB.NET, neither of which have multi-line lambdas.
The stable release of PHP 5.3 is due in September or October.
Posted at 20:20 in
PHP
Marco Arment (in a response to Jeff Atwood) came up with a list of five common complaints that are not valid reasons for hating a programming language:
- You’re unfamiliar with it.
- You don’t like the language’s vendors.
- Idiots often use it to write bad code.
- It doesn’t fully resemble your favorite language.
- You don’t like its syntax.
PHP’s not a perfect language, of course. Nothing is. But it’s by far the best language to use for nearly any web application, as long as you use an appropriate framework and good coding practices. Any language without either of those is bad.
I’d agree that PHP has its foibles, such as its lack of closures, its bloated global namespace and its ad-hoc, inconsistent approach to conventions. However, none of these are insurmountable, and in fact, once you get used to its foibles, working with PHP isn’t all that hard.
A few days ago I finished up on several days’ work on a PHP project and started on a SharePoint workflow. It’s an exercise that I highly recommend for anyone who is tempted to write an anti-PHP rant, because it will put everything in perspective, and give you a list of valid reasons for hating a programming language, platform or framework:
- Vertical and infinite learning curve.
- Unnecessary complexity.
- Useless documentation.
- Excessive pitfalls, gotchas and leaky abstractions.
- Design that obstructs you from adopting best practices.
- Meaningless, cryptic and uninformative error messages, buried in a massive log file deep in an obscure part of the bowels of your file system.
- Painful debugging process.
Check this out: to debug a SharePoint workflow you can’t just hit run in Visual Studio. You have to attach the debugger to the w3wp.exe process, and even then it still won’t hit your breakpoints or break on exceptions. According to this blog post, you have to copy the .pdb file by hand into a part of the GAC’s directory structure that you can’t even access through Windows Explorer, so you have to do it via the command line. On top of that, the edit-compile-test loop is agonising — it can take two minutes to re-compile, deploy, and re-load your test site into your browser, after which you may well have to remove and restart the workflow.
Admittedly it’s not all bad. The vertical and infinite learning curve at least gives you some immense satisfaction when you finally “get it”. However, getting there feels at times like climbing the Inaccessible Pinnacle in rollerblades with your hands tied behind your back.
Okay, folks, here’s a little exercise for those of you who think that closures are a pointless, computer-science-y concept of little or no relevance to real-world programming. This is a very practical snippet of code that I had to implement this afternoon, in PHP.
You have to write a function that takes two parameters: a template string containing placeholders such as [[foo]] and [[bar]], and a hashtable containing the values that are to be substituted into the placeholders, and returns a string carrying out the substitution. Your exercise is to write such a function in as few lines as possible.
In JavaScript, you can take advantage of the fact that anonymous functions have access to the arguments passed to the function in which they are declared, to produce a very elegant solution:
function do_template(template, values) {
return template.replace(/\[\[(.*?)\]\]/g,
function(key) { return values[key.slice(2, -2)]; }
);
}
In PHP, unfortunately, it is nowhere near as straightforward — while you can create functions on the fly using the create_function method, they don’t have access to the scope in which they were created, so I couldn’t use that particular trick here. The result? Twice as many lines of code to achieve the same result:
function do_template_substitute($part) {
global $tmp_values;
return $tmp_values[$part[1]];
}
function do_template($template, $values) {
global $tmp_values;
$tmp_values = $values;
return preg_replace_callback('/\[\[(.*?)\]\]/',
'do_template_substitute', $template);
}
Oh well, I guess PHP is a better language if you think that productivity can be measured in lines of code per day…
RSS feed
Comment on this » 
Welcome to my website. My name is James McKay and I am a
web developer from Horsham, West Sussex, UK.
