Computational Musicology, ????, Profit

This year I had the pleasure of attending FARM at ICFP. As well as demoing Klangmeister, I gave a paper on what computational musicology means for the study of music. The abstract is as follows:

In this paper I examine the relationship that complexity theory and
disjunctive sequences have to music, music-generating programs
and literary works. I then apply these ideas by devising a program
to generate an infinite ‘Copyright Infringement Song’ that contains
all other songs within it. I adopt literary modes of analysis and
presentation, which I motivate by arguing that music is a cultural
and artistic phenomenon rather than a natural one.

The full paper is available online via the ACM.

Most of the FARM papers focused more on general analysis of the structure of music than the interpretation of the meaning of specific pieces. I find the general analytic approach fascinating, but as I argue in my paper, I think computational musicology can be more than that.

I'm grateful to the FARM organisers for accepting a work that is a little loose with the genre conventions of a computer science paper. ICFP is a great conference, but its usual standard of worthwhile research is inherited from mathematics and the sciences. With notable exceptions like James Noble's work on postmodern programming, I don't see many examples of academics employing computational thinking for humanities research.

The paper is based on a talk I gave at Strange Loop last year called Kolmogorov Music.

Lanham on explicit data dependencies

Who's kicking who?

- Richard Lanham, Revising Prose

Dickens on Ruby on Rails

There is much good in it; there are many good and true people in it; it has its appointed place. But the evil of it is that it is a world wrapped up in too much jeweller's cotton and fine wool, and cannot hear the rushing of the larger worlds, and cannot see them as they circle round the sun. It is a deadened world, and its growth is sometimes unhealthy for want of air.

- Charles Dickens, Bleak House

Eco on over-engineering

This triumph of the mechanism produced a kind of giddiness, whereby the importance attached to what the machine actually produced was less than that attached to the extravagance of the mechanical resources required to produce it, and frequently many of these machines displayed a wholly disproportionate relationship between the simplicity of the effect they produced and the highly sophisticated means required to obtain it.


- Umberto Eco, On Beauty: A History of a Western Idea

Eliot on projects without Continuous Integration

What are the roots that clutch, what branches grow
Out of this stony rubbish? Son of man,
You cannot say, or guess, for you know only
A heap of broken images, where the sun beats,
And the dead tree gives no shelter, the cricket no relief,
And the dry stone no sound of water.

- T. S. Eliot, The Waste Land

Russell on programming language design

A good notation has a subtlety and suggestiveness which make it seem, at times, like a live teacher. 

- Bertrand Russell, in the introduction to Ludwig Wittgenstein's Tractatus Logico-Philosophicus 

My agile canon

As much as I enjoy reading blog posts, they cannot match the sustained argument from a well-written book. Fortunately, the agile movement has many articulate advocates who have been busy committing their thoughts to paper (and eReader) over the past few years.

Here are some agile books that I recommend:

• Extreme Programming Explained by Kent Beck is the original XP manifesto.
  
• The Art of Agile Development by James Shore is a comprehensive reference for agile/XP.
  
• Clean Code by Uncle Bob is a detailed manual for producing high quality code, right down to variable naming.
  
• The Art of Unit Testing (with examples in .NET) by Roy Osherove is the only good book I've found specifically on unit testing.
• Working Effectively with Legacy Code by Michael Feathers is an interesting guide to bringing legacy code under test and under control.
• I'm currently reading Agile Estimating and Planning by Mike Cohn, which covers story points, sprint length, agile planning and a lot of other topics that are important for management to understand as well as developers.
• Two very reputable books on use cases and user stories are Writing Effective Use Cases by Alistair Cockburn and User Stories Applied by Mike Cohn, but I've read neither (yet).

The exciting thing about reading these books is that they are part of an ongoing conversation. We haven't worked out how to build software well yet, but I think that these books bring us a little closer.

Tolstoy on iterative development

But their mother country was too far off, and a man who has six or seven hundred miles to walk before reaching his destination must be able to put his final goal out of his mind and say to himself that he will 'do thirty miles today and then spend the night somewhere'; and during this first stage of the journey that resting-place for the night eclipses the image of his ultimate goal and absorbs all his hopes and desires.

- Leo Tolstoy, War and Peace

Crime, punishment and reinventing the wheel

Crime and Punishment, the classic 19th century novel by Fyodor Dostoevsky, describes the execution and aftermath of a brutal double murder committed by the poor ex-student Raskolnikov. I am not spoiling the ending by telling you this - the murder itself takes place early on and the bulk of the novel deals with Raskolnikov's guilt and mental anguish.

Initially, Raskolnikov justifies his crime by imagining himself to be one of the elite few who transcend ordinary morality. Like Napoleon Bonaparte, these extraordinary men are destined to seize society bend it to their will. Their higher purpose excuses them from the constraints of morality that ordinary members of society must abide by.

The reader soon realises that Raskolnikov is not a member of this elite cadre. True Napoleons are too busy invading Spain to construct self-serving psuedo-philosophical justifications. As the novel progresses, Raskolnikov's crippling doubts reveal to him the fallacy of his delusions of grandeur. He realises that men who are preordained to shake civilisation to its very foundations do not agonise over their calling.

In the world of software, it is not at all uncommon to encounter a developer who is convinced that they are a Napoleon. Perhaps it's ignorance. Perhaps it's arrogance. Whatever the reason, they are motivated to create their own inadequate solutions to problems that have already been well and truly solved. Often they take it on themselves to improve upon things that ordinary programmers take as given (like the nature of truth itself).

Google Wave may just be an example of a revolution that we actually need. Email is a tried-and-true technology, but it has its limits and could benefit from a ground-up redesign. The success of Google Maps certainly suggests that the Rasmussen brothers are candidates for web Napoleons.

On the other hand, Google's non-standard implementation of OpenID looks more like it was designed by Rodion Romanovich Raskolnikov. The whole point of OpenID is that it is a universal protocol, yet they have extended it for their own specific needs (they want to be able to use gmail addresses rather than URLs). What's worse, every developer who wishes to accomodate Google OpenIDs on their site will have to contaminate their code with a special case to handle gmail addresses.

If you are contemplating producing your own version of a well-established technology, it is just possible that you possess a unique insight and that by reinventing the wheel you will drag software in a bright new direction. But if you are not sure, then your code is more likely to resemble an opportunistic act of violence than the Code Napoléon.

And even if you are certain that your way is better, you're probably still wrong.