Hacker News Reader

Comment by jabr | Hacker News Reader

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.

View on HN

Stephen Hawking could easily come up with rangeCheck in minutes, even counting the time it would take him to type it on the editor.

I really thought Oracle couldn't surprise me, but they keep getting to new lows.

What about binary search? http://googleresearch.blogspot.com/2006/06/extra-extra-read-...

And what about a ray-tracing function? I don't see the point here. It's not what's being discussed.

The ubiquitous "gotchas" in binary search are well documented; Jon Bentley did a talk on it. At Google, if memory serves.

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.

You could not type that function and tests 2 minutes.

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.)

A set of tests took me about 6 minutes.

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.

In Java, no. In other languages, yes.

    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.

This is the the version in Java. Only four lines (including the curly bracket).

       private static void rangeCheck(int length, int fromIndex, int toIndex) {
           if (fromIndex > toIndex || fromIndex < 0 || toIndex > length) 
               throw new Exception("Illegal index");
       }

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.

Shouldn't that be "toIndex >= length"?

Bloch used > http://news.ycombinator.com/item?id=3940683

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.

At 70+ WPM, I doubt that I would have much trouble. No tests for it have been identified, either.

Maybe not if you're a very poor typist, I suppose, but most developers I've met are at least marginally competent typists.

Reply on news.ycombinator.com