I think my bracketed aside covers this: by using a probability density, it's not affected by how many people are actually using it, or whether that changes. Of

I think my bracketed aside covers this: by using a probability density, it's not affected by how many people are actually using it, or whether that changes. Of course, it's only a conceptual help, since you can't actually know this density: it amounts to knowing all possible tasks now and in future (a practical impossibility) and also knowing all the solutions (a theoretical impossibility). It wraps all that up in two words. I think defining whether A and B are part of the same program is a red herring. If you think of their calls to each other taking place through an interface, they don't need to know about each other - they just expect something that fulfills the contract of the interface. Again, it's like a mathematician arbitrarily making assumptions: we'll take a component that does this as a given. So, A and B aren't part of the same program. They aren't related at all (except that each happens to fulfill some interfaces needed by the other). This perspective is similar to taking probability density, in that it replaces a concrete actual program with an abstract representation. But how then does one measure complexity? My view is you can't, in practice. But we can have a concept that can guide us. Of course, when staying entirely within a single program it's clear that we should factor out commonalities to reduce length. But what about factoring those things out into libraries? I think an approach that works is to think about being in the business of selling those libraries - but not with the perspective of making money for yourself, but for improving the world. [again, this is an abstract concept, so we don't actually need to sell them and can ignore the real-world issue of marketing] So, there's questions like: is there a need for this, in many programs? Can it be reused generally? (or is it specific to program A - shades of Brooks program-vs-product here) Is it a clean abstraction (i.e. can it be used without knowing its details - this reduces complexity in the code that uses it). How much effort/LoC is saved by it? Factoring out code into a library that is broadly needed, is simple to use, saves a lot of code, is simple to use (doesn't require lots of code to use; solution doesn't create more problems - not the cure is worse than the disease) would be needed broadly. Good libraries save the world! I agree that in practice, it becomes a social (or community) issue, and whether it's adopted is important. You might have a great product that no one ever uses; or a crappy one that everyone does. It's messy, in that it's affected by non-programming issues like the particular alternatives existing at this moment, the need for it at this moment. [But again, a probability density circumvents all this] Maybe it's a bit like whether the scientific method requires the communication of the results: you haven't done "science" until you tell someone. It also seems absurd - how can communication affect what you've already done? - but if you being with science being a community effort (like language, commerce and law), then it does make sense: you can't do science alone. And our established science was a community effort (notwithstanding that we wouldn't know of the other stuff). This is contentious - I mention it because it seems like a similar contention. Finally, some caveats. Though I think complexity is central (Occam's razor) and even did a masters around it, it's not everything. For example, in English communication, redundancy helps by giving listeners a way to verify understanding, and different perspectives in case they didn't grasp it, or if the message was ambiguous and the speaker didn't realize it. and raw repetition in case they weren't listening or the message was corrupted/obscured. Some of these were significant in Shannon's original work on information theory. In communication in general, a constant background helps convey a changing foreground - as simple as the lines on a page of printed text; or looking at a file that is laid out neatly, so you can quickly orient yourself, and also notice irregularities. In code, some repetitive concrete structure can be helpful to the humans reading it. Related to this is the concept of "accidental redundancy". This is when two pieces of code are identical, so you factor them out - but it turns out that they change on independent bases, and it was just a coincidence that they happened to appear identical syntactically. i.e. their meaning was different. You can't tell this just by looking at the code, nor by measuring the length. You have to understand the model beneath the code, and even more importantly, understand the problem being solved (though there might be no way to know the two things differ, until they do differ). My over-idealization of short code eventually made me see the benefits of seemingly over-concrete representations. :-) But short code is still central for me, as it seems to be in scientific discovery. The simpler hypothesis/code is likely closer to the truth. And it's happened to me many times that simpler code generalizes in just the right way - before I realized that it would need to generalize that way. :-) Also, the Dirac/antimatter story is nice on this point: http://arachnoid.com/is_math_a_science/index.html http://arachnoid.com/is_math_a_science/index.html (near the end)