There's a photo of mine in the September 2010 issue of Popular Photography. I'm excited about it; my photo credits are few and far between, and it brings back the feelings I had when I wrote for magazines long ago. Completely ignoring the subject of the image, there are couple of surprising facts about it.

The first is that it was a taken on a circa-2004 Canon PowerShot G5, a camera with a maximum resolution of five megapixels.

The second is that it's a doubly-compressed JPEG. The original photo was a JPEG, then I adjusted the colors and contrast a bit, and saved it out as a new JPEG. Each save lost some of the image quality. I was perfectly willing to submit the adjusted photo as a giant TIFF to avoid that second compression step, but was told not to worry about it; the JPEG would be fine.

Yet there it is: the five megapixel, doubly-compressed photo, printed across almost two pages of the magazine. And those two technical facts are irrelevant. I can't tell the difference; it looks great in print.

Now it is an impressionistic shot, so it could just be that the technical flaws aren't noticeable in this case. Fortunately, I have another anecdote to back it up.

Last year I was in New Mexico and took a lot of photos. After I got back home, I decided to get a few photo books printed. The source images were all twelve megapixel JPEGs, but the book layout software recommended a six megapixel limit. I cut the resolution in half, again twice-compressing them. When I got the finished books back, the full-page photos were sharp and beautiful.

The standard, pedantic advice about printing photos is that resolution is everything. Shoot as high as possible. Better yet, save everything as RAW files, so there's no lossy compression. Any JPEG compression below maximum is unacceptable. Double-compression is an error of the highest order, one only made by rank amateurs. And so it goes. But I know from personal experience that while it sounds authoritative, and while it's most likely given in a well-meaning manner, it's advice that's endlessly repeated in a loose, "how could it possibly be wrong?" sort of way and never actually tested.

I've mentioned before that this site is generated by a small Perl script. How small? Exactly 6838 bytes, which includes comments and an HTML template. Mentioning Perl may horrify you if you came here to read about Erlang, but it's a good match for the problem. Those 6838 bytes have been so pleasant to work on that I wanted to talk about them a bit.

I've used well-known blogging applications, and each time I've come away with the same bad taste, one that's caused by a combination of quirky rich formatting and having to edit text in a small window inside of a browser. I don't want to worry about presentation details: choosing fonts, line spacing, etc. It's surprising how often there are subtle mismatches between the formatting shown in a WYSIWYG editing window and what the final result looks like. Where did that extra blank line come from? Why do some paragraphs have padding below them but others don't?

I decided to see if I could bypass all of that and have a folder of entries marked-up with basic annotations, then have a way to convert that entire folder into a real site. And that's pretty much what I ended up with. The sidebar and "Previously" list and dated permalink are all automatically generated. Ditto for the atom feed and archives page. The command-line formatter lets me rebuild any page, defaulting to the newest entry. If I want to change the overall layout of the site, I can regenerate all of the pages in a second or so.

There are still legitimate questions about the path I chose. "Why not grab an open source program and modify it to fit your needs?" "You do realize that you decided to write an entirely new system from scratch, just because you didn't like a few things in existing programs; surely that's a serious net loss?"

My response is simple: I did it because it was easy. If I get annoyed with some feature of Microsoft Word, I'm not going to think even for a second about writing my own alternative. But the site generation program just took a bit of tinkering here and there over the course of a weekend. It never felt daunting. It didn't require anything I'd label as "engineering." I spent more time getting the site design and style sheet right, something I would have done even if I used other software.

Since then, I've made small adjustments and additions to the original script. I added the archive page nine months later. Earlier this year I added a fix for some smaller feed aggregation sites that don't properly handle relative links. Just today I added mark-up support for block quotes. That last one took ten minutes and four lines of code.

If this suddenly got complicated, if I needed to support reader comments and ten different feed formats and who knows what else, I'd give it up. I have no interest in turning these 6838 bytes into something that requires a grand architecture to keep from collapsing. But there's some magic in a solution that's direct, reliable, easy to understand, and one that fits my personal vision of how it should work.

(If you liked this, you might like Micro-Build Systems and the Death of a Prominent DSL.)

In One Small Step Toward Reducing Programming Language Complexity I added "Who even knows what "\v" (vertical tab) does?" as an off the cuff comment. Re-reading that made me realize something that's blatantly obvious in retrospect, so obvious that I've gone all this time without noticing it:

No one is actually using the vertical tab escape sequence.

And I truly mean "no one." If I could stealthily patch the compiler for any language supporting the "\v" escape so I'd receive mail whenever it occurred in source code, then I could trace actual uses of it. I'm willing to bet that all the mail would come from beginners trying to figure out what the heck "\v" actually does, and then giving up when they realize it doesn't do anything. That's because it doesn't do anything, except with some particular printers and terminal emulators, and in those cases you're better off not relying on it anyway.

And yet this crazy old feature, one that no one understands or uses, one that doesn't even do anything in most cases, not only gets special syntax in modern programming languages, it's consistently given space in the documentation, even in tutorials. It's in the official Lua docs. It's in MIT web course notes about printf. It's in the books Programming in Python 3 and Python Essential Reference. It's in an introduction to Python strings. It's in the standard Erlang documentation, too.

[Insert conspiracy theory involving the Illuminati here.]

Here's my simple plea: stop it. Stop mentioning vertical tabs in tutorials and language references. Drop the "\v" sequence in all future programming languages. Retroactively remove it from recent languages, like Python 3.0. Yes, ASCII character number 11 isn't going away, but there's no reason to draw attention to a relic of computing past.

Surprisingly, the "\v" sequence was removed from one language during the last decade: Perl. And even more surprisngly, there's a 2010 proposal to add escaped character sequences, including vertical tab, to the famously minimal language, Forth.

(If you liked this, you might like Kilobyte Constants, a Simple and Beautiful Idea that Hasn't Caught On.)