If you’ve done a lot with today’s popular Javascript libraries like jQuery and Prototype, you’ve no doubt come across closures.  They’re little self-contained functions that can be passed around like variables.  For example, jQuery’s fadeIn() method takes a function as its second parameter, and calls it when the target has faded in.  With a traditional coding style, you may have written something like this:

function doStuff1()
{
	// do some stuff...
	$('#mydiv').fadeIn('normal', doStuff2);
	// do some more stuff...
}
function doStuff2()
{
	echo "hello world!";
}

This works, but there’s a visual disconnect between what happens in the middle of doStuff1() and what happens in doStuff2(). And, when you start reading doStuff2(), you don’t have any context for what’s happening (unless you left really good comments). If doStuff2() is used in more than one place, you have a justification for keeping it a separate function. But if it’s only used this one time, a closure is the way to go:

function doStuff1()
{
	// do some stuff...
	$('#mydiv').fadeIn('normal', function() {
		echo "hello world!";
	});
	// do some more stuff...
}

This code is more compact, and it makes it clear that the echo statement is related to the fadeIn() call.

I use closures a lot in my Javascript coding, and I’m sure I’ll be using them a lot in PHP once 5.3 is widespread.

SQL injection is one of the biggest security problems in the PHP world. But, it doesn’t have to be a problem.

The simplest thing you can do to prevent SQL injection is to sanitize your inputs. If you’re expecting an integer, check that the value is an integer before you plug it into your query. Some people suggest using the addslashes() function on any value you plug into a query, but that still leaves room for improvement. The mysql_real_escape_string() function provides a little better security.

An even better way to thwart SQL injection is through prepared statements. They’re supported by the MDB2 library from the PEAR project, and I’m sure many other libraries support them. A prepared statement query looks something like this:

SELECT * FROM users WHERE username = ?

When you run the query, you give the database library a list of values to match up with the ?s in the prepared statement. The library then passes those values to the database, saying “I want you to find this exact value. Don’t interpret it, just look for this value verbatim.” If someone tries SQL injection against a prepared statement, they’re just going to get 0 results back.

Sure, there’s a performance penalty for doing prepared statements, but the security benefits are well worth the overhead. You don’t want your site to be one of the “tens of thousands” infecting other people’s PCs, now, do you?

Java is still out there, and I get tons of calls & emails from recruiters every week looking to fill Java positions (even though I haven’t updated my online resume in over a year). Java positions tend to pay well, and are usually with big, dependable companies. They’re safe, but probably not very “fun”. Very few new open source projects are written in Java — that’s not where the action is anymore. Likewise, PHP started out as a hobbyist thing but grew into a language used by Google, Yahoo!, and other big names on the Internet. PHP is where Java was a year or two ago. Python is where PHP was a year or two ago, and Ruby is where Python was back then.

With one company (Zend) dominating the community like they do, and with big companies using it, PHP seems to have become kinda “corporate”. Remember when your favorite band signed with a big label? PHP kind of did that. The indie fans who dug its original sound and obscurity have moved on to other cool & obscure languages. The sound changed, man. It used to be about the music, man, but now it’s all about writing songs for yuppies to listen to while they drink their lattes in their BMWs!

Ok, this metaphor is getting out of hand. But, you get where I’m going with this, right?

Ruby and Haskell are the big “indie” programming languages these days. The 20% kind of programmers see them pushing the boundaries and breaking us out of the C++/Java influenced paradigms which have dominated for more than a decade. They’re the programming languages of rebels…digital Che Guevara t-shirts, if you will.

Know what else they’ve got? Why the Lucky Stiff.

Why’s (Poignant) Guide to Ruby is a programming book, the likes of which I haven’t seen since Mr. Bunny’s Big Cup o’ Java back in ’99. It teaches the basics of Ruby programming through surreal cartoons, personal anecdotes (usually not about programming), and code examples. It’s fun, it’s catchy (chunky bacon!), and it’s unlike any book I’ve seen the PHP community produce. It’s even published online with a Creative Commons license, for that extra bit of indie cred.

Think what you will of a programming book written in this style, but you have to admit that it’s “out there”. It’s different, and that makes it attractive. PHP doesn’t have Why the Lucky Stiff. We have Zend. And, while I’m sure the Zend crew knows how to party, their website doesn’t reflect it. When you’re pushing a $250/seat IDE, it has to look attractive to the kind of people who cut checks to order $250/seat IDEs, not the kind of people who stay up into the wee hours of the morning learning new programming languages.

I’m not saying we should go out and steal this idea, but maybe ask ourselves why the PHP community doesn’t have a Why, and what might prevent us from having one in the future. If the answer involves the words “management”, “corporate”, or “inappropriate”, we’re doomed. Now that PHP 5.x is coming into it’s own, attention will be focussed on PHP 6.x for a glimpse of what the future holds. If PHP is to remain popular among the passionate programmers out there, it needs to catch up feature-wise. I, for one, dislike writing complex apps in a language that doesn’t have namespaces. It also needs to start pushing boundaries.

If PHP “sells out”, it wont mean the immediate death of the language, community, or even the job market — Java has proven that. But it will start it on the path of decline, and once you’re on that path it’s hard to get off it. We need to make PHP fun again. PHP needs chunky bacon.