Code readability from a musician's perspective
updated over 5 years ago; latest suggestion about 5 years ago
There's huge emphasis placed on code readability in the Ruby community. People baulk at implementation styles which are less than beautiful and there's a focus on refactoring to the latest fad - whether that's DCI, Hexagonal Rails, BDD, or <insert next week's fashion here>.
There are parallels with the experiences of a musician in reading encoded information quickly and accurately, but with a very different context of market forces.
I think it might be interesting to look at some of those parallels and ask ourselves whether we're right to care so much; what the benefits are; what the future might bring...
I've had v little time to consider this talk since originally proposing it. #sadpanda
Thank you for your comments. To your points:
- @Robert. I'm thinking of notated scores, focussing less on interpretation and more on parsing what is absolutely encoded in the score.
- @Paul. I'm not interested in tablature, chord sheets et al - just orthodox classical notation. The relation to programming is in the expectations around JIT interpretation, I think.
- @Roland. I hadn't planned to involve other languages, but that's an interesting point.
- @Tom. Right. Abstraction impacts on surface readability, at least demands more of the reader.
If there's sufficient interest I'm happy to dig in and work on it.
When you describe a musician reading encoded information: are you describing notated scores, or are you interested in exploring other forms of notation?
I ask because a lot of music is about interpreting music and extending on what's written - be it a super detailed score, or a figured bass, or a lead sheet; by contrast, I'd like my compiler or interpreter to do exactly what I want it to. Unlike musical notation, code isn't just written for humans (even if it's written for humans first).
Or perhaps: that is the talk; I guess I'm just interrogating what you mean by a "musician's perspective", because there are several possible talks here, and I might be imagining the wrong one.
I think this could be an interesting topic. I'd been thinking recently that things like written music have a lot of direction and nuance in them that make the musician interpret them in different ways. Not only what to play, but how to play it. I wonder if that applies/could be applied in programming.
Can you explain a bit more about the parallels? I suppose that (western) musical notation has varying levels of abstraction, from chord sheets, to melodies with figured bass, to full scores, to tablature and other notations for concrete implementation. Then there are the piano rolls used by sequencer software. How does this relate to programming, though?
Is there anything here around the readability/density of various languages compared? For example ruby code is frequently a lot shorter than something like Java, but Haskell is often shorter again. Many people find Haskell hard to read though, until they are used to the "encoding". I'd be interested to find out if you think there is some form of optimum for this, especially having mastered another dense technical language (music).
I'm interested in the identification of DCI and Hexagonal Rails with readability. It seems to me that these, and similar, techniques sacrifice surface readability for flexibility. That is, you can't immediately see what concrete code will be executed because you're depending on an abstraction which comes from elsewhere, and I've often heard the complaint that this is less readable. It certainly seems to necessitate careful thinking about naming.