(b)logophile

During our Christmas holiday trip to visit my family in New Zealand we put on a small workshop teaching rebetiko, the style of Greek music that we play. Olga has put some footage online, which I’ll link to in a moment (I want you to read the caveats and disclaimers first).

Said caveats and disclaimers being:

• At no point was this a professional undertaking. We don’t know what we’re doing, although we’re having fun finding out.
• The folks attending the workshop had to pick up two entirely unfamiliar scales and one quite unfamiliar rhythmic structure over the course of about five hours, during which they also learned four songs.
• These folks were playing from sheet music notated for an unfamiliar tonal system, which they had to translate on-the-fly to what they are used to.
• We cocked up: we didn’t play them the originals. So they know the songs from our renditions, and (mainly) from the sheet music.

Given all of which, I’m proud of what they (and we) accomplished. Here it is.

Some thoughts about what worked, didn’t work, etc:

• Four pieces in two modes worked pretty well for a one-day workshop. I think we got through two pieces in the morning and two more in the afternoon; we also attempted a fifth piece late in the day, but that didn’t go as well as the first four. If we tried again to fit five into a single day, the fifth should be carefully picked to revive flagging energy and definitely shouldn’t introduce new complexities (rhythms, modes, etc).
• I was amazed at how easily people picked up the melodies, playing from sheet music. We are used to playing by ear, which usually makes learning a song a slower process because you have to remember it entirely. Sheet music parts (and people who can play to them) rock!
• The book we used, Smirneika and Pireotika Rembetika by Evgenios Voulgaris & Vasilis Vantarakis, also rocks. But…
• … it is notated for makam theory (a Turkish-based tonality involving four kinds of accidentals, none of which is quite the Western sharp/flat); I think it would have been helpful to write out the parts in simple sharps/flats, although people coped very well.
• Another disadvantage to this book for a workshop is that the transcriptions are extremely faithful to the original recordings; they include all the fills, ornaments, etc that the performer put around the melody. A simple transcription of the main melody, with ornaments and fills indicated separately or left out entirely, would have been better I think.
• Final disadvantage of Voulgaris/Vantarakis: no guitar chords. We didn’t actually think to plan for guitarists at the workshop, and the pieces were chosen for their melodies; that, combined with my indifferent guitar skills, left poor Jim making it up as he went along (very competently I must say), and playing an awful lot of Cm chords.
• We made one colossal error: we didn’t play them the original recordings. Between that and the sheet music (and the fact that of course nobody in New Zealand could sing the lyrics), some of the parts end up sounding a bit wooden because there’s not enough phrasing: they don’t know what’s melody and what’s not, and they don’t really have any model to work from to find out.
• Listening to the recordings makes it horribly clear how much I, in particular, speed up when playing. While not a workshop problem per se, this is definitely something I need to work on.
• To finish with something positive: as well as making it possible for people to pick up the pieces, the photocopied sheet music we gave out let them take something away from the workshop, which I think was appreciated. All in all, a decided victory for paper-and-ink.

If we ever do this again (and I hope we do!) I think we’ll start with rewritten versions of the Voulgaris/Vantarakis transcriptions; perhaps one with only the main melody and one with ornaments, or perhaps with the ornaments written in smaller. We’ll choose pieces with some guitar potential, and I’ll figure out, and perhaps notate, some guitar parts with more interest than “5 1/2 bars Cm, 1/2 a bar G, back to Cm, repeat” — the older recordings often have quite startling choices of chord and beautiful bass parts. We’ll also make a point of playing the original recordings as we introduce each piece.

Still I reckon we did a pretty good job for first-timers. And again, huge thanks to my mother for suggesting the idea and organising it, to the folks who showed up and shared the music, to Graeme and Zoë who made recordings, and to Jessica who gave us a beautiful venue for our New Years Eve concert.

Catching up on blog posts from my holiday I saw the cover for a book named Northworld: Vengeance on Good Show Sir (a blog devoted to “only the worst sci-fi/fantasy book covers” — and indeed, this one is awful). “Northworld,” I thought to myself, “what kind of nonsense is that?” According to one commentator the world was discovered by “a guy named North”, which doesn’t improve matters much. But then I remembered about living in glass houses and casting first stones: I am hardly in a position to criticise others on the originality of their placenames.

(Continued)

The last payment on my student loan has gone to the IRD.

Time to buy a house.

Every time I visit Germany by train, something goes wrong.

Once I spent most of the day waiting on platforms, after some perfect-storm-like sequence of feedback effects interrupted not just the service I had a ticket for but also the fallback service we were advised to take instead, and then even the unscheduled service arranged specifically for the victims of the outage.

Another time, more pleasantly, I had an unscheduled wait of a couple of hours in Cologne: just long enough for an old friend to take the subway into town and have a beer with me.

Recently I visited the same friend for a weekend; predictably, something went wrong on the way home. This time it was only a communications breakdown, but one I found particularly amusing: the various automated systems announcing the timetables completely failed to cope with a planned change to the schedule.

The ticket I paid for was Cologne to Amsterdam, but my seat reservation was only valid to Utrecht; the reservation system, at any rate, knew that on the day I was travelling the international service to Amsterdam would end instead at Utrecht, and the last half-hour of the trip would have to be made on local trains.

In Cologne, an automated voice helpfully announced in three languages: “The ICE service to Utrecht leaving platform 5 at 17:32 will not stop in Utrecht.” (We’ll carry on until we fall off the edge of the world?) The board on platform 5 announced an ICE service to Amsterdam, and warned that it would not be stopping in Utrecht. (Not to the edge of the world then. I wonder what my seat reservation to Utrecht is worth if we don’t stop there?) On the train, around the time I would have expected to arrive in Utrecht (or not to arrive there, under the circumstances) the wee lighted displays said we were approaching Arnhem. (I wondered how far from Arnhem to Amsterdam and what time I would be getting home.) Then we pulled in to Utrecht: right on time, as predicted on my ticket, but somewhat befuddled.

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. [↪]