Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • First, I appreciate the schadenfreude here as much as the next hacker, but it appears this bug was in the Freescale code for the platform, not the code Microsoft wrote for the Zune. So it effects more than just Zunes...

    Second, the "some type inference systems" is misleading. The one type inference system that Andrew Koenig and MJD discuss is the Hindley-Milner [wikipedia.org] type system, which is used in ML and its descendants (OCaml, F#, Haskell, etc.). Koenig's example demonstrated that a recursive algorithm would

    • Thanks for the extra information.

      I think, ultimately, that part of the problem here could be alleviated by coupling things which must be coupled. For example, having a DayOfYear type with a type coercion system could partially help. Imagine the following type definition (in Perl 6, which doesn't do inferencing, of course, but bear with me):

      subset DayOfYear of Int where { 0 <= $_ <= 366 };

      Obviously, that still leaves edge cases, but I would imagine with inferencing, while you wouldn't get a compile time check, you couldn't get this:

      Int day = get_day_of_year();
      day++;   # runtime-fail if day was 365

      Even though that's an "Int" and its static type would be an Int (thus preventing catching this at compile time), you could at least get a runtime failure when there's no suitable method/function to be called on its dynamic type. This will prevent certain classes of problems, but at the end of the day, there are still plenty of edge cases for date math and trying to decouple the day of the year from the year is the real culprit here.

      If you merge that with Test::LectroTest [cpan.org] (like Haskell's Quickcheck [chalmers.se]), and you might actually catch those errors in testing, even if you didn't explicitly test for them.

      All of this, of course, if from a typing newbie, so if I'm talking complete bollocks, feel free to correct me!

      Er ... except, now that I think of it, since its static type is an Int, that still allows adding two days together, something which DayOfYear would have to forbid. This means that DayOfYear would have to be able to know all operators available for Int and disallow inappropriate ones, something which is just begging for trouble. I guess the decoupling is the real problem and I don't know that coercive typing would help :(

      • All of this, of course, if from a typing newbie, so if I'm talking complete bollocks, feel free to correct me!

        You're talking complete bollocks. :-)

        The kinds of things a strong static typing system can do is let you create types like DayOfYear, which let you specify a single calendar date, and prevents such nonsense like the 47th of April as being a "date". From there, you can create functions like addDays that take a DayOfYear and an integer number of days and return a new DayOfYear.

        What this code was doing was taking a count of days since the beginning of time, and figuring out the current date by subtractin

      • I think the mindblowingly clever technology you are looking for here is called a truth table. :-)