craven.fr (.ox.ac.uk)

It's been ten years since I wrote my Programming Language Timestamp, a sort of time capsule of how I felt about the various programming languages I used, or used to use, at that moment in time.

Ten years is a long time, and I no longer write code professionally. So while a major theme of my 2006 article was making the transition from university—where I focused on intellectually interesting languages like Lisp and Prolog—to the working world, dominated by Java, the major themes in 2016 can be enumerated as follows:

• I have a lot less time to program, between a non-technical day job and having kids
• The languages I use have a lot more to do with what I'm comfortable with, than what I think is ideal.

So, without further ado, here are the languages I use now, in order. The reality is far from my ideals, but this is what life getting in the way looks like.

1. Perl. The Swiss Army Chainsaw is today far from the dominant scripting language it was when I learned it in high school. And rightly so. It's a mess, the primary merit of whose syntax is that there's a perverse pleasure in producing code that, to the non-initiate, looks absolutely incomprehensible. (Like this gem from one of my recent scripts):

while (<>) {
    s/&/&amp;/g;
    s/>/&gt;/g;
    s/</&lt;/g;
    if (m/^\#(.*)$/) {
        $comment .= "$1\n";
    } else {
        m/(^.+?)=(.*)$/;
    ...

The thing is, I learned Perl so well back in the day, and it's so useful for text processing, that I still end up using it all the time. (Another big factor was that I was able to install it without admin privileges, which I don't have at work, so I have access to it whereas I do not have access to a JDK.) The idealist in me would prefer to be using Guile as my scripting language, and I'd recommend others learn Rexx or, most obviously, Python, rather than Perl, but Perl is what I know, so that's what I use.

2. Java. Java, formerly my bread and butter, is still what I turn to for anything requiring libraries (I never really got confortable with Perl modules but I know the Java world inside and out). It also powers all my web-based projects. Thus it holds on to the number two spot fairly easily even though I'd in theory like to be moving away from it, in favour of...

3. Clojure. I've written about Clojure on here a couple of times. I'm still bullish on the language: if I can do Lisp and still have access to all the Java world I know so well, it should be perfect for me. But I just haven't had the time to build up the language knowledge and the workflow for it to become that go-to language. It's definitely my programming skill priority—it's just that I have so little time to consecrate to improving my programming skills these days.

4. VBA. Sadly, it might have been more honest to list VBA ahead of Clojure and maybe even Java, but I just can't stomach the thought of that. Working in an office job with Excel as your tool though means that macros are often the only programming option available (if I need to share the functionality with others; if it's just for me I can and will use Perl instead). But to say that it's not my favourite language or first choice would be an understatement.

5. Python. Wait, didn't I already explain that I don't need Python for anything, since it doesn't bring anything useful to the table of someone who's already mastered Perl and Java? That's true, for me, but if I were starting over from scratch, Python is the most logical choice as an easy programming language to familiarise oneself with, that has huge library support, and can scale to larger projets more elegantly than Perl can. I don't use it because I'm not starting from scratch.

But my son is. I owe a great deal to my father teaching me BASIC on the Commodore 64 back when I was in grade school, so I certainly want to give my own kids the same advantage. And while his first taste of programming came in the form of a game we worked on together in Clojure, that language is probably a bit too dense for a first introduction to writing code. So I've bought him a fun and colourful book aimed at teaching kids to code, and it uses Python, which I agree is an excellent choice. So in guiding him through that I'm starting to get my toes wet with that language as well, although I don't think I'll ever do more with it than help him debug his code.

And that's about it. As in 2006 I don't really consider things like SQL, bash, HTML, or Javascript "programming languages", so although I still regularly use them I won't list them here. And I've dabbled in Lua, Objective C, and newlisp, and thought about learning assembly for real, but those just aren't likely to get much attention going forward if I'm being honest. Hopefully in 2026 when I next do this exercise (don't hold your breath, but I wouldn't have guessed the site would still be here ten years ago either), by then Clojure will have moved up the list, but apart from that, it looks like I'm getting set in my ways. I think I feel middle age creeping up...

αὐτὸς [Ζεὺς] δ᾽ ἐκ κεφαλῆς γλαυκώπιδα Τριτογένειαν
δεινὴν ἐγρεκύδοιμον ἀγέστρατον ἀτρυτώνην
πότνιαν, ᾗ κέλαδοί τε ἅδον πόλεμοί τε μάχαι τε,
Ἥρη δ᾽ Ἥφαιστον κλυτὸν οὐ φιλότητι μιγεῖσα
γείνατο, καὶ ζαμένησε καὶ ἤρισε ᾧ παρακοίτῃ,
ἐκ πάντων τέχνῃσι κεκασμένον Οὐρανιώνων.
Ἥρη δὲ ζαμένησε καὶ ἤρισε ᾧ παρακοίτῃ.
ἐκ ταύτης δ᾽ ἔριδος ἣ μὲν τέκε φαίδιμον υἱὸν
Ἥφαιστον, φιλότητος ἄτερ Διὸς αἰγιόχοιο,
ἐκ πάντων παλάμῃσι κεκασμένον Οὐρανιώνων.

Hephæstus is one of my favourite figures in Greek mythology, not only for his qualities, which any programmer or maker of things is bound to feel an affinity with, but also for the fascinating character dynamics surrounding his forced marriage to Aphrodite.

Until I read this passage, though, I hadn't really paid any attention to the manner of his birth, which in Hesiod's version presents quite a few interesting character dynamics itself. Of course the tension between the philandering Zeus and Hera, goddess of marriage, is well-known, but in the context of the theogony, where the Olympians are just taking their places on the scene, Hera is wife number seven, and her rôle as the defender of matrimony had not yet taken root. It doesn't take long for the quarreling to start, though: Zeus, having swallowed the pregnant titan Metis to avoid the prophesy by which any son she fathered would have a weapon stronger than the thunderbolt (and thereby overthrow Zeus), gives birth to Athena out of his own head. Having children without recourse to his wife makes the latter furious—that's her job!—and so to get even, she fathers Hephæstus without recourse to him. (Note that this differs from Homer's version of events.)

I suppose that Zeus still comes out ahead in this little battle of asexual reproduction, both because Hephæstus came out deformed, and because Athena was viewed as a far more important deity in the Greek pantheon. But it's an interesting link between the two, all the more so since they have such similar rôles, in terms of teaching men how to do things (in the form of wisdom and strategy with Athena, and technology and implementation, for Hephæstus). By all accounts, Athena and Hephæstus got on reasonably well, so even though with their birth stories one might have imagined they would become rivals, it seems instead to have created a sort of bond between them, even though technically they are not even half-brother and sister.

I've really been enjoying the latest Hitman game, and wanted to share this hilarious video about it, but unless I supply a little context, it won't make sense to those unfamiliar with the game.

The game involves piloting your square-jawed, bald hitman, naturally enough, through assassination missions (the game story gives you good justification of what bad people your targets are, to make the setting somewhat less gruesome), but it is not an action shooter. Your targets are in highly guarded locations and simply pulling out a gun in the open is usually enough to fail a mission. Instead, the game boils down to stealth, creativity, and disguises.

You observe, you eavesdrop, and when the opportunity strikes to sneak up on a waiter or security guard without being seen, you can knock them out, and put on their outfit, granting you access to areas you previously couldn't enter without attracting suspicion. The environments are very interactive, and the best assassins will manage to off their target without ever alerting the guards, and in such a way that the death appears accidental. You then disappear into the night, with no one ever the wiser.

At least, that's how it's supposed to go. But for those looking for an extra challenge, the developers have added an unusual twist in the form of a disguise hidden in a hard-to-access attic.

The vampire magician.

Whereas most disguises lower your suspicion in different areas (dress like a cook to blend in the kitchen, where you might poison the food being prepared, or dress like a security guard to access the security monitors and turn off a camera), there is nowhere on earth you can go where being dressed like a "vampire magician" will not arouse suspicion! The video below shows some of the hilarious reactions that you can arouse when wearing this ridiculous outfit. (It also gives you an idea of how elaborate this game is; if there's this much dialogue for a costume most people will never find, you can imagine how vast this game is.)

If you're interested in a more in-depth look at what this game is like Giant Bomb's videos on it are very entertaining (explicit language warning).

I was curious about finding the answer to this rather basic (but just as inconsequential), question (also an obsolete one, in this day of smartphones). At any rate, I was only able to arrive at an answer by piecing together information from a variety of sources. So, to make things simpler for anyone else who ever wonders the same thing, I'm putting up my answer here. It's a deduction, so I may be wrong, but it makes enough sense that I'm fairly confident in it.

The first thing to be clear about is the purpose of the two buttons, which we so rarely use. Interestingly, the engineers who designed them weren't entirely sure what they would be used for, either, but they could anticipate that they might be necessary for some future type of telephone-computer interaction, and toured a number of businesses canvassing for ideas about what applications they might develop and what they would need. They did know that the phone company would be implementing vertical service codes, which were distinct from phone calls and would require a special prefix. They could have defined a reserved numeric prefix (like the later infamous 10 10 numbers), but using the * key turned out to be more pragmatic. (I still remember the *67 and *69 VSCs from my youth.)

The biggest use of having a non-digit input was that it enabled input of variable-digit sequences in applications, such as a conference id, or to allow more then ten choices if you need them for a voice menu (and I pity you if you do). By ending with the # key, the system can distinguish 1 from 10 and know when you've finished making your choice.

I knew that much, but what irked me is why there had to be two symbols. Neither one of the two uses for the keys requires the use of both of them, so what's the point of making two?

The answer lies in the way the touch-tone system was built, a system called dual-tone multi-frequency signalling (DTMF). Unpacking the name, there are two tones that are sent simultaneously with each key press (a low tone and a high tone). Since it would have been science fiction in the 1960s to use a microprocessor to emit the proper tones, the solution had to be built using basic electronics. And, the elegant way to do that (once ergonomic research, and the need to maintain the rotary phone's alphabetical order, had dictated that a 3-row square of digits was the layout to use), was to have the row of the keypad determine the low tone and the column to determine the high tone. So voilà, the first touch-tone phones had a layout that looked like this:

So, pressing 5 generates a tone at 1336 Hz and 770 Hz, etc. But what any efficiency-minded engineer notices is that the 941 Hz tone is underused, serving only for 0. So this is the key reason why two function keys were added: it didn't cost anything in terms of complexity to do so: there were essentially already two unused buttons built in to the system. If there had been an added cost to adding two keys, the need would have had to be justified and perhaps they wouldn't have been implemented. As it was, since they were revisiting the original design anyway, they already had cause to want to future-proof things. So in fact, it isn't so much that they needed to add * and # to the keypad, it's more the case that they were essentially already there. (In fact they added not two function keys but 6, adding a fourth column with keys A-D at 1633 Hz which was only ever used by the military, to set call priority. Again, the choice brings symmetry, since there are 4 rows and 4 columns in the full design, and no leftover unused frequency pairs.)

And, in point of fact, having two function keys would have allowed some large organisations to implement their own, internal vertical functions, prefixed with the # key, while still allowing access to the phone company's VSC's on the star key. (In practice large organisations would use a PBX which probably wouldn't allow direct access to the external telephone network anyway—as anyone who remembers dialing 9 before making an outgoing call from their hotel room would well remember.)

As for why the symbols * and # were chosen, it seems largely to do with their familiarity, since standard typewriters had them, although if they had only chosen @ instead of *, as they might well have done, we would have had an uncanny precursor to Twitter!

Oriel College, of which I am proud to be a member and to which I have donated annually since graduating, recently announced, and today backed away from, "a listening excercise seeking the views and ideas of a wide range of groups" regarding a petition the college has received for the removal of its statue of Cecil Rhodes. I am publishing my views here as well (because I am interested to hear what others think of them), and because I have already written favourably about the statue in the past, before any controversy had arisen.

The sad irony is, that the whole reason I've always loved the Rhodes statue is because Rhodes' legacy is one that defies simplistic appraisal. (Or so I always thought!) It's intellectually challenging. On the one hand, you have an outstandingly generous philanthropist, on the other, a ruthless colonizer. Yet the colonial legacy in Africa is less ruthless, in fact, than in America or Australia (if the extermination of native populations is what we measure by). On the one hand, you have an astonishingly successful business man, on the other hand, an arrogant racist. Yet his views were widely held at the time, so why single him out for being a product of his time and place?

Most challenging of all is the legacy of Rhodesia. Is it a racist, oppressive legacy, that deserved to be destroyed? On the surface, anyone with left-leaning views would have said so. Certainly at the time of the Bush War it seemed clear which side held the moral high ground, from afar. And yet, anyone who thinks that Rhodes' treatment of Africans in his day was appalling should read a bit about what life is like for many in Zimbabwe right now. This is not about abstract ideology, this is something that profoundly affects the lives of millions of people. It is impossible to argue, I would submit, that the country is better off for having been ruled by the anti-imperialist Mugabe, than it would have been had it continued as Rhodesia. For all inhabitants. The fact that black Zimbabweans would have been better off had they remained under white rule, even though white rule was patently immoral and unethical, is a hard paradox to reconcile.

Nelson Mandela, of course, understood this paradox profoundly, and was able to chart a way forward from it. It is thanks to the fact that he did that South Africa has not become another Zimbabwe. And, with regards to Rhodes' legacy, not only did Mandela not fight to erase it but actually added his name to it, via the Mandela Rhodes scholarship. Sadly, today, with movements like Rhodes Must Fall, and the push to marginalise the Afrikaans language (the majority of whose speakers are not white), there are signs that South Africa may be heading down the path of Zimbabwe now.

To say it straight, the rigid groupthink calling for the removal of the statue is uncritical, blind to historical context, and wrong.

Take for a moment the contrary opinion that they are right. There is no reason why a rigid standard of contemporary political correctness should stop at Rhodes' statue. What about the chapel? ("Offensive to non-Christians") What about the Codrington library? ("Built by a slaver") What about the Queen as our Visitor? ("Offensive to republicans") Was not British colonialism far more destructive in North America and Australia than it ever was in Africa? Or can that history safely be glossed over, since those indigenous populations have been reduced so close to extinction that they do not have the numbers to protest? Singling out Rhodes' statue makes no sense, since if the values espoused in the petition are taken to their logical conclusion, the entire university should be destroyed, since the entire institution is the product of imperial inheritance (as well as a pre-imperial history which does not meet any of the standards of modern political correctness either).

Clearly, if any and all legacies of the past which offend modern sensibilities of political correctness needed to be done away with, then Oriel College, the University of Oxford, and the country as a whole will need to be erased as well.

This being the case, I am saddened that the college has seen fit to take this petition as seriously as it has, since it is immediately obvious to anyone with an ounce of historical sense that the purpose of the statue (and naming the Rhodes building, and the Rhodes scholarship) is to show praise and gratitude to his (outstanding) philanthropy. It is not a canonization affirming his sainthood! To take a more contemporary example, I might not agree with every choice Wafic Saïd has made in his life, or its impact on the world, but I will absolutely praise and thank him for the specific action of funding the creation of the Saïd business school, an action which has benefited thousands of people and made a major positive impact on the world. And it is to recognise that action that the school is named after him.

If perfection were a prerequisite for public recognition at Oxford University, all the colleges would have to be named Jesus College.

The college's statement on this issue includes bien pensant sentiments about "being at the forefront of the drive to make the University of Oxford more diverse and inclusive of people from all backgrounds". This is not, it should be noted, what the college was founded for. It was founded to house "scholars studying various disciplines in honour of the Virgin Mary", a mission statement which eo ipso limits its "diversity" in the modern sense.

I am not in any way arguing that the college today should seek to conform itself to the ideals of 1326, nor that being at the forefront of helping the university be more diverse is not a laudable goal; it was always implicit in the college's mission that, as knowledge was discovered, the institution devoted to its pursuit would adapt itself accordingly. But in order for Oriel to be what it is today (which is a phenomenal, diverse, and inclusive institution), Oriel must not forget what it was yesterday. I for one would never have studied at Oriel (or at Oxford) were it not for its traditions. There is always a balance to be had between remembering traditions and being bound by them, to the detriment of progress, but it is simply impossible to maintain any memory of Oriel College, Oxford University, or England as a whole if one erases all "racists" from their histories (in scare quotes since the term itself is anachronistic across most of said history). It should hardly need to be said that the correct approach is to develop a fuller understanding of the history of race relations, in order to situate contemporary values in their proper context, and take proper steps to correct the consequences of past mistakes. The college's measures to take part in this process, needless to say, I strongly support. But tearing down statues or burning books is no way to achieve that, and I am disappointed that, in responding to the iconoclasts in this way, the college implicitly is conceding to them that they have a point, when they do not.

To my eyes, this whole exercise is more worthy of Robert Mugabe than Oriel College (though perhaps the petitioners' aim is to have his statue erected in Rhodes' place). There is contemporary precedent, of course, for destroying all traces of the past which do not harmonize with a certain group's radical ideology. It is to be found in the Islamic State. May such denial for the objective facts of the past (however unpleasant) never hold sway at Oriel College. If leftist political correctness is to be a prerequisite for being a donor to the college, than I shall cease to remain one.

I thankfully read today's announcement that the statue will remain, but the damage done to the college's reputation in entertaining the iconoclasts seriously is bound to be significant, and that makes me sad.

With the return of cold weather, one of the recipes I've been making the most with my Cookeo Connect is that staple of Russian cuisine, щи ("shchi"). Making it with the Cookeo cuts nearly an hour off of the cooking time, for a result that I think should rival any Russian babushka's (not that I'd put money on that!)

Ingredients:

• 1/2 a head of cabbage

• ~600g of pork on the bone (I buy the meat marked "à mijoter" in our French supermarket)
• 3-4 carrots
• 1-2 potatoes
• 1 onion
• Herbs & spices: plenty of room for improvisation here but the basic approach would be a bay leaf or two, basil, oregano, and black pepper
• Sour cream

Preparation

Cook meat in ingredient mode on the cookeo, choosing meat on the bone and entering the weight, but adding way more water than indicated in order to have broth for the soup. I skip the frying phase by hitting the exit button to go straight into pressure cooking mode*, which with the preheating time will take about 15-20 minutes in all. While that's going, peel and chop up the onion and carrots and fry them in a frying pan. Chop up the cabbage and potatoes.

(*Alternatively, one could use the frying phase to fry the onions and carrots, remove them, and then put the meat in as above, but this would require more overall prep time since you'd have to have the onions and carrots ready beforehand. But, that would be the way to do it if you didn't want to dirty a skillet and do everything with the Cookeo alone.)

Remove the meat from the broth and put in the cabbage, fried onions and carrots, and herbs and spices. Cook them in manual mode for about 6 minutes, while they are cooking, remove fat and bone from meat and chop the latter into small bite-sized pieces. When the Cookeo has finished cooking the vegetables, return the meat pieces into the soup.

Serve with a spoonful of sour cream. Enjoy!

In a previous article on heraldry, I went over the differences between Blazon and Emblazon: how the artistic depiction of a coat of arms can differ, while the verbal code that describes it must always be the same.

Some months ago, eagle-eyed reader Gary Smith wrote in to notify me of an irregularity in the depiction of my own arms as painted below:

Namely, the mantling (the flowing fabric shown swirling around the helmet) is reversed from what has become the standard practice: the metal (white or yellow) should be on the bottom (if the mantling were laying flat down the back of the helmet), and the tincture (red, in this case), should be on the top.

Now mantling does not even form part of the blazon: it is technically all about artistic license and the artists' need to fill in empty space, and there are a huge variety of ways in which it can be depicted (there are some good examples at this link, and this is as good a time as any to plug my pinterest on heraldic art as well). So, as heraldic sins go, the artist's decision in the above painting to have the gold mantling on the outside is about as minor as they come. And, in fact it turned out to be a happy fault in my case, since it led to Mr. Smith taking it upon himself to make a new version of my arms, which means I am now able to illustrate the differences between blazon and emblazon using my family's own arms as an example:

What makes the two versions most interesting to compare, in my opinion, is that while the former was painted by hand on parchment (and a scan doesn't to justice to the final product, with its gold and silver leaf ), the latter is an all digital creation, made primarily using clip art heraldry images (with a final result that is much nicer than what one traditionally associates with clip art heraldry). In any event I am happy to have my arms depicted by as many different artists as possible, so I was very happy to get these. He even threw in an ex libris "free of charge":

Thanks Gary!

For the past week I've been having fun with my newest toy, a very French marriage of technology and cuisine, the Cookeo Connect. This is a kitchen appliance that performs six different types of cooking, and promises to let you to make all kinds of recipes with considerable ease and rapidity, in particular otherwise tricky French classics like blanquette de veau, coq au vin, carbonade flamande, etc.

That much is also true for the base model Cookeo. The top-of-the line Cookeo Connect, however, adds an unexpected ingredient to the recipe: Bluetooth!

All models have a colour screen and database of recipes, (which one can select for 2, 4, or 6 people, with the quantities and cooking times adjusted automatically), which guide one step by step through making whatever one decides to make.

The bluetooth-enabled version takes this accompaniment a step further, allowing you via an Android or iOS app to select and follow recipes directly on your tablet. (It even sends notifications when it's finished cooking!)

While I had some doubts about this being a pointless gimmick, I ended up caving in on getting the Bluetooth model, as much out of curiosity as anything else. I'm glad I did!

The app actually has a lot of advantages: there are full-colour photos illustrating each step of the recipe (the screen on the Cookeo only shows text), and the database of recipes is larger and expandable—new recipes can be uploaded from the app onto the Cookeo. There's also an integrated shopping list function, and it's easier to browse the recipes by looking at their photos on an iPad than reading a list of names on the tiny Cookeo screen, or via the robust search function (which lets you filter not only by ingredients or type of dish but also by themes like "summer" or "Valentine's Day").

The best part of the app, though, is simply the fact that there are user ratings and comments with each recipe. It actually makes a cookbook way better to have notes from lots of people, not only to see whether the recipe works as advertised but also for little tips like "my kids love this one" or "adding one more can of tomato paste to this chili than the recipe indicates makes it way better".

As for the Cookeo's actual usefulness as a kitchen appliance, it does deliver. It is an optional extra, certainly, since in essence it's needed for steaming fish or vegetables and as a pressure cooker, and those aren't kitchen necessities (although someone living in a studio apartment might use it as a stove, too). Cooking times are shockingly fast (to produce meat that melts in your mouth), and the recipes are really good. Clean up is also very fast—versus the stove-top pressure cooker we used previously, it saves me a lot of time. (Enough that time I can cook on weeknights and still get the kids to bed on time, which I couldn't have done with the old cooker.)

That said, it's not magic, and there's not much it can do to cut down on preparation time. So, with the need to chop vegetables and what-not, and the sequential nature of the recipes, it's not about to displace the microwave. But it is, if I'm being honest, one of those things I half-expected to consider a waste of money after spending some time with it (even though it came recommended by others), and am glad to report that nothing could be farther from the truth. Now let's just hope that the reliability is solid!

The film below (in French), shows the Cookeo in action and what the app looks like.

В лицо морозу я гляжу один,—
Он — никуда, я — ниоткуда,
И все утюжится, плоится без морщин
Равнины дышащее чудо.

А солнце щурится в крахмальной нищете,
Его прищур спокоен и утешен,
Десятизначные леса—почти что те...
А снег хрустит в глазах, как чистый хлеб безгрешен.

I had expected by now to start sharing some of the appreciation I've gained for Tang poetry. This has been an unexpected development in my study of Chinese, since the language is hard enough to appropriate that I never expected to have the time, or even the ability, to get much out of its poetics, especially when they are expressed in a more archaic form of the language than the contemporary 普通话 I am focusing on. After all, how much would one expect a Chinese ESL learner to get out of Shakespeare?

Well, that discussion will be left for another day, because my Chinese lately has been suffering some neglect thanks to an unexpected boom in my Russian reading. I've learned to just roll with it when a sudden breakthrough comes in a language, even if it isn't the one that I'm currently focused on. (Remember, Chinese itself was an unexpected breakthrough that came when I was trying to focus on Sanskrit.) Even if the last few months have set me back on my Chinese progress, reading hundreds of pages of Russian fiction makes up for it. After all, it's not as though I had any deadlines for any of these languages, except the goals I set for myself, and the overall benefit of these waves of progress ultimately ends up with me knowing and mastering a great deal more, than if I held myself to a narrow road arbitrarily.

Osip Mandelstam lived a hard life, and in context, the fact that he likely never got any exposure to Tang poetry probably comes in rather far down on the list of his hardships. That context notwithstanding, it is a shame all the same, since his Acmeist style seems like a reincarnation of Tang poetics, albeit in a language that could be not be more different, and in a time and place that could not be more different as well.

The poem above, written late in Mandelstam's untimely short life, creates such a pure image. It embodies to me what the Acmeist ideals are all about. At the same time, focusing as it does on nature, it harkens back to timeless themes. In Chinese (and Japanese) poetry, such minimalist poems are seconded by minimalist language, vague allusions and a sparse economy of words serving to enhance the perceived purity of the word painting. Chinese being an isolating language—and classical Chinese extremely so—means that almost no space be wasted on grammatical elements (number, tense, or any of the usual elements of conjugation or declension).

Russian could not be more different. It's a language that I would have thought would be poorly suited to this style of poetry. It's a—I don't know whether it's because of the poem's imagery but this is the word I have in mind—"slushy" language. Утюжится, морщин, дышащее... the words hang around, and flow into each other, with grammatical elements all over the place adding nuance and detail to their relationships.

It's precisely this paradox, not hidden in this poem but fully assumed, while still creating such a pure image, that makes this poem stand out to me, and made me want to share it.

Growing up in the 1980s (and having a kid's perspective at that time), it seemed inevitable that digital watches would replace analog in time. They were high tech, the LCD screens seemed so cool, and the bulky buttons looked like something out of a (1980s) sci-fi movie. And they could do so many things—alarms, running pace, stopwatches. The coolest kids (read: the biggest nerds) even had calculators!

The technology continued to advance into the 1990s, but already fashions were beginning to change. The last Casio watch I had was analog, but you could rotate a polarized bezel to reveal a digital read out, into which you could laboriously enter simple text that would scroll across the screen. Pretty impractical, but at the time it was impressive and cool. It also turned out to make a nice transition for me into the world of analog, and from then on I opted for the more "grown-up" look, and never wore a digital watch again.

In the last 20 years or so, in fact, I've hardly ever come across anyone wearing a digital watch. Partly this is due to being grown up, I'm sure, and partly due to having moved from the States to France for most of that period. But by and large, no one would argue that it is the analog watch—and the high-end mechanical analog watch especially—which dominates in advertisements and airports, and digital watches seem to have been a passing fad, leaving the watch industry more or less in the same state it was in before digital watches, once it had passed. (The low-cost, high-accuracy quartz movement, on the other hand, has been a lasting revolution—but most quartz watches today are analog, not digital.)

As anticipation builds for Apple's new foray into the "smartwatch" market, then, I can't help but get a distinct feeling of déjà vu. A recent article on the BBC ponders, "will the public be satisfied with tech-enhanced classical designs, or will people want fully-fledged apps on their wrists? If the answer is the latter, traditional watchmakers might still be caught out."

I can't help but think that people wanting read-outs of weather and Twitter on their watches are bound to be the same kind of crowd that wanted a calculator on their watch thirty years ago—and I expect this to be a fad which will follow a similar trajectory. Not that that should worry Apple—Casio sure has managed to sell millions and millions of watches, and during the period when Casio watches seemed really high tech and cutting edge, they probably did so with pretty healthy margins on their higher-end models.

Baselworld managing director Sylvie Ritter hits the nail on the head in the above article when she points out, "here we talk of timelessness, there they talk of planned obsolescence." This is the enduring competitive advantage Rolex & co. have over Apple and its imitators: I passed a shop window in Mayfair recently showcasing vintage Rolexes from the 1950s to the present day, each one commanding a high resell value for collectors. A "vintage" smartwatch probably won't even turn on in ten years (battery technology being what it is), and even if it did, its communication protocols will all be obsolete, making its apps unable to run. Such products have their market, but I anticipate that at the higher end—at least once the first rush of novelty has passed—most watch buyers will still be looking for something a little more enduring.

Sometimes I feel that my original alma mater, McGill University, doesn't get enough love on this site, since I've written so many articles about Oxford, and only occasionally mention McGill in asides (apart from a brief article in 2008 and a link on the sidebar).

That's in large part down to the fact that I simply hadn't created this site yet back when I was attending McGill, and I've never been back there since (not having left Montréal under the best of circumstances).

Even so, McGill was a major, positive, formative influence on my life, and is a fantastic university (and perpetually under-rated, "Harvard of Canada" etiquette notwithstanding). While I'm not well-placed to tout its merits nowadays (the alumni network in France is strong, though, even if very Paris-centric), browsing the web today I came across this conference, which only cements for me my opinion of McGill as a damn cool place: an annual Sanskrit conference, encouraging the use of Sanskrit as a spoken language.

In Canada, of all places!

परोक्षप्रिया इव हि देवा: परोक्षप्रिया इव हि देवा: ।।

Sed quando poterimus eodem modo colloquium facere Latine?

The barrier to entry on game programming in Clojure is surprisingly low, thanks to the ease of use of play-clj and the excellent example programs provided by Zach Oakes. This makes it possible to get cracking on the actual content of a game very quickly.

That is, assuming one is already a fairly competent programmer. In my case, being a longtime Lisper and possessing a very deep knowledge of Java, it only took a couple hours to get up and running on James' game. But I thought it might be useful for some if I spelled out what the steps I followed were, in case it might help out a newer clojure hacker unsure of what to do when confronted with all these unfamiliar parentheses.

After completing the absolute beginner's first steps (installing a JDK, Clojure, and Leiningen, learning the basics of Clojure syntax, knowing how to execute the example games, and knowing to have the language and library documentation open in tabs of your browser), here's how I got rolling on making a platformer of my own.

I began with a bit of time away from the code, scanning in my son's artwork and retooling it a bit in the GIMP. I then downloaded the Tiled Map Editor and began by modifying the existing map of the example, replacing the art assets with tiles made from my son's drawings.

Next, it was time to begin appropriating the code. Super Koalio's actual game code is contained in just three .clj files, each only about a hundred lines long, so the first step was simply to read over each file in detail and understand what it was doing. Along the way I added comments, and made notes of things I wanted to toy with—either to better understand what was happening by testing different behaviour, or to implement different features (such as double jump).

I then moved the files into a new namespace and began hacking on the game in earnest, but I publish here the original clojure Super Koalio files, annotated with my comments but before I began altering the code, in case they might help guide someone else through the same exercise:

• core.clj—sets up the game, loads the level, and the main screen rendering routine.
• entities.clj—mostly concerned with the player character, his animation and movement rules (there are no enemies or other moving sprites in the demo game).
• utils.clj—utility functions, mostly related to handling player input

I know that my comments reflect an imperfect understanding of the code in some places, but I wanted to present a methodology for figuring this stuff out, rather than official documentation (that's why I use comments instead of docstrings, too). This is my process, and it works pretty well for me.

Once one has the game running and has understood what the source code is doing, the only thing left to do is begin playing with changing the code and adding features. There's no substitute for actually getting one's hands dirty with the code, and as a Lisp, Clojure is particularly easy to play around with, since the code can all be inspected—and modified—even when the program is running. Have fun!

Following on from my last article, and my continuing interest in Clojure, my son and I have begun working on a game together. He's still too young to learn much about programming (although at least by seeing me do it, he gets exposed to the concept), so he's doing the art and design decisions, while I handle the actual coding.

Of course at first he wanted the game to be called "Minecraft 2" and take place in space, but I only have any interest in writing 2D games. Luckily I was able to sell him on 2D as well, by pointing out that we'd have to make a flat game, since he only knew how to draw flat pictures. An irrefutable argument! So, we settled on a Mario-like platforming game, though naturally it will still need to have a block world, diamonds, potions, and skeletons that you can attack with a bow and arrow.

So far things are going well (I'm using the libGDX-based play-clj engine and basing my project on the Super Koalio example), but writing a game in partnership with a six year-old brings some non-technical challenges that I hadn't anticipated. What's a programmer to do when provided with this for a specification?

His spoken explanations aren't much better, as everything seems to change radically every time he opens his mouth. For instance, yesterday the main character was supposed to be James himself (or his sister, for player two); today, he's decided that it should be a flower. (Because he knows how to draw flowers, and is afraid that if he draws himself "it will look a bit rubbish.") That said, he's super enthusiastic, and actually very easy to please, so we're having a lot of fun together, which, of course, is the real point.

The other day in a conversation with a friend she mentioned how her teenage son-in-law aspired to become a game developer, and mentioned what his college plans were. Rather than go off on a side-track about the work-life balance issues experienced by game devs, my main reaction was to emphasise that one does not learn to code in school. If one hopes to develop any skill at it, it should be first and foremost a hobby and a passion, which formal education can supplement and refine (by imparting such things as design patterns and best practices, without which the pure hobbyist is likely to produce messy and inelegant code).

A 15 year-old wanting to start down the path to game development, I said, should begin by writing a Snake or Tetris clone, the skills for which can be picked up within a couple years, and would give a solid base for growing as a programmer from that point on, depending on what direction he wanted to go into.

Upon further reflexion, I think that this advice is a bit too blunt, but the basic idea—learning to code by writing progressively more complex games—is a pretty solid concept. But Tetris and Snake are a bit too hard to be considered beginner projects. Below I list a more realistic progression (which I might try with my own kids when they're big enough), which does grow with one's ability as one learns how software works. Of course it's not meant as a rigid path—if the passion is there to explore a given direction further (like writing interactive fiction with Inform, which might well appeal more to some personality types keen on fleshing out a fictional world, as opposed to moving on to Asteroids, which requires learning trigonometry), then that's what one should do. It's better to let one's specialisation (and one must specialise at some point) be determined by passion (for music, graphics formulæ, networking protocols, etc.) than anything else.

Here then is the basic progression I would propose one set out for oneself, as soon as one starts learning a programming language. Each project can be expanded on and have features added for as long as the student feels inspired to do so.

• Guess a number. Basic algorithms and input/output concepts.
• Hangman. More interesting / complex algorithms. Can begin life as an interactive console (scrolling up) and then upgrade to using ncurses or an equivalent to function on a fixed ASCII screen (including an ASCII art hanged man).
• Sokoban. Introduction to graphics. Rudimentary collision detection (synchronous with player input). Beginning level design and storage.
• Snake and/or Tetris. Introduction to the game loop. First version can be ASCII based, then can branch out into 2D graphics (or 3D, for the determined and impatient). Basic collision detection. These games could be long-term projects, adding in music, high score lists, etc.
• Asteroids or anything that involves animation (a slot racer or side scrolling-shooter would fit the bill as well). Learning about how geometry, trigonometry, and perhaps even physics models impact animation. More complex collision detection, and asynchronous input.

The last item may be a hard sell, since the programmer has enough knowledge to branch out into different areas (a top-down RPG, Zelda clone, or platformer, for instance), and might not be interested in something like this, which can be quite complicated to code. However I include it as part of the curriculum because I think getting a feel for this maths-heavy part of animation programming is an important thing to be exposed to, if one wants to be a game programmer.

Any programmer who has written the above games has the basic skill set he needs to go forward with whatever kind of project he chooses to set for himself next. Hopefully along the way, along with from-scratch programming, he's naturally been exposed to a few APIs (ncurses, Java2D, etc.), and can, whatever ambitious project he sets up for himself next, figure out on his own which gaming library meets his project's needs, and can go about learning it without too much trouble. (It is not unlikely that porting that old Snake or Asteroids clone over to the new framework will be the first step in learning his way around it.)

Of course it's also necessary to do some outside reading in order to learn how to use programming language features, how memory management works, and how to implement all kinds of different algorithms efficiently. But the idea here is that the needs of the projects are what govern the learning, rather than taking a series of books and tutorials and working through them, as if they were the ends in themselves.

So that's my basic, generalist curriculum. I imagine others have already come upon this same idea independently, but I thought I'd share my take on it, for what it's worth.

It could of course be adapted for someone who only cares about creating fighting games, or RPGs, or what have you, but the course proposed above should, in my opinion, produce a self-confident programmer who can apply his skills to a broad range of things. More importantly, game programming requires a lot more skill and application than plenty of other forms of programming (web, database, utility applications, etc.) which, while not as fun, can also one day pay the bills quite nicely. Of course, knowing the right tools and languages, to introduce to the right person at the right time, in order to keep them engaged and enjoying the programming process, is another part of the puzzle. I look forward as a father to seeing whether I can finesse that for my kids, and transmit to them some of the fun that there is to be had in computer programming.

              
These two coats of arms are identical, heraldically speaking

An important distinction in heraldry, not always understood by the general public, is that a coat of arms' official existence is its "blazon"—the strange description, in an odd mix of English and Norman French, which a herald would have shouted to the crowd if the bearer of the coat of arms was getting ready to joust in a mediæval tournament. The actual pictorial depiction, sometimes called the emblazon, can actually vary—so long as it remains a depiction of the blazon.

For instance, the coat of arms of Flanders is blazoned "Or a lion rampant Sable, armed and langued gules", which in regular speech means "a yellow shield with a black lion standing up on it, with a red tongue and red claws".

So, if I want to draw a picture of it, I have to draw a yellow shield with a black lion standing on it, with a red tongue and red claws—or I haven't drawn the coat of arms of Flanders. So, I pick up my paintbrush and whip something up that conforms to what was asked of me, and there you go. Job done.

Except, of course, not everyone draws their lions exactly the same. The exact shades of "yellow" and "red" are not defined. Nor is it specified what shape the shield needs to be. That doesn't matter: as long as it matches the blazon, that's which coat of arms it is. In Flanders' case, all these fit the bill:

When one thinks about it, this makes practical sense. To start with, there's the fact that some coats of arms live for centuries (Oxford University is older than the Aztecs, after all), and will therefore be painted and re-painted thousands of times through history. It would be impossible to impose a single design on a coat of arms, when it has to be adapted to buildings, bookplates, signet rings, patches on clothing, etc. Insisting on an exact shade of blue, or some precise depiction of a lion, just wouldn't be possible, across so many different media. Yet to be meaningful, coats of arms have to be unique. Confining this uniqueness to the spoken blazon meets both needs.

Even just in my own case, it makes sense that the depiction of my arms that sits atop this web page be simpler and more modern than the one that hangs in my study (a fantastic rendition of the full achievement of arms by heraldic artist Max Guéguen). The former would look amateurish blown up and framed, and the latter would be overkill to use in the header to my blog!

Another happy side effect of this distinction, between the coat of arms and its artistic depiction, is that it opens up room for the heraldic artist to showcase his talent. The armiger who appreciates this talent can get a great deal of enjoyment out of commissioning his coat of arms among different artists (I recommend the book The Art of Heraldry by Carl Alexander Von Volborth for a deeper exploration of this). I haven't found as many showcases of this online, but I link to Derwin Mak here, who has had quite a few artists render his own arms, making for quite an interesting collection on his website.