what's right vs what works
I seem to revisit this topic from time to time. Usually in the context of trying to struggling through someone else’s code.
Now, the standard disclaimer: I am not a programmer. Or, more accurately, I don’t write code for a living. (We are all programmers now, are we not?)
But I continue to struggle with the ‘right-thing’ vs ‘worse-is-better’ debate. On one hand is the fact that I learned how to code of textbooks, and the readability of code had high priority. Clean algorithms and appropriate commenting (enough, but not too much) naturally leads to readability (or so they say), and also make maintenance less of a chore.
On the other hand, no one likes vaporware, which is what following the ‘right-thing’ philosophy frequently leads to. Witness the GNU/Hurd, for example.
But the history of information technology has many examples of ‘the right-thing’ pitted against ‘worse-is-better’. Mac OS vs MS-DOS. Pre-emptive multitasking vs cooperative multitasking. RISC vs x86. HURD vs Linux. GNOME vs KDE. Lisp vs C. C vs Java. ObjC vs C++. The list goes on-and-on. If ‘worse-is-better’ wasn’t a winning ticket, Microsoft would’ve gone bankrupt decades ago.
Why do I wax philosophical?
I’ve stared at the monolith codebase known as Wordpress and have fled in fear and horror.
Oh, Wordpress works, all right. I’ve been running it for several iterations now, for well over a year. But all I wanted to do was write a simple custom theme.
Horror of horrors.
The thing that I like about my kludgy XSLT/Makefile/perl script homebrew, and what I liked about Blosxom (after you installed the ‘theme’ plug-in) was that it was trivial to convert an XHTML design into a blog template. Throw in a few conditional statements here, a few variables there, and voila, you’ve got yourself a theme.
Screwing around with Wordpress is a little more involved than that.
For one thing, the template is strewn across multiple files (which was something that I loathed about Blosxom without the ‘theme’ plug-in) Sure, at the bare minimum, you could get away with just style.css
and index.php
, but then it gets kind of ugly, and most sane people include header.php
, sidebar.php
, and footer.php
as well. Not to mention comments.php
. I’m sure there are a few more I’ve forgotten to mention, but I’d rather not wade through lines of PHP right now.
For another thing, I find PHP aesthetically displeasing. It can’t seem to decide whether it’s a templating language (like the Perl Template Toolkit, MASON, or XSLT) or if it’s a full on scripting language like Perl, Python, and Ruby. And the syntax shows it.
For some reason, I really detest nested angle-brackets. I can’t stand stuff like this:
Call it a pet-peeve. Call it psychosis. Whatever. But this is common practice in PHP, and it makes me feel the same way that scratching fingernails across a chalkboard does.
But the scripting/templating schizophrenia makes reading code a chore, and it has taken me a good while to follow the logic of the templates themselves, much less actually understanding the functions I’m supposed to call.
Now the functions. Ugh. To be fair, Wordpress has existed in several incarnations, previously known as b2 which was released back in 2001. Since it’s debut as Wordpress in 2003, the code has gone through 2 major revisions and several minor revisions. The latest iteration is version 2.2. It’s extremely popular and many webhosts have it installed for your immediate use.
Digging into the code, you can almost see the different layers, kind of like an exercise in paleontology. Strata after strata of heaped-on code. Lots of inadvertant redundancy.
The thing that started driving me crazy was that there were functions that returned actual values, and functions that sent direct output. Some of them followed a certain convention. (If there was a function x()
that displayed output, then usually there was a function get_x()
that would return a value.) But God help you if the function you wanted didn’t follow that convention. Usually there is no recourse but to read the source code itself, which can get tedious, to say the least.
At first, I started mucking around with the template code just so I could understand the logic. For one thing, the way PHP can switch in and out of templating mode confused me (and, in all honesty, continues to confuse me, even though I know it really shouldn’t be that confusing.) For another thing, I wanted to see if I could get rid of the nasty nested angled brackets. I’m slowly finding out that this is almost, but not quite, feasible.
But before I realized the futility of separating code from presentation, I had this grand scheme of building a template engine, such that you only had to change one file to customize a template rather than screwing around with all these subfiles. One include
and I could be home free and have customizability galore. But wp_query
stopped me cold in my tracks. I would have to learn Wordpress’s object classes and methods. Shudder.
So on one hand, I could just give up and stick my HTML into the proper places in the template code, and give up on readability. As long as it works, what do I care, right? On the other hand, it’s clear that, short of complete rewriting the codebase (I never did like the reliance on a SQL database, and I might as well rewrite it in Perl or Ruby if I’m going to do something insane like that), I’m not going to find the Holy Grail of easy template editability. It may be time to move on to yet another blog engine. Or chase that unicorn of writing my own. Double-shudder.