I don’t know why, but suddenly I had the urge to try yet another blog engine, even though I haven’t really hacked into SimpleLog’s internals and given customization a chance, which was the whole point of using it.

The first thing I did was search through freshmeat. I found a few blog engines that hit all the right buzzwords for me, and which sound intriguing. One of the cleaner looking ones is Bloo—it’s new, it looks simple, and it’s based on a PHP framework(!) which is object-oriented. The other one that sounded interesting is minb, which does not need a db, and uses XML as its storage model.

The thing that made me hesitate—a lot—was that they’re both written in PHP.

PHP is a kludge

Don’t get me wrong. I admire a good kludge when I see one. And PHP is certainly one of the biggest, most successful kludges out in the world today. (Although, granted, it is certainly cleaner than Perl/CGI, but that’s another rant entirely.)

But I’m a guy who does other things than code. Kludgery is always good for the one-off. But it’s terrible for maintenance, and it’s terrible when you want to actually learn how to code properly.

I don’t have anything against PHP necessarily. It’s just that my first direct interaction with the stuff was a Bad Experience™.

Wordpress gives me the heebie-jeebies

Now granted, Wordpress is good at what it does. It is the most widely deployed Open Source blog engine, and in 2007, it seems to be more ubiquitous than even Blogger and Movable Type.

But if you ever want to get Wordpress to do something a little different than usual, beware.

I used Wordpress from February 2006 to June 2007, having moved from Blosxom. But what made me jump ship was my problems with themes.

Frankly, most of the Wordpress themes look extremely crappy. I can’t believe that, in this day and age, people are still doing fixed-width designs. (I guess I should be happy they’re no longer using tables.) Or the designs are too noisy, too crowded. Three columns, with more of the look of a web forum or a Slashdot-clone, than that of a personal journal. And the ones that look good and are innovative (the Hemingway theme comes to mind) are mindlessly copied ad infinitum.

Which in itself is not a problem. Nothing that a good text editor and some XHTML/CSS can’t fix.

But then I found myself wading through hundreds of lines of PHP embedded within the themes. Maybe this was just an abberation. But I looked and looked, and found that Wordpress seems to be anti-encapsulation. A theme developer is forced to put business-logic in their theme.

I Can’t Help It, I’m an Artist

Now I don’t know why I’m so against nested angle-brackets. I get the shivers whenever I see a bit of code like:

<a href="<?php displaylink[x]; ?>" title="<?php displaylink_desc[x]; ?>"> <?php displaylinklabel[x]; ?></a>

Now maybe I just need to configure my copy of Emacs better, but it sometimes drives me nuts when I’m missing a closing angle-bracket, because Emacs doesn’t care about tags that are embedded in quotes.

But nested angle-brackets seem to be a characteristic of PHP, and try as I might with assigning commonly used functions to variables, I couldn’t eliminate every instance of code sitting inside the design.

I gave up.

OOP. Bright and Shiny.

Now I realize that Wordpress is just badly coded. Sure, it does what it’s supposed to do (most of the time), but trying to change anything is an exercise in frustration. There are redundant sets of functions (one for display, and one for assigning to a variable), the code is pretty much spaghetti, and a lot of things just don’t make a hell of a lot of sense. I realize that the spaghettification of Wordpress has a lot to do with it inheriting a really old codebase, which was written in a now-deprecated (although still widespread) version of PHP.

At the same time, I was learning about the new darling of the Open Source world: Ruby (not to be confused with its even more popular framework, Rails)

I’ve always been intrigued by object-oriented code. I like the idea of mapping code to real world objects and processes. I suspect that true AI systems will require an object-oriented implementation, because human brains seem to function in an object-oriented manner. (Don’t ask me for evidence on this one. It’s just my intuition from studying both neuroscience and computer programming.)

My interest in OOP also lies in the fact that I’ve been running Mac OS X for the past few years and the entire system is based on OOP (Objective C, to be precise.) The most interesting thing that Objective C and Ruby have in common is that they both borrow from Smalltalk, the language developed by Xerox, which is the company that spawned the whole GUI revolution. (OOP and GUIs seem to go together so naturally, its amazing that there are actually few instances where the two are intertwined.)

Smalltalk seems like a cool idea that was just too ahead of its time, and even Xerox didn’t have hardware that could run it at a usable speed.

Long story short, I ended up jumping on the Rails bandwagon. I’ve tried Typo, I’ve tried Mephisto, and now I’m using Simplelog.

“Slow and Easy” beats “Fast but Arrogant”

The thing with Ruby (without and with Rails) is that “I just get it.” Like I said, I’m not a professional code monkey. I just do this for fun, even though I’ve been screwing around with computers for more than 20 years now. I found C difficult. I found C++ more bearable because at least it had the C++ standard library, although ironically I never got the hang of the object-oriented side of things. I found Perl and specifically TMTOWTDI refreshing, and for the longest time, I didn’t use anything else.

But, while it’s really easy to write one-offs in Perl, it isn’t always the easiest to comprehend.

This is what makes Ruby different.

I can look at a piece of code and figure it out just by looking at it, fast. It’s such a different experience than when I’ve used other languages. For me, it’s like the difference between moving my lips while reading and sounding things out phonetically, and comprehending entire words and sentences at once.

And while a lot of this magic is Rails itself, it seems to pervade the entire language. Because Rails doesn’t just hide the messy internals from the naive programmer. If you really wanted to, you could look at the Rails code itself, and you could probably figure out what it does just as quickly.

Grrr.

Which leads me to this entertaining reactionary rant from a PHP guru directed against Rails fanboys that I found on Google while trying to look for more blog engines.

Now, maybe the underlying tone is purposefully, ironically, full of piss and vinegar, to match the caustic feel of the “Fuck You” slide from the Rails talk that he cites. Still, it sounds a lot like some wimpy Asian geek who just managed to pwn you on Counterstrike and who keeps rubbing it in, talking shit.

And I totally understand the reaction to abject fanboyism. Back in the day in the late ‘90s, I had it in for the Mac fanboys (despite eventually converting to Mac fanboyism in 2002.) But at the same time, I can’t stand Microsoft butt boys, and the Rails fanboyism can be cloying.

And Chay’s rant stinks of PHP fanboyism.

I recognize that PHP runs a lot of the web (which is what Perl used to do back in Web 1.0) But the fact that the most popular sites, and the biggest site in the world—Yahoo—runs PHP is mere accident of time and implementation. If Yahoo (and the Web) had been built earlier, it might have been scripted in Lisp or even Smalltalk for all we know. If it was just being written now, maybe Haskell or Erlang might be the magic language. (I mean, just think how fast Yahoo would be if it were fully parallelized in Erlang?)

And the idea of not using frameworks sounds ludicrous. While we may have hit the quantum mechanical wall when it comes to CPUs, there is still a lot of optimization possible with memory buses, with storage media, with network switches, with data transmission technology. Some day the performance optimization you did in PHP will not matter a damn, and the time lost trying to decipher your kludge is going to cost a lot.

Not using a framework is like coding in C++ without using the standard library, or coding machine language by hand instead of using an assembler. Maybe it executes faster. Maybe it performs better. But there’s a terrible cost in maintainability.

The Road to the Future has a lot of speedbumps

I know first hand what a pain in the ass Rails. Even though my blog has like one reader, it used to crash and give 500 errors quite regularly. Some of this, though, is the fact that my webhost isn’t really optimized for Rails.

And without caching, it’s slower than molasses. It might take a full minute to render a page, which is rather pathetic.

But the quickness by which I can comprehend the code and customize it to my liking is worth it. Someday, it will not be slow, without me changing or optimizing a damn thing.

Sure, there is indeed merit in living in the present, and dealing practically with problems. Sometimes all you need is a piece of duct tape, and PHP is a lot like duct tape. If your paycheck is entirely dependent on your coding skills, and you know PHP like the back of your hand, of course it makes sense to deploy it. Your employers are paying you to fix problems, not to create aesthetically pleasing pieces of code.

But to ignore the future is slitting your own throat. Someday, the 9 year old script kiddie who is screwing around with [Scratch][14] today is going to be kicking your ass around the block with apps written in two or three lines of code in the Next Generation Programming Language, built on top of the Next Generation Framework, and it’ll perform just as well or better than any soon-to-be obsolescent PHP kludgery you’ve written today and have tons of new features.

I agree that Ruby and Rails is not the end-all-be-all of Web 2.0. In the end, it’s going to be a stepping stone to Web 3.0. But I guarantee that five years from now, the paradigm represented by PHP is going to be long-dead, and if you don’t move on to Bigger and Brighter Things™, you’re going to find yourself unemployed.