Introduction to Computer Graphics by Frank Klawonn



  • Some of the code examples that come with this textbook were so awful that I snapped and decided I had to share them. Perhaps I'm overreacting, but you can be the judge. Also, apparently the text was written originally in German, because while reading it you'll encounter untranslated phrases. Anyway, here's the author's wait method:

      public void sustain(long t)
      {
        long finish = (new Date()).getTime() + t;
        while( (new Date()).getTime() < finish ){}
      }
    



  • That's nothing. At my previous job I had to deal with a really badly running web app, which only worked on IE 6, took 10 seconds for just switching from one to another form field (for all the validation, you know), and crashed IE 6 because of "out of memory" when working with it for half an hour (which you NEEDED to complete your task because it was so slow and inefficient). Also, it took 100% CPU and also hung the windows desktop while it was "validating input".

    I then checked the code... and it had some very interesting "gem":

    function waitfor(ajax)
    {
        while(ajax.readyState != 4)
        {
            setTimeout("", 100);
        }
    }
    

    So, quite obviously, it spammed timer objects... and never clearTimeout'ed them of course (which you still should do even if the timer has expired, to free its ID).

    That sure explained both the high CPU load, and the memory leak... I mean, there's sure more of that in the script mess.



  • @OperatorBastardusInfernalis said:

    function waitfor(ajax)
    {
    while(ajax.readyState != 4)
    {
    setTimeout("", 100);
    }
    }

    This one definitely takes the cake!



  • @iconoclast said:

    Some of the code examples that come with this textbook were so awful that I snapped and decided I had to share them. Perhaps I'm overreacting, but you can be the judge. Also, apparently the text was written originally in German, because while reading it you'll encounter untranslated phrases. Anyway, here's the author's wait method:

      public void sustain(long t)
    {
    long finish = (new Date()).getTime() + t;
    while( (new Date()).getTime() < finish ){}
    }

    This guy doesn't even know about Thread.Sleep() - a fundamental C# language construct - and he's writing books about the language? If that's the sort of shit that can get published in textbooks nowadays, it's no wonder that universities are churning out so many CompSci graduates who can't write code to save their lives.



  • @The_Assimilator said:

    and he's writing books about the language? If that's the sort of shit that can get published in textbooks nowadays,
     

    I'm guessing there's a whole spectrum of textbook quality. Some are truly awful.



  • @OperatorBastardusInfernalis said:

    and never clearTimeout'ed them of course (which you still should do even if the timer has expired, to free its ID).

    A perfectly good example of cargo cult programming, by clearTimeouting you feel that you have done your utmost to prevent memory leaks, in truth you have performed a completely redundant task, you have told the garbage collector nothing it did not already know.



  •  @OperatorBastardusInfernalis said:

    That's nothing. At my previous job I had to deal with a really badly running web app, which only worked on IE 6, took 10 seconds for just switching from one to another form field (for all the validation, you know), and crashed IE 6 because of "out of memory" when working with it for half an hour

    No, that's nothing! At my previous job I had to deal with a really (for real!) badly running web app, which only worked on IE5, took 60 seconds for just switching from one to another form field and crashed IE5 because of "out of memory" when working with it for 15 minutes.

    I then checked the code... and it had some very interesting "gem":

     

    function waitfor(Godot)
    {
        while(Godot.readyState != 4)
        {
            setTimeout("", infinite);
        }
    }
    

     



  • @The_Assimilator said:

    @iconoclast said:

    Some of the code examples that come with this textbook were so awful that I snapped and decided I had to share them. Perhaps I'm overreacting, but you can be the judge. Also, apparently the text was written originally in German, because while reading it you'll encounter untranslated phrases. Anyway, here's the author's wait method:

      public void sustain(long t)
    {
    long finish = (new Date()).getTime() + t;
    while( (new Date()).getTime() < finish ){}
    }

    This guy doesn't even know about Thread.Sleep() - a fundamental C# language construct - and he's writing books about the language? If that's the sort of shit that can get published in textbooks nowadays, it's no wonder that universities are churning out so many CompSci graduates who can't write code to save their lives.

    I'm going to take a turn as the pedant. Googling the book title says Java. I'm pretty sure C# doesn't have a Date class... it just has a DateTime class, yes?



  • Wrong. setTimeout returns an ID, not an object.

    > t = setTimeout("alert(1)", 100);
    75
    > t
    75
    > typeof(t)
    "number"
    

    And as it returns a number, it's not exactly useful for the garbage collector. You could store it in a string, or as part of a string, could even encrypt it, or even forget it entirely and later possibly do a clearTimeout over the range of all possible integers (if you want to end up here). And in all of these cases, the browser is required to keep the internal timer object.



  • The WTF gets event worse when you realize that every control in IE, including the timeout, is a reference-counted COM object.  Which means that any circular reference that may hapen to pop up somewhere between Javascript and a control will leak.  Microsoft has had varying success in mitigating the problem from IE7-9, with IE7 being the worst. 

     To confirm, try rendering 500 textboxes in an AJAX control in IE.  Now try it in Firefox.



  • @OperatorBastardusInfernalis said:

    Wrong. setTimeout returns an ID, not an object.

     

    > t = setTimeout("alert(1)", 100);
    75
    > t
    75
    > typeof(t)
    "number"
    

    And as it returns a number, it's not exactly useful for the garbage collector. You could store it in a string, or as part of a string, could even encrypt it, or even forget it entirely and later possibly do a clearTimeout over the range of all possible integers (if you want to end up here). And in all of these cases, the browser is required to keep the internal timer object.

    First of all, please make a quote when you answer anything but OP, otherwise it is really hard to follow the debate.

    Second, I'd never talk about what a garbage collector does or does not collect without doing an actual test, I know my WTFs too well to presume that I know anything for sure about the behaviour of those constructions.

    In any case, your argument seems to work given the presumption that the browser must have a corresponding timeout object in store whenever clearTimeout is called. The thing is, it doesn't need to have such an object. Whenever a timeout has been cleared, or has happened, the defined behaviour of clearTimeout given the id of that timeout is "do nothing", this makes the most obvious, easiest and fastest implementation of clearTimeout handling be: Have an index of all pending timeouts, remove timeouts from this index (and everywhere else) whenever they are executed or cleared. If clearTimeout is called and it does not find the given id in the list, it should simply do nothing further.

    It sounds like you have mixed this up with the functionality in a lot of other garbage collected languages where obtaining the memory address of an object will render that object protected from garbage collection and a "free" command will undo that protection. The id of a timeout is not a memory address, it is just an indexed id, and nothing bad will happen by searching an index for an id it does not contain. clearTimeout is NOT the equivalent of a free command, it is a command that cancels the timeout, and nothing else.



  • Sorry, I should have specified that the code snippet was Java. Still, he could have used Thread.sleep(), System.currentTimeMillis(), javax.swing.Timer, or something else that didn't involve creating a new Date object every loop iteration. Also, in the same example he puts an entire animation in the AWT frame's paint() method.



  • @The_Assimilator said:

    This guy doesn't even know about Thread.Sleep() - a fundamental C# language construct - and he's writing books about the language? If that's the sort of shit that can get published in textbooks nowadays, it's no wonder that universities are churning out so many CompSci graduates who can't write code to save their lives.

    You know how it is: Those who can, do. Those who can't, teach. Those who can't teach, write textbooks...



  • @blakeyrat said:

    @The_Assimilator said:
    @iconoclast said:

    Some of the code examples that come with this textbook were so awful that I snapped and decided I had to share them. Perhaps I'm overreacting, but you can be the judge. Also, apparently the text was written originally in German, because while reading it you'll encounter untranslated phrases. Anyway, here's the author's wait method:

      public void sustain(long t)
    {
    long finish = (new Date()).getTime() + t;
    while( (new Date()).getTime() < finish ){}
    }

    This guy doesn't even know about Thread.Sleep() - a fundamental C# language construct - and he's writing books about the language? If that's the sort of shit that can get published in textbooks nowadays, it's no wonder that universities are churning out so many CompSci graduates who can't write code to save their lives.

    I'm going to take a turn as the pedant. Googling the book title says Java. I'm pretty sure C# doesn't have a Date class... it just has a DateTime class, yes?

    Correct, my apologies. I think my irrational hatred of Java is blinding me, although in my defence both languages have a same-named class that has a same-named method (differing only by the case of the first letter) that does the same thing. And my point still stands, he obviously doesn't know nearly enough about the language to be writing a book about it.

    @iconoclast said:

    Also, in the same example he puts an entire animation in the AWT frame's paint() method.

    In C#, if you do custom painting and your painting code throws an exception, everything goes to hell. Haven't done Java custom painting in a while but I assume it behaves the same way.



  • @OperatorBastardusInfernalis said:

    function waitfor(ajax)
     

    Oh god. Someone really didn't get the idea here.



  • Is he Herb Schildt's long lost brother?


Log in to reply