While the basic line of reasoning is valid, it is absurd in the context of the rangeCheck function.
There might be a nine line function that takes a day or two to get right, but for even a bad programmer, rangeCheck would take a few minutes. With thorough tests, maybe ten minutes. I've barely touched Java code in over a decade, but I could write that function -- with tests -- in less than two minutes.
RangeCheck is the kind of function you'd get on a quiz in your first week of your first CS class in college.
I was simply trying to show that even seemingly-simple functions can have surprising bugs. Binary search isn't week 1 of CS101 - I think it was week 4 for me. Bentley's published version had a bug, Bloch's original corrected version had a bug, etc.
Working on it myself, after having read what the code does and being committed to re-implementing it myself, it took me 3.5 minutes and there were 2 bugs. (I needed to look at the original code again to determine that to == length and to == from were both allowed -- those were the bugs.)
Did you include the time it took to read what was needed, including the different exceptions? I would estimate, if one wasn't fresh and up for a challenge, 15 minutes (against your approx 10 minutes). And given that a day of programming isn't pure programming, I'd double it to 30 minutes. It feels way too long, but it's a realistic, day-in-day-out estimation.
Programming takes time... which is why it's so powerful if you can reuse code (as Bloch did), and even better if you can find a way to reduce the code needed, or best, to avoid needing any code.
sub rangeCheck {
my ($len, $from, $to) = @_;
if (($from > $to) || ($from < 0) || ($to > $len)) {
die "Illegal index $len ($from / $to)";
}
}
Java, as usual, makes a big hairy deal out of it. If the lack of types bothers you it's trivial in Haskell too. (Though trying to be idiomatic would lead you down a very different road. Perl is more similar to Java than Haskell, even as they are all very distant from each other.)
As it happens I've recently written somewhat similar code in Perl where I want to explicitly deal with out-of-range accesses (in a way other than silently receiving undefs) in a particular case, so this isn't even that odd.
You're throwing a generic exception; Bloch's version throws two specific exceptions, together with appropriate information. Java tends to have excellent error reporting.
All this reminds me of people saying that could code stackoverflow or facebook in a weekend. The difference is that rangeCheck actually is trivial - it's just that it's easy to underestimate the work involved in coding something. Even something trivial.
>>You're throwing a generic exception; Bloch's version throws two specific exceptions, together with appropriate information. Java tends to have excellent error reporting.
I know. I reduced it to one generic exception because that is what the person I was replying to did. Bloch's version is better of course.
I think in defining a range, the toIndex means up-to-but-not-including the element at that index. Thus, to include the full array, you'd use the range fromIndex=0, toIndex=length (one past the last one, since the index of the last element is length-1). With this notation, you can then make ranges of any width, from 0 up to length. If instead you included the element at that index, you couldn't have 0-width ranges (unless you allowed toIndex to equal one less than fromIndex).
I don't know whether 0-width ranges are directly useful for the Timsort algorithm; or whether it's just a convenient notation that happens to have that ability as an unused side-effect.
Maybe not 2, but less than 20. I've never written any Java, don't code regularly, and consider myself more of plodder than a coder, but it only took me a minute to figure out what the function was doing and why. Knowing when to put such functionality into your code is a larger challenge than actually coding it; this is a very trivial piece of procedural code.
There might be a nine line function that takes a day or two to get right, but for even a bad programmer, rangeCheck would take a few minutes. With thorough tests, maybe ten minutes. I've barely touched Java code in over a decade, but I could write that function -- with tests -- in less than two minutes.
RangeCheck is the kind of function you'd get on a quiz in your first week of your first CS class in college.