4 ms·

While I don't necessarily disagree with you, I personally love working with other people's code. Better or worse than what I would have written, at least its a

While I don't necessarily disagree with you, I personally love working with other people's code. Better or worse than what I would have written, at least its a starting point. Plus it puts a new perspective on a problem that I wouldn't have gotten without tinkering with the open source solutions first.

gruseom 19y ago
You make a very valid point, one which I think is consistent with what I was saying, though perhaps not obviously so. I'd make a distinction between large production codebases that have been around for a while (let's call that "legacy code") and code that illustrates how to do a particular task (let's call that "sample code"). These are not mutually exclusive; legacy code can be mined for good sample code, and the better systems are rich sources of it. When you're trying to figure out how to do "particular thing X" there's no better way than to look at working code that does X. When Naur talks about the theory of a program, though, he's not talking about particular thing X, but about grokking the design and structure of an entire system. That's a hard thing to do for someone who doesn't have contact with the original programmer(s). You don't need that kind of knowledge for tinkering or bug fixing, but it's hard to pull off major design transformations without it. So what I was saying applies to legacy code, but not sample code. This matches experience, I think. When working with legacy systems, I've gotten a great deal of mileage out of asking myself "how did they do blah" and then looking to the code for blah to see exactly how they did it. But this only works for relatively constrained problems like "how did they scale that font" or "where did they get that data". It doesn't work if "blah" equals "producing the whole system". Web apps illustrate this. We all inspect the code of other web apps to figure out specific techniques. That this is so easy to do is of course one of the biggest reasons for the rise of the web in the first place. But it's orders of magnitude harder to figure out the design of an entire system. I've actually tried - programmatically downloaded as much js and html as I could possibly scrape from another app, to learn whatever I could about how it was put together - and it was a total waste of time. I'm curious to hear if this distinction is relevant to what you were saying.
- jmtulloss 19y ago
  It's absolutely relevant, and I would generally agree with you. There is one exception though. If the system is surrounded by a well designed testing framework, it can be overhauled piece by piece as necessary, no system rewrite required. Test code illustrates what the original programmer expected, and enables a system to be extended without necessarily understanding the theory behind it in its entirety. Of course, most legacy systems don't have good testing frameworks in place these days, so it might take a few years to see if this exception actually holds true or if the testing frameworks tend to get scrapped with the system.
gruseom 19y ago
Actually, I have to say something else about this. You mention working with other people's code in an open source context. That relates to my original point - there seems to be something about open source that changes the dynamic I was describing and that relates to the value of software. After I noticed this detail in your comment I asked myself, does it feel different to work with other people's code when that code is open source, and (for me at least) the answer is definitely yes, it feels better. It would be fascinating to know why.
- jmtulloss 19y ago
  I would say that it's because open source coders 1. Have the time to do it right (there are no deadline) 2. Could potentially be judged by anybody who uses the project
- LogicHoleFlaw 19y ago
  Open-source coders care.

gruseom 19y ago

You make a very valid point, one which I think is consistent with what I was saying, though perhaps not obviously so. I'd make a distinction between large production codebases that have been around for a while (let's call that "legacy code") and code that illustrates how to do a particular task (let's call that "sample code"). These are not mutually exclusive; legacy code can be mined for good sample code, and the better systems are rich sources of it. When you're trying to figure out how to do "particular thing X" there's no better way than to look at working code that does X. When Naur talks about the theory of a program, though, he's not talking about particular thing X, but about grokking the design and structure of an entire system. That's a hard thing to do for someone who doesn't have contact with the original programmer(s). You don't need that kind of knowledge for tinkering or bug fixing, but it's hard to pull off major design transformations without it. So what I was saying applies to legacy code, but not sample code. This matches experience, I think. When working with legacy systems, I've gotten a great deal of mileage out of asking myself "how did they do blah" and then looking to the code for blah to see exactly how they did it. But this only works for relatively constrained problems like "how did they scale that font" or "where did they get that data". It doesn't work if "blah" equals "producing the whole system". Web apps illustrate this. We all inspect the code of other web apps to figure out specific techniques. That this is so easy to do is of course one of the biggest reasons for the rise of the web in the first place. But it's orders of magnitude harder to figure out the design of an entire system. I've actually tried - programmatically downloaded as much js and html as I could possibly scrape from another app, to learn whatever I could about how it was put together - and it was a total waste of time. I'm curious to hear if this distinction is relevant to what you were saying.

jmtulloss 19y ago
It's absolutely relevant, and I would generally agree with you. There is one exception though. If the system is surrounded by a well designed testing framework, it can be overhauled piece by piece as necessary, no system rewrite required. Test code illustrates what the original programmer expected, and enables a system to be extended without necessarily understanding the theory behind it in its entirety. Of course, most legacy systems don't have good testing frameworks in place these days, so it might take a few years to see if this exception actually holds true or if the testing frameworks tend to get scrapped with the system.

gruseom 19y ago

Actually, I have to say something else about this. You mention working with other people's code in an open source context. That relates to my original point - there seems to be something about open source that changes the dynamic I was describing and that relates to the value of software. After I noticed this detail in your comment I asked myself, does it feel different to work with other people's code when that code is open source, and (for me at least) the answer is definitely yes, it feels better. It would be fascinating to know why.

jmtulloss 19y ago
I would say that it's because open source coders 1. Have the time to do it right (there are no deadline) 2. Could potentially be judged by anybody who uses the project
LogicHoleFlaw 19y ago
Open-source coders care.