(b)logophile

Recently in code review Boaz questioned my choice of the order of arguments in a function definition. I couldn’t come up with a coherent reason for my choice, and he couldn’t put words to his feeling that it was odd. As often happens, I realised what was going on while doing something entirely non-coding-related; this time I was in the shower when the light dawned. It turns out that the argument order tells you something about the language paradigm I’m thinking in (OO versus functional); it also ties in to the choice between destructive updates or returning a modified copy, which came up in the same code review.

The function definition (in Python) looks something like this:

def remove_brands_from_chart_defn(chart_defn, brands_to_remove):

A chart definition is a complex structure of nested dictionaries and lists (it comes from JSON serialisation of a JavaScript object in the browser); a brand is an element that can occur in many places in a chart definition, so the function has to make a recursive traversal of the chart definition’s structure to find all occurrences of the brands it has to remove.

Now there are two ways of thinking about this process, which correspond to the two possible orderings of the function arguments. One is that a chart definition is an object, which has the behaviour “remove these brands from my internal structure”. This would correspond more directly to the Python definition:

class ChartDefinition(object):
  def remove_brands(self, brands_to_remove):

As it happens, the chart definition is simply a Python dictionary read from a JSON string, so we don’t have a class to define this method on. (Some considerations I’ll get to later suggest that we ought to have one, but I’ll leave that aside for the moment.) You can see the object-oriented argument pattern though: the first argument gives the object being operated on (which languages like Java make entirely implicit in a method’s argument structure) while the rest of the arguments specify the particular form the operation will take (which brands get removed, in this case).

The other argument ordering is much more reminiscent of functional programming. Here “removing brands X and Y” is a specific form of a more general operation “removing brands”, and the specialised form gets applied to a particular data structure. Haskell makes this very explicit with its syntactic support for currying:

remove_brands :: [Brand] -> ChartDefn -> ChartDefn
remove_brands_X_and_Y = remove_brands [brand_x, brand_y]

Here remove_brands_X_and_Y is now a one-argument function that wants a chart definition, and will perform the brand-removal operation on it. (Of course you could also think of the operation as “remove brands from chart definition X”, and depending on your use case that might be the more useful currying to apply, but that perspective is (perhaps) less functional and (definitely) more object-oriented.)

So my choice of argument order reveals some aspects of my coding psychology: in this case, at least, it seems I was “thinking OO” even when I wasn’t using Python’s class system at all. And indeed, the issue of destructive updates versus return-modified-copy bears this out.

Remember that a chart definition is a complex structure of nested dictionaries and lists, and that the brands to be removed can occur at many different positions in this structure. Of course I handled the removal with a recursive traversal of the structure, but given this there are still two ways to get the resulting chart definition back: I could modify the structure in-place (“destructive update”) or I could return a copy of the structure with the modifications occurring only in the copy (“return-modified-copy”).¹

How to choose between the two? Of course, the particular situation might make one or other choice obvious. (For instance, it’s elsewhere very handy for us to be able to extract by reference a list of brands occurring in a chart definition, so that altering those brands destructively updates the chart as well.) But the language paradigm can also help with making this decision.

The destructive update is very natural in the OO setting: one of the behaviours of objects of this type is to update their internal state by removing internal references to a given list of brands. Thinking functionally, on the other hand, the destructive side effect is unexpected and unnecessary, while return-modified-copy is much more natural.

The odd thing about this situation is that because our chart definition is not an object (at least not of a user-defined type), I had written an OO-like function to perform a destructive update. In the course of writing this post I’ve convinced myself that this is a recipe for misunderstanding: either that function should be functional-style (return-modified-copy and –yes Boaz– with the arguments reversed), or it should be a (destructive) method defined on a ChartDefinition class and returning no result at all.

Notes:

1. To my shame, what I actually did was a bit of both, which would have introduced extremely difficult to diagnose bugs further down the pipeline if Boaz hadn’t asked me to put my choice in a docstring, which made me verbalise it explicitly, in turn making me notice that I hadn’t actually made the choice at all. [↪]

Winter is coming, and I have to admit I’ve been playing computer games. Specifically, I’ve got myself hooked on SpaceChem. It’s a somewhat odd addiction for a programmer, since playing this game is in many ways very like algorithm design, but it definitely tickles me.

Until recently you could decide your own price for SpaceChem and a bunch of other games, with the Humble Voxatron Debut (Humble Indie Bundle number umpteen), but now the sale is finished so you can’t any more. You can get it for $10 on their site (Mac/PC/Linux) or on Steam or Playism. Or if you have an iPad, it’s only $6.

I envy iPad-owners immensely on the gaming front. SpaceChem would be lovely with a drag-around interface.¹ So would World of Goo (and yes you can).

Osmos is another gorgeous game that seems perfectly suited to the touchscreen. It’s available for iPad; it will be on Android… someday.²

And finally, there’s a new release coming “early 2012″, from the makers of Machinarium and the two Samarost games: Botanicula. It looks as quirky as their earlier games, and features some extremely beautiful design. I’m excited for it.

Notes:

1. There is some talk of an Android version, if the iPad one does well enough. Not holding my breath though. [↪]
2. By then I will probably have an iPad. For which I will buy Osmos. But when they release the Android version, I’ll buy that too. Because Osmos is that good. [↪]

Cycling to work one morning, a scrap of newspaper (of unknown provenance) blew against my face. In the moment before the wind took it again I read the following:

Exercise: How many errors, and of what kind, are contained in the following sentence? I did not interpolate at that moment, as she was interfacing telephonistically.

Solution: The sentence contains one error, an error of etiquette. It is never impolitic to extrapolate a telephonic conversatory. The rule of remembrance is this: If the telephone may interpolate you, then you may interpolate the telephone.

Attempts to discover the source, while initially showing encouraging signs of progress, have proved fruitless.

Over at Hyperbole and a Half there’s a post that explains why she hasn’t updated for several months. It’s about depression.

I’m glad to say that my experience of depression has been nowhere near as severe as this. But one thing in particular rang true for me:

But trying to use willpower to overcome the apathetic sort of sadness that accompanies depression is like a person with no arms trying to punch themselves until their hands grow back. A fundamental component of the plan is missing and it isn’t going to work.

The most effective ways I’ve found to counter my (again: much more limited) depression have been: exercise, sleep regularly and enough, and eat properly.¹ The terrible thing is that each of these (apart from the vitamins) is liable to be disrupted by depression itself, starting a vicious circle that genuinely deserves the name. Exercising and eating properly take willpower, which depression saps. And at least in my case, depression often brings insomnia (not exercising enough contributes); I also tend to spend more time consuming low-quality screen-fodder late at night when I’m low (lack of willpower again) which makes falling asleep harder.

The hardest thing to explain to people who don’t suffer depression is exactly captured by Allie’s quote above. It’s sitting staring at rotten television at 1am and knowing you should go to bed and knowing that this is making you even more tired and unhappy… and flicking through the channels anyway. And hating yourself for it, and knowing that that is making you more unhappy, but not stopping.

Because of the willpower issue, curing depression (“from inside”, as it were) is really really hard. People you’re close to can help, but just giving you well-meaning advice probably isn’t enough: sitting on the couch you know what you should be doing, it’s just that doing it feels impossible. It takes a pretty powerful kick to get you moving; it might be that those of your friends and family who would be willing and able to give you that kick don’t realise just how hard a kick you need.²

These days I put a lot of effort into preventing depression before it hits. I exercise regularly (in a schedule with other people, which makes it hard to skip a session if I start feeling a bit low). I monitor my sleep patterns and make sure I consistently sleep enough hours. Living with Olga has vastly improved the quality of my diet (and my general happiness, although oddly enough that seems to have less to do with my downers than you would expect). And I keep a watchful eye out for the early signs, so I can do something about them while I still have reasonable amounts of willpower to do it with.

If you didn’t already click through to Allie’s story, go do that now. It’s not what you expect; it’s got hilariously demented pictures and a twisted happy ending and it won’t make you depressed. In fact, when you realise that it exists only because she got better, it should make you bloody delighted.

Notes:

1. And perhaps: vitamin D supplements; jury is still out on that one but I’m keeping them up through the winter just to be sure. [↪]
2. Don’t underestimate how hard it is to give the kick, either. It’s not enough to give advice, someone has to basically supply a portion of the willpower the depressed person is missing. That effectively means bullying them into going for a run now, cooking a healthy meal for them, pulling the plug on the television, that kind of thing. And then putting up with the complaints, as well as the fact that a depressed person is lousy company. And probably knows it and isn’t happy about it. [↪]

Hoping this might be useful for someone else, since Google didn’t turn up the answer for me.

I got a vagrant-packaged CentOS box from a colleague, and starting it up warned me that the VirtualBox Guest Additions were out of date. Fixing things involved these steps:

1. Get VirtualBox to “Install Guest Additions” (from the Devices menu of the running VM). Don’t be fooled: VirtualBox has not, in fact, installed the guest additions at this point.¹
2. What it has done is added the ISO as if it were a cdrom device: you have to mount it and run an install script. This is in the VirtualBox docs, but everything I found assumed the ISO would be on device /dev/cdrom. In my case, though, /dev/cdrom was very handily attached to the cdrom device on my host machine. (Vagrant setup did it? VirtualBox did it by default? Not sure.)
3. Turns out the device you want is /dev/cdrom1 (yeah, obvious in retrospect). Mount that, run the install script, done.

Notes:

1. Yes, this is a rather astonishing failure of UI design. But one that is fairly well-known, googlable, and not the root of the problem here. [↪]