>>>>> "Chris" == Chris Douce <[EMAIL PROTECTED]> writes:
> This is a good question. What is considered to be important in a > program (what is likely to be useful to solve an immediate problem) > changes with expertise. I think that's very likely. But what is expertise? It might even be the case that the level of tool that people use to manipulate code for major changes (e.g. refactoring) could be used as a measure of expertise -- perhaps absolute beginners will just work at the character level, the next stage use cut and paste, and so on. And what areas of expertise? And are we really talking about experience rather than expertise, and, if so, experience of what? I expect that the tools used make a difference here. For example, someone using a line editor such as "ed" may continue to think in terms of lines! It could be that tools such as Versor could be used in training people. I expect that programming languages used, and projects worked on, will be factors in how programmers think of code. My own expectation here (as a Lisp person, so I may well be biased) is that people who've worked with code-as-data (e.g. in languages such as Lisp, or on the internals of compilers or interpreters, or perhaps theorem provers) are likely to have a more abstract view of code than most others. > When you're refactoring and moving functions around, creating new > classes, moving between files and functions, the sound of the > repetitive key presses sometimes acquires a regular rhythm. This is the kind of thing I'm interested in -- when there is that rhythm, there is presumably some inefficiency (think in terms of information theory, data compression, etc) -- how much of what you're doing is "finger macros", where you could probably even name a sequence of keypresses (perhaps not quite as literal replays, as the size of procedures, number of parameters, etc varies, but parameterized to work on blocks of text, like Versor does)? Are you, in fact, simply "executing a program" which you could get the computer to do for you? In part, you answer this below: > when you're done, so is the noise and rhythms and you're probably > never going to make the same editing rhythms in the same way. but there may be significant chunks that are just nearly-fixed sequences. (I did once start looking at processing command histories, probably as Markov chains, to try to predict the likely next command, or even to suggest sequences to bundle up into macros; this might be worth picking up again some time, or putting it up for a student project!) __John ---------------------------------------------------------------------- PPIG Discuss List (discuss@ppig.org) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
