I wrote a blog.

As previously promised, the new Tar Pit¹ is almost done. It's not quite there yet, and considering the usual pace of the blog's affairs, it might take a month or two before it goes online -- besides, the non-technical reader will experience virtually zero change in reading experience; so I dare guess that this news isn't even that interesting. However, I wrote a blog! and despite this development having begun before the initial announcement, and despite its duration of a few additional months, it has all gone in perfect accordance to the initial plan.

Given all this, and moreover, given this rare occasion of working with sane tools² I feel compelled to share my experience with the reader and do some post-design examination on the topic.

First of all, the Tar Pit Lisp Blog Scaffolding (LBS) is based upon a fundamental data structure, which I have at some point uninspiredly decided to name blist³. A blist is conceptually very similar to a dynamic symbol table, that is, a binding between a name and a value. Almost everything from blog posts to templates to tags are representable as blist objects, and thus all that the LBS needs to do is convert source objects such as Markdown files or CL-WHO templates into this intermediate representation, and then forth into the target representation, which in our case happens to be plain ol' HTML.

This approach has the advantage of uniformity: metadata (e.g. post identifiers, the author(s), the date of publication) as well as the actual data (e.g. post content) are all represented using the name-value associations within a particular unit, e.g. a post or a page. Given this, the blog programmer is left with no option but⁴ to manipulate blists as he or she wishes, for example by translating the body from Markdown to HTML or generating a whole new body based on existing metadata, such as for creating lists of references.

The heavy lifting is of course still done by CL-WHO and Pandoc, with some help from CL-PPCRE and some other useful bits which help keep the whole castle in one place. And despite the system's heterogeneity, the design is anything but a mash-up of arbitrary tools.

As far as development effort goes, I believe the whole thing took much less than fifty hours of implementation put together, plus around ten hours of thinking and reading the imported libraries. In fact most of the time went into learning Common Lisp⁵, debugging and testing being a close second and actual writing and refactoring occupying a third place.

The close-to-final result is publicly available on GitHub -- for now on a separate branch, but I expect it to converge towards the master as soon as I deem it to be ready for use in production. And make no mistake, "ready for use in production" is equivalent to "done", not unlike Roman aqueducts, the Great Wall of China and Shakespeare's works are "done"⁶. And when it's here, you'll see it -- soon!