I get it. I really do. Javascript is intended to work in a (mostly) single threaded way and allowing it to sleep could gum things up tremendously. Reading that and similar links has been beneficial and I’ll be making time for more.
What brings this up is that I was debugging a piece of Javascript code where I thought it would be clever to graphically render the different 3D hidden point tests I was running to see why some of them weren’t being tested. I could add the temporary renderings of the test point and each plane to be tested against, set a breakpoint at the end, and then click like mad through all the requisite loops. Of course, if I clicked too quickly I could cause the browser or its debugger to hang. Therefore I figured that I could eliminate the clicking by inserting sleep()-like statements that would allow me to watch the proceedings without having to do anything and without running the risk of going so fast I’d lock things up again.
However, my digging around for the fabled sleep()-like statement led me (inevitably, it seems) to a number of StackOverflow discussions on the subject. Those a) made it clear that there was no such animal and b) asserted that it would be a really, really bad idea for one to exist. I did see how I could have refactored the code to use the setTimeout(func, delay) construct and there were a number of other suggestions and discussions of their relative merits. Since the point was to test the code as it was and not to turn it inside out, which may have obfuscated the very thing I was trying to identify, I ultimately chose to click patiently and use conditional breakpoints to save some of the work as I honed in on the problem.
I have often used sleep()-like statements for animations and real-time processes but I can appreciate the desire of the language designers to omit the capability from this particular language. I’m not always a fan of designers’ desire to keep programmers from shooting themselves in the foot. I own my foot and if I want to be able to shoot the thing off that should be my right, should it not? That said, some features are bound to get abused, choice is not infinite, and sometimes you have to just accept things the way they are. Design decisions like these assuredly save time, effort, and frustration on net across the entire user base over the life of the product, and I can respect that. I also appreciate that different programmers can work for a long time in different subject areas and not encounter the same concerns. Conversely, I appreciate as well that some subjects seem to come up over and over again no matter what people are doing.
Interestingly, the poster who started one of the longer discussion threads wanted the capability for the same reason I did, as a known hack for testing and with no intention of using it in production code. What killed me was the insistence of so many commenters that there could be no valid use for such a construct. I’m guessing that some of those strongly expressed opinions grew out of knowledge of the language’s underlying structure and its application while others arose from ignorance of possible uses for the capability. Like Dennis Miller would observe, I could be wrong. In any case, as I mentioned above, I will definitely be studying the language’s underlying structure in greater detail, and expect to enjoy myself while doing so.
Oh, and the graphical debugging effort? Worked like a charm.