> No, he did not. The meaning of a technique not being scalable is that while it does work for small instances it does not for large ones. I see, so a complete

> No, he did not. The meaning of a technique not being scalable is that while it does work for small instances it does not for large ones. I see, so a complete and correct multiprocessing operating system running on unreliable hardware is a "small instance" according to you. This is the sophistry I promised to dismiss. Consider it done. > There are now complexity theory results that show that decomposition cannot always work. Obviously decomposition can't always work. Primitives can't be decomposed by definition. Yet another trivial truth. >It's not a constraint as much as saying that the claim you have a technique that can more effectively yield programs that we already know how to get more-or-less right and the claim you have a technique that can effectively, feasibly and scalably produce programs that are otherwise very hard to get right are two very different claims. It's like the difference between improving a polynomial algorithm by a constant and finding a polynomial algorithm for NP-complete problems. The first might get you published; the second will make you world-famous. This word-salad has nothing to do with anything I've written. > The proof is relevant because it precisely proves that your claim, as stated, is, in fact, false. Your claim might be made about "common cases" etc., but that would require a much more careful wording, as well as a careful empirical study rather than insistence. This is more interesting, but also misleading. Obviously every single program ever written falls within the class of "common cases," since, asymptotically speaking, very nearly all program texts have never been written, let alone studied. Look ma, I can do sophistry too!