6 ms·

Reminds me of "open textured" in legal philosophy: the idea of precedent in law is you can use it to predict how a court will decide in future. This mostly work

by 6ren 15y ago

Reminds me of "open textured" in legal philosophy: the idea of precedent in law is you can use it to predict how a court will decide in future. This mostly works, but if you have a bunch of cases (data points in multidimensional space), simple interpolation isn't always accurate. You need to look at the specifics of the present case (there's still uncertainty because each judge has an individual perspective, but that's a different issue). It's a little bit like a fractal: just knowing some data points won't always predict - even roughly - what happens in between (but in flatter regions, it can). And Turing showed that (in general), you can't predict the result of a computation except by actually doing it. The experience the article mentions only helps when a specific domain reoccurs, and known tools have been developed for it, with known characteristics. Now, if you know that domain and the tools, you can do prediction pretty well. I think of it like an experienced tradesman. However, when you go into a new area (and a new one is created every decade or so in programming), you're back to zero in many respects. e.g. the existence of the right library can save 10,000 hours.

gruseom 15y ago
That makes me wonder what other disciplines there are that have the unpredictability and open-endedness of software. I read that on large construction projects, a 1% overrun is considered failure. That is clearly a different universe. Who else is in our universe?
- 6ren 15y ago
  I think it includes anything involving new knowledge: e.g. law, science/mathematics, invention. Maybe also in the academic Arts (I don't know enough to be sure), and also in the creative arts - painting, sculpture, writing (there's exploration and massive overruns there). Also, exploration in prospecting, oil discovery - though that's not really open-ended. OK, I think it's being able to open up/zoom into finer detail (like knowledge, recursive structures, fractal) + discovery.
  - gruseom 15y ago
    Law, I'm not so sure. Any variations posed by new legal cases are still limited by the basics of human nature. Oil discovery? Don't think so. People may look in different places but they don't invent new ways of doing each project. The other examples are all art. (The practice of science itself is an art and not a science.) Is software an art?
- xiaoma 15y ago
  Mathematicians are. They couldn't tell if Fermat's last theorem was solvable in a day, or a year... or not by the efforts of many of the world's greatest minds for centuries.
  - gruseom 15y ago
    Agreed. Math is art with proofs. Or formalized imagination. Or something. It would be significant if that's the closest thing to what we do in software. (Obviously, math and computing are close as theoretical disciplines, if not overlapping totally, but that's not the same question.) Is there any kind of construction or engineering that comes closer? Because those are the analogues people have mostly (and largely unhelpfully) turned to when trying to understand how software projects work. People say "engineer" when they mean "programmer"; they never say "mathematician".
gruseom 15y ago
the existence of the right library can save 10,000 hours Can anyone define for me the difference between a library and a language? If I take all my functions and put them in a "library" and then just call them, have I made my program shorter? What if I define them all as built-in to the language? Intuitively, those seem like tricks and not genuine simplifications. Why don't they count?
- 6ren 15y ago
  Perhaps, moving into a library means it must be a clean abstraction and reusable - there's some legitimacy to considering it no longer "part of your program", so your program's shorter. If it is in fact used by other programs, by distributing its length over them all, your first program literally is "shorter" even including the library cost. The library/language distinction seems less important these days (e.g. standard libraries are often thought of as part of the language). There is (usually) a syntactic distinction, of whether it's a keyword (global availability and tightly limited), or namespaced in some fashion (local availability, and limitless/open-ended). ans: 1. syntactic/expandability, 2. yes, 3. yes, 4. they count in the wider system (as OP, I just meant you don't have to write it)
  - gruseom 15y ago
    Your suggestion that a library's complexity/cost be amortized over the programs that use it is an interesting one. What I really want to know is when a program counts as independent of another program, so its length (and thus complexity) can be measured separately. Terms like "clean abstraction" don't clarify this for me. Is it as simple as saying: if my program calls your program and your program knows nothing about mine, then yours is my "library" and I need not add its size to my total? If I make a system and call parts of it a "library", is it less complex than if I call everything the same program?
    - 6ren 15y ago
      Sounds like mathematicians defining their assumptions - it's up to them where they draw the line as to what they will work on themselves, and what they'll accept as a given. i.e. it's arbitrary. Taking it back to turing machines, you can simulate any specific design/implementation of a turing machine on some another turing machine, given a program of constant size (an emulator for the first machine). This can be applied to turing machines which include libraries of arbitrary size. So again, it's up to you where you draw the line. I wonder if the confusion is to do with why you want to draw the line? I doubt these answers will satisfy, because I'm not clear on your question. I find such questions easier to answer if I get clear on the purpose - why exactly do I want to know how complex a program is? If it's purely out of curiosity, what is the nature of that curiosity? Complexity, from what point of view? how am I thinking about it? What am I worried/concerned about? BTW: I was going to use "amortized", but it seems specific to over time (an online dictionary supports this). But it does feel correct - is it a legitimate generalization? EDIT I really think my first answer was best, so I'll flesh it out a little. I understand your question as being, when we measure the length of a program, we can factor some of out into a library routine, to make it shorter. But isn't this shifting things around just cheating? If it simply was cheating, then I don't think you'd have any question about it. I think the puzzle is that it does seem legitimate, in some way, yet also seems like cheating. My answer is that instead of measuring the length of your program, you measure the aggregate length of all the programs on your computer. From the perspective of this larger system, if that part that was factored into a library was also used by other programs, then it would make the total length shorter. The "clean abstraction" isn't an important consideration in itself, but comes into it only because that's the (a?) way to make it reusable; and being reused is crucial for factoring a component out into a library, to decrease the total length of all programs. [ One could generalize beyond "all the programs on your computer" all possible programs, weighted by their probability. The probability captures the usefulness of the programs (there's many more nonsense programs than useful ones in the set of all possible programs). This is important, because a uniform probability density wouldn't enable factoring out to make the total shorter - you need some regularity/redundancy for that, which requires some unevenness. Typically, programs do have commonalities because the programs they solve have commonalities. ] Basically, taking the widest view, would factoring this aspect out make the total system shorter? I think this explains the sense that factoring out some code into a library does make it shorter, even though when looking at that program in isolation it's just moving things around.

by 6ren 15y ago

gruseom 15y ago

That makes me wonder what other disciplines there are that have the unpredictability and open-endedness of software. I read that on large construction projects, a 1% overrun is considered failure. That is clearly a different universe. Who else is in our universe?

6ren 15y ago
I think it includes anything involving new knowledge: e.g. law, science/mathematics, invention. Maybe also in the academic Arts (I don't know enough to be sure), and also in the creative arts - painting, sculpture, writing (there's exploration and massive overruns there). Also, exploration in prospecting, oil discovery - though that's not really open-ended. OK, I think it's being able to open up/zoom into finer detail (like knowledge, recursive structures, fractal) + discovery.
- gruseom 15y ago
  Law, I'm not so sure. Any variations posed by new legal cases are still limited by the basics of human nature. Oil discovery? Don't think so. People may look in different places but they don't invent new ways of doing each project. The other examples are all art. (The practice of science itself is an art and not a science.) Is software an art?
xiaoma 15y ago
Mathematicians are. They couldn't tell if Fermat's last theorem was solvable in a day, or a year... or not by the efforts of many of the world's greatest minds for centuries.
- gruseom 15y ago
  Agreed. Math is art with proofs. Or formalized imagination. Or something. It would be significant if that's the closest thing to what we do in software. (Obviously, math and computing are close as theoretical disciplines, if not overlapping totally, but that's not the same question.) Is there any kind of construction or engineering that comes closer? Because those are the analogues people have mostly (and largely unhelpfully) turned to when trying to understand how software projects work. People say "engineer" when they mean "programmer"; they never say "mathematician".

gruseom 15y ago

the existence of the right library can save 10,000 hours Can anyone define for me the difference between a library and a language? If I take all my functions and put them in a "library" and then just call them, have I made my program shorter? What if I define them all as built-in to the language? Intuitively, those seem like tricks and not genuine simplifications. Why don't they count?

6ren 15y ago
Perhaps, moving into a library means it must be a clean abstraction and reusable - there's some legitimacy to considering it no longer "part of your program", so your program's shorter. If it is in fact used by other programs, by distributing its length over them all, your first program literally is "shorter" even including the library cost. The library/language distinction seems less important these days (e.g. standard libraries are often thought of as part of the language). There is (usually) a syntactic distinction, of whether it's a keyword (global availability and tightly limited), or namespaced in some fashion (local availability, and limitless/open-ended). ans: 1. syntactic/expandability, 2. yes, 3. yes, 4. they count in the wider system (as OP, I just meant you don't have to write it)
- gruseom 15y ago
  Your suggestion that a library's complexity/cost be amortized over the programs that use it is an interesting one. What I really want to know is when a program counts as independent of another program, so its length (and thus complexity) can be measured separately. Terms like "clean abstraction" don't clarify this for me. Is it as simple as saying: if my program calls your program and your program knows nothing about mine, then yours is my "library" and I need not add its size to my total? If I make a system and call parts of it a "library", is it less complex than if I call everything the same program?
  - 6ren 15y ago
    Sounds like mathematicians defining their assumptions - it's up to them where they draw the line as to what they will work on themselves, and what they'll accept as a given. i.e. it's arbitrary. Taking it back to turing machines, you can simulate any specific design/implementation of a turing machine on some another turing machine, given a program of constant size (an emulator for the first machine). This can be applied to turing machines which include libraries of arbitrary size. So again, it's up to you where you draw the line. I wonder if the confusion is to do with why you want to draw the line? I doubt these answers will satisfy, because I'm not clear on your question. I find such questions easier to answer if I get clear on the purpose - why exactly do I want to know how complex a program is? If it's purely out of curiosity, what is the nature of that curiosity? Complexity, from what point of view? how am I thinking about it? What am I worried/concerned about? BTW: I was going to use "amortized", but it seems specific to over time (an online dictionary supports this). But it does feel correct - is it a legitimate generalization? EDIT I really think my first answer was best, so I'll flesh it out a little. I understand your question as being, when we measure the length of a program, we can factor some of out into a library routine, to make it shorter. But isn't this shifting things around just cheating? If it simply was cheating, then I don't think you'd have any question about it. I think the puzzle is that it does seem legitimate, in some way, yet also seems like cheating. My answer is that instead of measuring the length of your program, you measure the aggregate length of all the programs on your computer. From the perspective of this larger system, if that part that was factored into a library was also used by other programs, then it would make the total length shorter. The "clean abstraction" isn't an important consideration in itself, but comes into it only because that's the (a?) way to make it reusable; and being reused is crucial for factoring a component out into a library, to decrease the total length of all programs. [ One could generalize beyond "all the programs on your computer" all possible programs, weighted by their probability. The probability captures the usefulness of the programs (there's many more nonsense programs than useful ones in the set of all possible programs). This is important, because a uniform probability density wouldn't enable factoring out to make the total shorter - you need some regularity/redundancy for that, which requires some unevenness. Typically, programs do have commonalities because the programs they solve have commonalities. ] Basically, taking the widest view, would factoring this aspect out make the total system shorter? I think this explains the sense that factoring out some code into a library does make it shorter, even though when looking at that program in isolation it's just moving things around.