The main difference between Perl and PHP, is writing maintainable, intelligent Perl is only slightly more work at first than writing horrible Matt’s Scripts style Perl. With PHP, writing decent PHP is possible, but it’s incredibly difficult. The majority of the PHP I’ve come across is code written by a web developer with no programming experience and the language design and direction accommodate that demographic. PHP’s language design gets in the way of writing sane, maintainable code. It’s not impossible, but you have to really, really want it.

When you write good Perl, the programming experience becomes easier, and more fun.

I’m trying to get back to my programming projects, and thus back to writing more on Perl. For now, understand that if you think Perl and PHP are the same beast, you’re wrong. I’ve been paid to develop both for periods of years. Perl is much more eloquent, evolutionary, and intelligent.

It all started with the concept of “Inside Out Objects” as a safe, functional object development methodology. From there a number of modules sprouted attempting to do Inside-Out better. Around this time, the Perl 6 Apocalypses were being published and translated in Conway’s Exegeses.  Conway  published “Perl Best Practices” and very soon after, Perl::Critic showed up on the CPAN to enforce the rules laid out in the book.  Perl::Critic became a critical authority on the most maintainable way to write Perl code.  TIMTOWTDI will never die, but clean, maintainable code does outweigh some stranger interpreter abuses.

The modern looking object system for Perl 6 made it debut, and instantly the Army of CPAN began figuring out clever ways to implement fancy object notation in Perl 5. his eventually led to the development of Class::MOP, from which the “post Modern Object System for Perl 5,” Moose, blossomed.

Concurrently, Ruby on Rails had layed waste to the entire scope of PHP Scaffolding systems in existence, building off the Model-View-Controller (MVC) Ideology implemented earlier in Perl 5 through Maypole. As RoR gained traction, Python’s Django framework, through it’s association with the MVC philosophy, began to see serious deployment. This made sense as a lot of large Open Source and Commercial companies were using Python for much of their behind the scenes development. The result left PHP staggering and dizzy in the corner.

Unfortunately, there was a horrible association of PHP to Perl in most people’s heads, which sounded the Death Knell for Perl as well. This wasn’t the case, as Perl, inside it’s mostly impenetrable Echo Chamber had not stagnated at all. Perl 5.8.x was a huge performance and syntactical modernization of Perl 5. This improvement was eclipsed with the release of 5.10, drawing from the Perl 6 Design Documents, and the push of the Echo Chamber for a more Modern Language.

The Army of CPAN was still hard at work in the background throughout all of this. ORM’s drawing on the Success of the MVC philosophy took shape and evolved. Rose::DB, Class::DBI, and the current forerunner DBIx::Class simplified database development through the use of abstraction through modules like SQL::Abstract. Maypole, an simplified, earlier implementation of MVC sparked other MVC efforts in Perl 5, the most popular of which are Catalyst, Jifty, and CGI::Application. Each have their strengths and weaknesses.

All of these modules are beginning to converge to create a beautiful, post modern web application development platform in pure Perl.  Additionally, projects like Strawberry Perl, and Padre are aiming to expand Perl’s reach into realms it’s shied away from: Windows & IDEs.  The future is bright for Perl thanks to efforts of countless volunteers and programmers.

Perl is dead.  Long live Perl.

To frame this, I just got back from YAPC::NA. I learned all kinds of new techniques and tricks from MJD, chromatic, brian d. foy, Randal Schwartz, Damian Conway, and countless other acquaintances. What’s not to love about Mason, DBIx::Class, and the brain bending functional tricks you can learn from MJD and chromatic? I never knew that @INC could contain a subroutine reference, did you? I also never thought of something so clever as recursively calling an anonymous sub ref contained in a scalar by using another anonymous subroutine that dereferences that ref at runtime.

So now, after refactoring a TON of my code to Perl Best Practices, I’m back into the land of PHP temporarily. Our administration group at work is looking for a project tracking system. After favorable experiences with dotProject a year ago, I suggested that. I hadn’t touched dotProject or PHP since dotProject’s 1.x branch. They’re now at 2.0.4 and it seems there just might be a few more hands in the pot. The code is not as coherent and refreshing as I remember it.

I’ve been spending time building a module for additional “fund” tracking. PHP seriously gets in my way. Granted, I have a very heavy bias against anything but Perl, but my god, there’s a reason why this Google Search exists. They’re not lying. I’m dealing with PHP4, so perhaps PHP5 has gotten better, but I harbor serious doubt that even by getting “better” that PHP5 would approach anything a serious computer scientist / programmer would consider usable.

The language is a patchwork of functions. There’s no real defining factor or consistency. As a matter of fact, the only thing consistent is the fact that regardless of what library in PHP you’re using, chances are the function names and argument orders lack consistency in that module and in the whole picture.

Don’t get me wrong, PHP is great for web designers and novices. There’s a very low barrier to entry. However, we now have a landscape littered with horrible PHP applications that expose servers to vicious attacks from outsiders. PHP is not by any means a language that should be taken seriously by any serious developer. Please invest your time elsewhere. I’d even recommend Python over PHP. Ruby would be a more worthwhile excursion.

PHP makes simple things simple and hard and obscure. Hard things are impossible. The biggest hole in the language from the perspective of a Perl or Lisp programmer is the complete lack of lexical scope. I know, inside of a function there’s a lexical scope, but it’s not really a lexical scope, it’s a hack. You have your choice between global scoped variables, or variables scoped inside of a function. No other closure provides an effective measure to force destruction and garbage clean up. More importantly, certain techniques become ridiculous without proper lexical scope.

Early version of PHP3, maybe even “late” versions, had no scoping even for functions. This became a problem to anyone used to using recursion to solve recursive problems. Recursion relies on the fact that each call to the function can resolve independantly of the rest of the call stack. Modifying variables that are still in wait on the stack can cause some “unexpected” behavior.

There also seems to be a problem with ternary operators. Unexplainably, if the false condition of a ternary construct is in itself another ternary, the false is evaluated. In order to “nest” ternary operators, you need to enclose each INDIVIDUAL ternary in its own set of parentheses. Find precident for that illogical BS. Why in the hell are we evaluating the false condition if the current ternary operator has returned “true” ?

It’s been a painful process, but in order to program in PHP, I’ve learned that you absolutely need a function reference. It is impossible for a human being to formulate a logical function naming convention (is it “noun then verb? verb than noun? do I separate with underscores, or just smash it together”?) let alone the argument order even inside the same “module”. Just peruse the function reference on the php.net site to see what I’m talking about. Zero consistency. Please, pick an interface and stick with it.

Bottom line, PHP is a good place to start, but don’t stop there. Pick up another language. I recommend Perl. I’ll even teach you. I’m gonna be teaching at NIH in the near future and I’ll be sharing my course material here.