I'm a musician who performs for money maybe 2 times a week on average. And I don't make a lot of money, and I'm not all that great, etc.

I have a different perspective on your point.

When I was little, I learned to read and perform. And I could get around playing clarinet in my school band. But I never really read or even played all that well.

Years later, I had more or less stopped reading because none of the people I play with read anything... but I had been composing a lot of music and had learned to play several instruments including piano and guitars. You don't have to "write" to program a sequencer or tell the banjo player to play these 4 chords over and over.

In the last couple of years, however, I've gotten more interested in theory and had a lot more opportunities to play written music (cello and double bass with my wife's orchestra and later bass and piano with a 16-piece jazz band).

It really wasn't until I was able to play well that I got to where I could functionally read well enough to do it on sight.

I now know a whole lot more theory-- enough at least to look at some intervals and say "ah, that's the root to the three to the five in the bass" without worrying about the key, and then have my hands just play the stuff.

And the reason I have somewhat of a grasp on theory is that I've played for years in situations where I've had to improvise a bass line or guitar solo for a tune I've never heard, and so theory has been both very helpful and proven by practice.

My point is that I feel the same way about code: I have a hard time reading code at a useful level if I couldn't have written similar code.

So I feel that it can be more helpful to learn to 'create' in some fashion -- I don't know if I'd call it writing-- before learning to formally code things. I don't agree that learning to read before we learn to speak is all that helpful for most folks.

You make a good point. There's lots of accomplished musicians who never learn to read. And some "full-stack" musicians like yourself who start with tabs or similar, and who come to writing earlier than reading. I think several of the Beatles never bothered to learn western notation.

My analogy has some problems. Still, I think it's interesting to consider the real possibility of a future where code-reading is a mainstream skill, and where writing is considered a specialisation. And where code writing is done with the expectation of serving the reader.

I've started to mess with figured bass recently. I have an old ukulele and am seeing if I can fit some lute songs to it, and get used to taking my finger patterns from those marks. Kind of a step up from tabs.

" think it's interesting to consider the real possibility of a future where code-reading is a mainstream skill, and where writing is considered a specialisation. And where code writing is done with the expectation of serving the reader."

Yeah, I can understand that as a good point. Still, as a person who was teaching Lit at a university for 8 years of my life, the idea that writing is the mantle of a special class and that reading is enough for the masses seems

Writing (code / music / language) is easy enough that I'm not understanding why you wouldn't teach it to folks even if they can't do it at the same level as the texts they are capable of reading.

Anyhow, best of luck with your ukulele experiments :D

That's a great idea! And the way you explain it in terms of music makes it seem like that should be very obvious, but I never heard it stated that way before.

I've heard Harold Abelson say “Programs must be written for people to read, and only incidentally for machines to execute” [1], and Jeff Atwood say "Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live" [2], but how about: "Write code that you'd be proud for your mom to read".

[1] http://www.goodreads.com/quotes/9168-programs-must-be-writte...

[2] http://blog.codinghorror.com/coding-for-violent-psychopaths/

A lot of programs are single-use throwaway scripts customized for a specific use case, or at best have a lifetime measured in months or years. Whereas with music there are centuries-old pieces that are still perfectly usable and probably better than what a composer would produce as a replacement. So no wonder our attitudes towards reading and writing are different.

> Composition-focused languages like python and go change that. Whitespace-orientation and named parameters help a lot. Also, you can write sophisticated python/go without complex type ontology.

This is backwards. Languages without (or with limited) type systems are very hard to read, because you have a lot less reliable information about what's going on.

    > Whereas with music there are centuries-old pieces that
    > are still perfectly usable and probably better than
    > what a composer would produce as a replacement.

As I see it, reverence for traditional composers comes from the culture where more people read than write. Other factors too - humans bond through sharing of specific tunes, and copyright makes manuscript artificially expensive and sparse.

Good composition is engineering.

When you study grades for composition or improvisation or kodaly teaching, you are taught systems by which you can write music. And you are taught to look out for ways to find new systems for yourself.

This surprised me. Up until then my mental model was that all art was subjective. But in western music, if you're doing something weird you're in trouble. Particularly in an exam.

Once you're trained in the art, you can hammer out good pieces on demand. Sophisticated pieces take time, as with coding.

By way of example, Kodaly would write exercise problems for his students on-demand, just to demonstrate a point during a lesson. He'd sit down for two minutes and scratch out a new piece, which they'd them perform. Faster than having to find an example in something that's in your existing library. Some of these exercises have lived on. This isn't evidence of genius. Rather, he was an engineer of the John Carmack school. Someone focused on an outcome, dismissive of the "don't reinvent the wheel" crowd. He had a need, he followed a system, a neat minimal piece was born. He considered it throw-away code.

We'll never know, but Mozart Coronation Mass shows signs of aggressive corner-cutting to get a product out the door. He reuses a lot of ideas across movements, he reuses an idea from one of his operas for one of the features. And - because it's a mass - he got his structure and words for free. It's good music, but we shouldn't put it on a pedestal.

    > This is backwards. Languages without (or with limited)
    > type systems are very hard to read, because you have a
    > lot less reliable information about what's going on.

In the hypothetical I describe, it would be the author's responsibility to make it clear with the restricted tools they have available. Code would truly be written for the reader.

>A lot of programs are single-use throwaway scripts customized for a specific use case, or at best have a lifetime measured in months or years.

There are just as many musical compositions that are written as a jingle for a commercial, and then are promptly forgotten.