2006-01-26
Structures
How many notes does a piece of music have? How many notes can a piano player play? I guess it’s several hundred, up to 1000 keystrokes a minute. Well, Google returned a.o. this link for the fastest piano player in the world. He could play 6000 notes in 2 minutes.
Imagine the amount of notes that a piano player plays during a concert. 100,000?
How can someone remember all those notes? Every note with it own tone, length and loudness? They don’t. At least they don’t remember individual notes. They remember phrases, rhythms, climaxes and turning points.
I’ve just been to a concert. Of course, there was some Romantic music on the program. I’ve got something with the 19th century. The pianist was Daniël Wayenberg, someone who really knows how the every note should sound. Anyway, during the concert I noticed how many of the notes were predictable. I had never heard those particular pieces of Beethoven, but everything was so familiar. BTW this is not uncommon with Romantic music or with Romantic paintings. Romanticism has a focus on the emotional and particular nature of things, but meanwhile it is extremely predictable (and beautiful).
If I can predict a large number of the notes, what about a concert pianist? Why can I predict some notes? Well, there is so much structure in the music. There is an overall structure with the introduction of a theme, variations, some repetitions and a final. There are microstructures like rhythms, chords and sequences in scales. A bit larger are the common chord sequences, melodic phrases.
Every composer has his own vocabulary with structures, his idiom, and his expressions. Every age has its expressions and every instrument has its vocabulary. A musician has a toolbox filled with those structures. For a piece of music he only has to know these structures and some particular notes that make the piece unique. Over 99% of the notes are just there, because they have to be there. They are the only ones that fit.
The same applies to other art forms. An actor can remember his text, because he knows the general structure of a play. He knows the character he is playing. He knows the idiom of the writer. Most words are there, because they are the most logic thing to say at that moment.
What about computers and software? Do I remember all those lines of code I have written? Do I know all functions of the operating system by heart? I only remember those things, because they have a structure, micro structures and overall structures. Sometimes I have even never seen a certain call of a system, but I simply know it is there, because it has to be there. The structure implies it. Of course there are some exceptions. Those are the things you have to remember. Yeah, and really sometimes you encounter something without structure or with such mixed up and inconsistent structures that it’s simply impossible to get it into your head. Those are the things I just really want to forget completely.
Imagine the amount of notes that a piano player plays during a concert. 100,000?
How can someone remember all those notes? Every note with it own tone, length and loudness? They don’t. At least they don’t remember individual notes. They remember phrases, rhythms, climaxes and turning points.
I’ve just been to a concert. Of course, there was some Romantic music on the program. I’ve got something with the 19th century. The pianist was Daniël Wayenberg, someone who really knows how the every note should sound. Anyway, during the concert I noticed how many of the notes were predictable. I had never heard those particular pieces of Beethoven, but everything was so familiar. BTW this is not uncommon with Romantic music or with Romantic paintings. Romanticism has a focus on the emotional and particular nature of things, but meanwhile it is extremely predictable (and beautiful).
If I can predict a large number of the notes, what about a concert pianist? Why can I predict some notes? Well, there is so much structure in the music. There is an overall structure with the introduction of a theme, variations, some repetitions and a final. There are microstructures like rhythms, chords and sequences in scales. A bit larger are the common chord sequences, melodic phrases.
Every composer has his own vocabulary with structures, his idiom, and his expressions. Every age has its expressions and every instrument has its vocabulary. A musician has a toolbox filled with those structures. For a piece of music he only has to know these structures and some particular notes that make the piece unique. Over 99% of the notes are just there, because they have to be there. They are the only ones that fit.
The same applies to other art forms. An actor can remember his text, because he knows the general structure of a play. He knows the character he is playing. He knows the idiom of the writer. Most words are there, because they are the most logic thing to say at that moment.
What about computers and software? Do I remember all those lines of code I have written? Do I know all functions of the operating system by heart? I only remember those things, because they have a structure, micro structures and overall structures. Sometimes I have even never seen a certain call of a system, but I simply know it is there, because it has to be there. The structure implies it. Of course there are some exceptions. Those are the things you have to remember. Yeah, and really sometimes you encounter something without structure or with such mixed up and inconsistent structures that it’s simply impossible to get it into your head. Those are the things I just really want to forget completely.
Comments:
Post a Comment
<< Home
Yeah, and really sometimes you encounter something without structure or with such mixed up and inconsistent structures that it’s simply impossible to get it into your head. Those are the things I just really want to forget completely.
I wish I could do that, but unfortunately the system I am working on is so twisted I am glad my editor has a decent and fast search function.
I wish I could do that, but unfortunately the system I am working on is so twisted I am glad my editor has a decent and fast search function.
Hey Michael,
Sounds cool! You are practising modern art; remove some familiar structures and be surprised by the effect of it. ;-)
Some tips:
1) Remove all comments. Those that are not meaningless are wrong anyway.
2) Replace all variable names by i,j,k and all method names by f(), g(), etc.. At least the names are not wrong anymore.
This way the number of lines you have to study can be reduced drastically.
Finally, take a blank page in your editor and start rewriting it all from scratch. Probably your code will be 1/4 of the size of the original and has only a fraction of the bugs. It might save you a lot of time during test and maintenance. And, above all, somebody else might be able to maintain your code without problems.
I haven't seen your system, but is this not what you're thinking as well?
Sounds cool! You are practising modern art; remove some familiar structures and be surprised by the effect of it. ;-)
Some tips:
1) Remove all comments. Those that are not meaningless are wrong anyway.
2) Replace all variable names by i,j,k and all method names by f(), g(), etc.. At least the names are not wrong anymore.
This way the number of lines you have to study can be reduced drastically.
Finally, take a blank page in your editor and start rewriting it all from scratch. Probably your code will be 1/4 of the size of the original and has only a fraction of the bugs. It might save you a lot of time during test and maintenance. And, above all, somebody else might be able to maintain your code without problems.
I haven't seen your system, but is this not what you're thinking as well?
Finally, take a blank page in your editor and start rewriting it all from scratch.
That would be a great option, if I had the time. Unfortunately, the requirements for the software are very complex and everything has to be documented and traceable from requirements to code. Typical for safety critical software.
I have seen code for DVD players that was better documented and traceable(!) to requirements than this here. :-(
That would be a great option, if I had the time. Unfortunately, the requirements for the software are very complex and everything has to be documented and traceable from requirements to code. Typical for safety critical software.
I have seen code for DVD players that was better documented and traceable(!) to requirements than this here. :-(
Hi Sander
Still, people make a lot of errors. Even pianoplayers. Perhaps not when you go and see them in a concert, but you can bet they made a lot of errors - or got completely stuck somewhere during the performance - while they were practicing. Same with actors, and programmers. You tell me you never use the debugger as a quick way of checking your code, thereby reducing your mental workload? Just trial and error, right?
I guess patterns, structure, only constraints the options so far. Especially when there are so many musical pieces that look so much a like, the regular patterns can actually be misleading. And a good composer will deviate from the patterns in significant ways (which you mentioned briefly) otherwise the piece would be a clichee. (Of which there are many, BTW).
Really learning to perform a particular routine is hard work. The expert might forget that he has worked to be an expert for years and years. At that point, it *looks* as if you just 'go with the flow'. But this 'flow' has been created in hard labor.
At least, that is what i think. You have to act, act a lot, do things, experience, and fail multiple times, before you get to the stage of performance that you were describing in this post...
(sigh...)
Still, people make a lot of errors. Even pianoplayers. Perhaps not when you go and see them in a concert, but you can bet they made a lot of errors - or got completely stuck somewhere during the performance - while they were practicing. Same with actors, and programmers. You tell me you never use the debugger as a quick way of checking your code, thereby reducing your mental workload? Just trial and error, right?
I guess patterns, structure, only constraints the options so far. Especially when there are so many musical pieces that look so much a like, the regular patterns can actually be misleading. And a good composer will deviate from the patterns in significant ways (which you mentioned briefly) otherwise the piece would be a clichee. (Of which there are many, BTW).
Really learning to perform a particular routine is hard work. The expert might forget that he has worked to be an expert for years and years. At that point, it *looks* as if you just 'go with the flow'. But this 'flow' has been created in hard labor.
At least, that is what i think. You have to act, act a lot, do things, experience, and fail multiple times, before you get to the stage of performance that you were describing in this post...
(sigh...)
Hi Jelle,
How do you know I never use a debugger? Did I ever tell you?
But you are definitely right with your last remark. I needed a lot of practise. I'm doing this for almost 20 years. But after all this practise I realised how I'm thinking, how I'm able to keep control on the development.
I'm trying to communicate this way of thinking to junior programmers; show them the structures. For a programmer it is also import to read a lot of good code. A composer can only become a good composer by listening to a lot of music and reading the scores.
But once you've got those structures in your head it gets so much easier You only have to pay attention to the deviations, the non-trivial part. You only have to focus on those things that give meaning to the composition/product.
Can you imagine that composers like Mozart and Beethoven didn't need a music instrument, but only a piece of paper to write a new composition? They knew what they were writing and didn't have to try the melodies on an instrument.
What about Claude Monet? He painted his famous Nympheas (Musée de l'Orangerie) when he was nearly blind.
Just a little bragging: last 2 weeks I've written about 5000 lines of code and spent only one day on testing and fixing (without debugger of course). And I started testing after all code was complete. Why? Because during trial and error development you lose the big picture.
20 years ago, before the PC existed, this was common practise. Computation time was too expensive for trial and error. It forces you into a very disciplined way of working.
OK, maybe no Mozart, but a skilled craftsman with a lot of experience.
How do you know I never use a debugger? Did I ever tell you?
But you are definitely right with your last remark. I needed a lot of practise. I'm doing this for almost 20 years. But after all this practise I realised how I'm thinking, how I'm able to keep control on the development.
I'm trying to communicate this way of thinking to junior programmers; show them the structures. For a programmer it is also import to read a lot of good code. A composer can only become a good composer by listening to a lot of music and reading the scores.
But once you've got those structures in your head it gets so much easier You only have to pay attention to the deviations, the non-trivial part. You only have to focus on those things that give meaning to the composition/product.
Can you imagine that composers like Mozart and Beethoven didn't need a music instrument, but only a piece of paper to write a new composition? They knew what they were writing and didn't have to try the melodies on an instrument.
What about Claude Monet? He painted his famous Nympheas (Musée de l'Orangerie) when he was nearly blind.
Just a little bragging: last 2 weeks I've written about 5000 lines of code and spent only one day on testing and fixing (without debugger of course). And I started testing after all code was complete. Why? Because during trial and error development you lose the big picture.
20 years ago, before the PC existed, this was common practise. Computation time was too expensive for trial and error. It forces you into a very disciplined way of working.
OK, maybe no Mozart, but a skilled craftsman with a lot of experience.
Who needs a debugger anyway?
In my experience, it is very rarely necessary to dynamically step through code to see what happens. On many systems (e.g. heavily concurrent ones with timeouts, interrupts...) it is even impossible to do.
A post-mortem debugger, e.g. examining a Unix core-dump, is usually sufficient, when it is available.
So, I am also in the "no debugger" camp. :-)
In my experience, it is very rarely necessary to dynamically step through code to see what happens. On many systems (e.g. heavily concurrent ones with timeouts, interrupts...) it is even impossible to do.
A post-mortem debugger, e.g. examining a Unix core-dump, is usually sufficient, when it is available.
So, I am also in the "no debugger" camp. :-)
hmm,
let me position myself a little bit more. I am a cognitive scientist interested in the "embeddednes", or "situatedness" of cognition. Meaning, that people often do NOT think as much "inside their heads" as we would normally believe them to do. What do I mean? Well, there is a great example of somebody making a pie. He has ingredients for the dough, for 4 people. But he wants to make a pie for 3 people. Now, instead of mentally dividing all quantities by 4 and multiplying by 3, he simply makes the dough, for 4 people, squashes it out in a circle, and cuts out 3 quarters. It is a pragmatic way of "doing the thinking in the world", instead of doing the thinking 'offline' (so you wish) in your head.
I used to believe that programmers do "embedded thinking" all the time. (I didn't mean to say that Sander SAID to me he didn't use a debugger, I meant the opposite, as in: well mister, you tell me you never... (with that intonation)). In other words: I assumed that Sander very often debugs 'along the way', letting the debugger 'solve' the problem instead of solving it by careful mental analysis.
I am probably wrong. But you must realise that programmers are very special people. They often have an inherent interest in mathematics, abstractions, conceptual thinking, structures, generalisations. They will try to find global rules that fit a set of local situations whenever they find it.
I have a feeling you are the minority, dearest programmers. (You should receive more salary, since we need these wicked minds of yours badly)
Most people, like me, just tinker about. We try some, we do this and that, we wait a little bit. We ask someone else. We do what the others do, or what worked last time. We get by, it's good enough for survival in any case.
What about it?
let me position myself a little bit more. I am a cognitive scientist interested in the "embeddednes", or "situatedness" of cognition. Meaning, that people often do NOT think as much "inside their heads" as we would normally believe them to do. What do I mean? Well, there is a great example of somebody making a pie. He has ingredients for the dough, for 4 people. But he wants to make a pie for 3 people. Now, instead of mentally dividing all quantities by 4 and multiplying by 3, he simply makes the dough, for 4 people, squashes it out in a circle, and cuts out 3 quarters. It is a pragmatic way of "doing the thinking in the world", instead of doing the thinking 'offline' (so you wish) in your head.
I used to believe that programmers do "embedded thinking" all the time. (I didn't mean to say that Sander SAID to me he didn't use a debugger, I meant the opposite, as in: well mister, you tell me you never... (with that intonation)). In other words: I assumed that Sander very often debugs 'along the way', letting the debugger 'solve' the problem instead of solving it by careful mental analysis.
I am probably wrong. But you must realise that programmers are very special people. They often have an inherent interest in mathematics, abstractions, conceptual thinking, structures, generalisations. They will try to find global rules that fit a set of local situations whenever they find it.
I have a feeling you are the minority, dearest programmers. (You should receive more salary, since we need these wicked minds of yours badly)
Most people, like me, just tinker about. We try some, we do this and that, we wait a little bit. We ask someone else. We do what the others do, or what worked last time. We get by, it's good enough for survival in any case.
What about it?
Hi Jelle,
You shouldn't tinker. You must think!
Unfortunately many computer programmers are tinkering i.s.o thinking. My mission is to let people think. My next blog is on my hero: Dijkstra.
I would like to know more about your "embedded cognition". The term suggests the same as I belief. The thing is that from that belief I put emphasis on instruction, training, training and training. You can only do something right with your body if you train it enough. You know, if you want to become a good salsa dancer it is not enough to go to the courses. You have to practise a lot.
And of course I wouldn't mind to earn a bit more, but also good teachers should earn a lot more. Let's say, I have often thought about becoming a teacher. But now it would be an act of charity. Well, you've got long vacations...
You shouldn't tinker. You must think!
Unfortunately many computer programmers are tinkering i.s.o thinking. My mission is to let people think. My next blog is on my hero: Dijkstra.
I would like to know more about your "embedded cognition". The term suggests the same as I belief. The thing is that from that belief I put emphasis on instruction, training, training and training. You can only do something right with your body if you train it enough. You know, if you want to become a good salsa dancer it is not enough to go to the courses. You have to practise a lot.
And of course I wouldn't mind to earn a bit more, but also good teachers should earn a lot more. Let's say, I have often thought about becoming a teacher. But now it would be an act of charity. Well, you've got long vacations...
Post a Comment
<< Home