• Raymond Meijer (github)

    Zeroth comment...

  • Raymond Meijer (github)

    Zeroth comment...

  • Hans (unregistered) in reply to Raymond Meijer

    repeated one times?

  • Steve (unregistered) in reply to Hans

    It's either user error, or a subtle off-by-one joke ...

  • Robin (unregistered)

    It took me more than a few moments to figure out what was wrong with the Prime videos one. Not exactly an off by one error, in fact I really can't imagine what kind of plausible wtf code would result in this - so almost certainly it's something implausible enough to feature on here if anyone happens to know the details!

  • Robin (unregistered)

    Oh I see now, one is reversed while the other isn't. Interesting...

  • Vault_Dweller (unregistered) in reply to Robin

    My guess: the images and details are fetched independently, and one of them is accidentally sorted descending instead of ascending.

  • Meir (unregistered)

    So in other words, about as accurate as everything else out of the CDC.

  • Brian (unregistered) in reply to Robin

    It smells like a case of parallel arrays, with incorrect assumptions about the order in which the data is fetched.

  • Whosy (unregistered)

    I've had an issue similar to the Prime Video above.

    The cause was using React SSR and Javascript's array sort function. The spec at the time didn't require sort to be stable, so moving a single element in an array (e.g. Move a selected item to the top) didn't necessarily preserve the order of all the other elements.

    Since the nodejs engine and browsers used different sorting algorithms, the results differed even between browsers and all the elements got jumbled up when React loaded in!

  • Prime Mover (unregistered) in reply to Brian

    It's a good sign of a rookie developer (or just a stupid one) that they hold obviously directly one-to-one correlated data in two parallel arrays rather than construct a more comprehensive data object to handle the damn thing properly.

  • MaxiTB (unregistered)

    I don't get it, why is it so hard to understand the difference between the index of a number and the count of numbers in a set for some people? When I have a set N0 (which is what the index of an array is based one obviously, because it's the first unsigned integer number), then you have a set with the number 0 and the count of the set is one. If you have the next number in the set, 1, then obviously the count of the set is 2. Should make sense to everyone, especially people with a science degree and high school levels of math knowledge.

  • Ryan (unregistered) in reply to MaxiTB

    Don't assume the science degree or even the HS diploma. I started writing software when I was 10. If github and gitlab were a thing back then who knows how many WTFs I might have published.

  • Дмитрий (unregistered)


  • (nodebb) in reply to MaxiTB

    It clearly is difficult. For me, it’s difficult because I’ve been spoilt by Ada; Arr’First, Arr’Last, Arr’Range, Arr’Length; so when I’m faced with actually working out the indexes my mind goes blank

  • Steve W (unregistered) in reply to Robin

    Well, obviously, they converted from a big-endian machine to a little-endian one in the middle of development. What else could it possibly be? Oh, you wanted "plausible"...nevermind.

  • Aha (unregistered)

    A/B testing their ranking algorithm.

  • Peter D (unregistered) in reply to Robin

    Off by one, in combination with some bit-twiddlling code?

  • jay (unregistered) in reply to Prime Mover

    "It's a good sign of a rookie developer (or just a stupid one) ..." Or the kind of lazy that says, "It's too much trouble to do it right. I'll just do it this quick and easy way. That will take 5 minutes less to write and 2 hours longer to get working, so I'll save time."

  • dusoft (unregistered) in reply to Robin

    Some weird for loop.

  • MaxiTB (unregistered) in reply to sjw

    Ha, Ada is a special case. It is from a time where there was still a discussion over the zero being part of the set of natural numbers (I a cold war kid too, so I still remember the time before ISO). Luckily it's an odd bunch, and there is not that much Ada left. Other examples would be the Pascal family and COBAL; both practically extinct as well beside a bit of legacy code.

    I remember I struggled first as well with an first index element being 0 when I was 8 and started coding assembler on the C64 but it helped to keep in mind that the first element is indexed by address plus 0, not address plus 1 :-)

  • Diane B (unregistered)

    TRWTF is the death count decreasing. They really buried the lede there.

  • (nodebb) in reply to MaxiTB

    Other examples would be the Pascal family and COBAL; both practically extinct as well beside a bit of legacy code.

    COBOL, but whatever. And there are vast quantities of legacy (translation: old, but still in use) COBOL code out there.

  • Donald (unregistered) in reply to Robin

    Seems pretty straightforward. Just store all the times to high precision, and round just before display. Then the individual times are rounded up, while the total is rounded down. 3.8+3.8+3.7=11.3 turns into 4+4+4=11 with rounding.

  • RussellWakely (google) in reply to Prime Mover

    Playing devils advocate, I'm assuming that the operations to fetch basic film meta-data, and also fetch images are separate ones - so the actual list of film titles, with data about each film can be shown before images are available (if you are scrolling on your phone through a very large set of film titles, the app might just be fetching images for films adhoc when they are needed, as the images probably represent a lot more data than just the text / meta-data per film). They might have a single data structure representing all films, and just be appending the image data incorrectly.

  • Haitham (unregistered)
    Comment held for moderation.

Leave a comment on “The Hardest Problem”

Log In or post as a guest

Replying to comment #:

« Return to Article