Hacker News new | ask | show | jobs
by yesenadam 3046 days ago
He doesn't really mention that the reason chess players and musicians can take more with each glance at a position/page is that they see in chunks, not individual elements - that comes from learning the patterns, e.g. in chess "short-castled white king with pawn on h3", in music "C7 chord with melody on the 7th" etc. It's just like adding more layers to a neural network, each layer building things from the elements of the previous one. Or like us reading a page of writing - we don't have to look at each letter like a beginner reader, and barely at some individual words. I guess looking at a C for-loop is like that for someone who's seen 1000s. Apparently chess masters don't look at more positions and moves than a beginner; they just see so much more, and intuitively only look at the best moves in a position (mostly anyway).

Learning to improvise jazz seems different to Franklin's method, in that you don't listen to a jazz great's solo, put it aside and later try to reconstruct it; you have to play it exactly, writing it out if necessary, and play it over and over until it starts to become intuitive; until the muscles learn it. And that must be done with many different solos. And copying just one person just makes you a clone of them. I guess learning programming doesn't have that essential element of imitating the styles of individual great programmers, although maybe for some people it does.

7 comments

Learning to improvise jazz seems different to Franklin's method, in that you don't listen to a jazz great's solo, put it aside and later try to reconstruct it; you have to play it exactly, writing it out if necessary, and play it over and over until it starts to become intuitive; until the muscles learn it.

I think that this Franklin method is basically how I learned. Jazz solos are not generally random; they are based on particular chords and/or scales/modes. The best improvisers tend to be good composers in general, and improvising is composing real-time. Get a good handle on what chord/mode to center you're composing around, and construct a jazz solo likewise.

>not generally random

not generally? "not random", surely. And even if humans try to play randomly they couldn't.

>based on particular chords

Whether the notes used in a section are from the set of all 12, or a particular subset, is nearly, dare I say, orthogonal to the level of randomness. And even playing not based on particular chords can be highly random-sounding or not at all.

I didn't understand your last sentence at all; at least, what do you mean, likewise? Or the first half really.

I did not mean "random" in a literal mathematical sense. If I have absolutely no idea (or purposefully ignore) what the chord progression of a tune is, I could just start playing notes. It might sound good, it might not. It might sound dissonant in a pleasing way. But that playing would not be based on a theoretical understanding of the chord progression; it would be, in some sense, random -- unplanned, escaping traditional theoretical analysis.

You could play any note on any chord, and it might be what you intended. Let's say the chord is C major. You could play a C, for the root. Or G, for the 5th. Or Db, for a flat 9. Or F#, for a sharp 11. Indeed, any of the 12 notes would be fair game, and you could name what they are from a music theory standpoint.

Trying to bring this back around to the Franklin method of learning: what one might do here is listen to a jazz solo, and first transcribe (or obtain a copy of) the chord progression. Instead of trying to copy the solo itself, you can hear that the soloist often played motifs emphasizing the dominant 9th and 11th over minor chords, and the major 7th and major 6th over major chords. You could then make up your own solo with the same emphasis. It would not be the exact same solo, but it would (or could) have a similar sonic color to it.

He doesn't mention it in those terms, but that's what the "Mental Representations" section is all about.

Compression : finding patterns :: forest : trees.

Q. Who are the great programmers, with inimitable or at least unmistakable and unique styles? Is there such a thing, as happens with music improvisers, composers, artists, writers?
I find that "great programming" is less about the style of the code itself. That part is craftsmanship, which beginners do poorly, but once you learn it, you've learned it. Expert coders may have differing styles, but it mostly just looks like "good style". Like how two expert carpenters might make slightly different style of chairs, and you can tell that both are made really well, but neither style is distinctive enough that it will blow you away.

No, true "artistry" in code I find comes less from style in code and more from architecture. Like, when you first learn about the unix pipeline, and realize how all these tiny programs are composable, and it blows your fucking mind? Or when you're faced with a huge codebase, framework or engine, and you start to explore how it works, and you realize how smartly designed everything is, and how easy it is to do stuff in it? (it doesn't happen often, but when it does, it's wonderful)

That's what great programmers do.

Thank you, yeah, that sounds right; it's more like design than like art.

Also, in pg's essay Great Hackers he says that no-one knows who the best programmers are; you have to work with them to know just how good they are.

http://www.paulgraham.com/gh.html

So, less emphasis "neat/readable organization symbols in a particular file" (though it's still important) and more emphasis "neatly organized abstractions enabling broad application"?

I often find folks who prefer langs like C, or at least have a lot of experience with it, are better at that than Ruby/JS/Python folks who haven't used much else.

IMHO every programer has a unique style to some extent, you just need to spend enough time looking at their code to start recognising those specific patterns. For some of my friends I can always guess that code is theirs by the way they name variables, how they structure the logic and other small details. So I guess you can just pick any elegant programming solution and try to replicate the logic on your own, and then compare it and see what they did differently.
A lot of people would disagree but I would nominate Arthur Whitney of k/q/j/apl fame; others on my list are Bill Spitzak of FLTK, Salvatore sanfillipo (antirez), Richard Stillman (who hasn’t written a lot of code recently, but did write the original Emacs, GCC and a lot more)
I would definitely add Fabrice Bellard to that list.
Stallman has never been still ;)
Usually, you have no choice but to follow the style set by the lead of your team, which he typically expresses in code reviews and design decisions.

So, extrapolating it further despite my lack of personal experience – perhaps, Linus?

The analogy between music and programming holds at this stage. I can guarantee you all the musicians in this band [0] had their own distinctive style to some degree or another and would have even loved to have been paid to perform it but the fact is most professional musicians come in and have to be subservient to the style of the bandleader. And it's no different for coding.

[0] https://www.youtube.com/watch?v=hNbsnBZOwqE

Well, in jazz, you have your own individual style, people hire you because they like it. Sure, in different settings you adapt, but you still sound like yourself. It's the same with classical soloists. The ones that are famous, are famous because they don't sound like anyone else. Just a lot like themselves. Same with singers (rock, jazz, classical) - all well-known singers are very recognisable, and a lot of them have weird, unusual voices.

Also, I find it strange, this talking as if programming and music don't exist in the world outside a setting of just having to do what the leader wants. I guess particularly because I've been programming and playing music all my life, almost all of the time doing exactly what I wanted every second. (Only music professionally)

Following the same style guide as your coworkers isn't the same as writing code exactly the same way your coworkers do. I suggest following the style of a bandleader works in the same way. Individuals still have a voice - think of all the great players who made a name in various Big Band orchestras - but the style is still unmistakably that of the band and not exclusively the individual. Unless you're Melkor or something.
Sure, sure. We should differentiate the styles of the individual players, and the style of the group; two different things. I found it depressing, that suggestion earlier in the thread that one's style is always totally suppressed by the team you're on. Maybe I misunderstood; maybe that's stretching the analogy too far.

Although... when I was about 20 I went to see a fellow musician in their day job, programming in a company, finance/accounting-type stuff. It seemed so totally depressing I decided I never wanted to do programming professionally.

I guess there is the average, rank-and-file performer in the arts, like a 3rd violin in an orchestra, or player in a musical show, singer in a choir, (or my friend) where individuality is not required, just professionalism. That's like craft[0]. And then the music-as-art thing, like classical soloists, jazz groups, singers where the important thing is to sound like yourself (and to sound good!)

[0] I'm thinking craft in the sense Collingwood uses it in Principles of Art - craft (as opposed to art) is when you know beforehand exactly what final result you're aiming for and what steps to follow to get there.

I would look to the great applications that you use everyday. Open source applications are a great resource here. One of the reasons I like GitHub is I can peruse great software and learn how they work. The great programmers quickly come to the top when you study their work.
Another advantage musicians practiced in reading sheet music have (assuming they're also practiced in the general play of their instrument) is that music falls into various scales and modes. Learning and practicing the scales and modes in different ways and patterns allows musicians to have a wide set of skills that can be quickly applied to most music.
Note that there are different sets of patterns. Jazz and classical music are different enough that you can be good at one but bad at the other. There are rhythms an chords in each that would never make sense in the other. Of course plenty of musicians are good at both, but it requires more effort.
Another big difference is that the chess players and musicians he mentions are already experts. If you are learning a new language, you probably don't know the syntax, and maybe even don't have a clue about the programming paradigm.
Another Q:

It's been said about many things that they can't be taught, only learnt. (e.g. Botvinnik—founder of the "Russian school of chess"—said it about chess, I say it about jazz, Oakeshott's Rationality in Politics is about that)

Is that true of programming also?

Maybe that's what the article's saying—you have to learn for yourself. Well, there are typically a lot of Exercises in maths books because that's how you learn that stuff, by seeing for yourself, working things out, not from just being told it.

When I studied jazz piano at university, I was actually taught a very similar technique to the one described in the aritcle. You're right in that we would learn to memorize transcriptions of great players, but there was also a step where we might deconstruct there techniques and apply our own approach to them.

For example, I might see that John Coltrane used a certain scale or lick at a certain point in a song. I then might make a note in my music 'Use X scale here' as an exercise while improvising.

The effect is similar to what the author is describing - chunking broad ideas and implementing them ourselves as practice.