Felix Crux

Technology & Miscellanea

Tags: , ,

Hector is a Literate Haskell implementation of Weizenbaum's ELIZA program.

ELIZA is more or less the original “chatterbot”. Implemented by Weizenbaum in the mid-1960s to demonstrate how seemingly “intelligent” behaviour could be mimicked by very simple pattern-matching, it shocked even him with how much ordinary people were taken in by the illusion. It is probably best known in conjunction with its DOCTOR script, which allows it to act like a Rogerian psychotherapist (a version of this can be invoked in the Emacs text editor with “M-x doctor”). One user was reportedly so affected by the program that he requested that Weizenbaum give him some privacy to discuss his issues with the doctor!

The program works by simple pattern matching. The user's input is checked against a list of pre-defined patterns, and if there's a match, a corresponding output is returned. Eliza also has some facilities for extracting content from the input and using it in the reply (e.g. “I need a vacation” might result in “How would you feel if you got a vacation?”). The final bit of finesse is a rudimentary memory, so that it can bring up past topics again if it doesn't know what to say (Hector does not do this).

Hector is a Haskell reimplementation of a very similar system. It is written in a “literate” style, and should be simple to follow along with. Hector is not a doctor like Eliza — instead, he's more of a grizzled old programming veteran, having got his start feeding punchcards into a mainframe in his undergraduate years. He can't help you with relationships or inferiority complexes, but he'll be happy to discuss your programming problems with you.


Tags: , ,

Doug Crockford gave a talk at the University of Waterloo last night as part of the Yahoo! Hack-U (University Hack Day), on the same topic as his new book, JavaScript: The Good Parts. I was lucky enough to get a seat, and have tried to condense my nine pages of notes into an overview of the highlights of his talk. Though I've rewritten parts, all of the content and wisdom is Doug's — I'm just the humble scribe. Of course, any errors of transcription are mine.


Tags: , ,

Makefiles are the granddaddy of build systems. Though falling out of favour relative to more modern systems like SCons and ant, make is still the lingua franca of software builds, particularly in the C and C++ parts of the open source world. Because of this, it is imperative to have at least a basic understanding of makefiles and their use.

There are plenty of tutorials introducing the fundamentals of makefile syntax, and a handful that show off some advanced features. There are very few, however, that actually show how to write a useful makefile, or that introduce makefile conventions and patterns. For me, this meant that writing makefiles became an arduous process of stringing together snippets from various places, and hoping they interoperated harmoniously. Frustratingly, I'd often learn of a new feature months later and rip out half of the file and replace it with a single line. Worst of all, I had no idea if what I was doing was “conventional” or even passable as a serious makefile.


Tags: , ,

So the W3C has officially ceased work on the next iteration of the XHTML standard, abandoning it in favour of the new and shiny HTML 5. I have some mixed opinions on this, since the simplifying purist in me likes the consistency and rigour provided by XHTML, but HTML 5 appeals to my more pragmatic instincts. HTML 5 also has support for a slew of nice semantic tags, like <section>, <article>, <header> and <footer>, which should make it easier and cleaner to style documents according to their content, and do away with the ubiquitous <div id="blogpost"> constructs that currently make up most sites.


Tags: , ,

I am afraid that I have to admit that the development of this site has until now proceeded in what any programmer must consider a state of sin: it was not under version control. Sure, I had periodic snapshot backups, but forget about versions, branches, and reverts.

The reason for this is that I was under the mistaken impression that my VCS of choice, git, made it difficult to set up remote branches. I think my confusion stemmed from the fact that it is somewhat tricky to set up public-facing ones with good commit-access control etc (which is why GitHub is so great).

Now that I looked into it more, I find it's actually tremendously easy, and I've got a really great work-flow set up: I have a master repo on the server, a development repo on my laptop, and another one in the directory from which the site is served. I can make changes on my laptop (and thanks to the magic of makefiles and m4 macros, keep a separate dev config file), and then push those to the master repository. When I'm ready to launch, I just pull them to the serving repo and run a make prod.