Note he said "suppose". His argument also applies to the copied test code (that was removed).
Parallelization is limited similarly to http://en.wikipedia.org/wiki/Amdahl%27s_law (usually called critical path when applied to development). I don't know the dependencies for this code, though it is part of a sort (Timsort) which was likely used by a few things, being a utility. As for test code, although TDD advocates doing it first, it's not a functional dependency. But, given the crucial importance of compatibility in this situation (reverse-engineering standard libraries), you might well want it first, to catch problems ASAP when they are cheaper to fix.
> Q. Why did you copy the rangecheck function for Timsort?
> A. It's good engineering to reuse the same function if possible
That's Joshua Bloch (it was his own code he copied).
http://www.groklaw.net/articlebasic.php?story=20120419221941... I think "good engineering" includes the accelerating factors I mentioned above (also, future modifications/bugs-fixes can be made in one place, when the same code is called, which was Bloch's long-term expectation).
BTW: Some other people are responding without reading fully - please take the time to do so. It elevates the discussion, making it interesting and engaging. I am really delighted to be shown wrong and to learn something, but it's hard for a response to a comment to be persuasive if it doesn't address that comment.
Parallelization is limited similarly to http://en.wikipedia.org/wiki/Amdahl%27s_law (usually called critical path when applied to development). I don't know the dependencies for this code, though it is part of a sort (Timsort) which was likely used by a few things, being a utility. As for test code, although TDD advocates doing it first, it's not a functional dependency. But, given the crucial importance of compatibility in this situation (reverse-engineering standard libraries), you might well want it first, to catch problems ASAP when they are cheaper to fix.
That's Joshua Bloch (it was his own code he copied). http://www.groklaw.net/articlebasic.php?story=20120419221941... I think "good engineering" includes the accelerating factors I mentioned above (also, future modifications/bugs-fixes can be made in one place, when the same code is called, which was Bloch's long-term expectation).BTW: Some other people are responding without reading fully - please take the time to do so. It elevates the discussion, making it interesting and engaging. I am really delighted to be shown wrong and to learn something, but it's hard for a response to a comment to be persuasive if it doesn't address that comment.