This version of Vestibule is read only. It represents an archive of the community effort to produce content for Ruby Manor 4.

Code readability from a musician's perspective

updated over 4 years ago; latest suggestion about 4 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...

Suggestions

  • The proposal author responds about 4 years ago

    Hi everyone,

    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.

  • F6f41097bd9390607fe4f1e7288c72e3 Tom Armitage suggests over 4 years ago

    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.

  • 9aad27c9b22345c079622758970e24ff Robert Chatley suggests over 4 years ago

    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.

  • 2abf5beb51d5d66211d525a72c5cb39d Paul Battley suggests over 4 years ago

    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?

  • 11364e09c2ea04444314e94eead06e98 Roland Swingler suggests over 4 years ago

    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).

  • C1f7bc8064161e7408ef62d97bb636ac Tom Stuart suggests over 4 years ago

    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.