• (nodebb)
    The language, in this case, is JavaScript, which has many possible options for iterating across an array.

    TRWTF

  • Jonathan (unregistered) in reply to Dragnslcr

    But is it? After all, which language would recommend instead which is available in every web browser?

  • OM222O (unregistered)

    TRWTF is JS but Python uses StopIterationException to end loops so maybe this dev was a core Python developer? (I love Python, don't be mad)

  • (nodebb) in reply to Jonathan

    The point that JS has many ways to iterate across an array is of almost no importance whatsoever. After all, even in iteration-challenged languages like C, there are multiple ways of doing it (while(true) with a conditional break, for(......), etc.), and more advanced languages, including C++11 (or later), have all that plus dedicated array-iterating structures such as C++'s for ( const auto &element : collection ).(1)

    Ultimately, all that's required is that the programmer thinks about what he or she is doing. Hmm. OK, that does mean that the large choice of ways of doing it is TRWTF, because the chances of getting a typical "grunt"-level JS (or other language) programmer to think are ... minimal.

    But that comes back to the thing I've mentioned before:

    TRWTF is programmers...

    (1) This is one of those instances where my normal antipathy toward auto is not applicable because element's type is clearly, by definition, "a const reference to whatever the type is of an element of collection".

  • (nodebb)

    Here I thought it would end with an ArrayIndexOutOfBoundException... but, surprise, this is JavaScript so when we have an array index out of bound exceptional situation we get.... undefined.... Sure, the code stinks, but this undefined BS takes it to Code of Cthulhu-level of insanity... Although, maybe JavaScript doesn't really play in that league... I'm still naively hoping it will never take down a nuclear plant... but then again... there was that gauge on the BACKSIDE of the panel (or whatever other UI idiocy took down Three Mile Island... JS is, after all, used in UI:s...)

  • NoLand (unregistered)

    I think, the art of building an endless loop is mostly independent from the programming language used.

    (BTW, this, where we hand over to another function, is a classic use case of foreach, which would also prohibit this kind of error, JS or not. Also, iterators, which are quite messy in terms of runtime efficiency, in about any language.)

  • Naomi (unregistered) in reply to OM222O

    To be clear, Python's for loop expects the iterator it's looping over to raise StopIteration to signal when it's done, and handles it automatically. User code doesn't need to think about it (unless it's advancing the iterator manually for whatever reason).

    I know @OM222O knows this; I'm just clarifying for anyone else who doesn't.

  • NoLand (unregistered) in reply to Erik

    Although, maybe JavaScript doesn't really play in that league...

    Mind that an ArrayIndexOutOfBoundException doesn't play well with the concept of sparse arrays. (How would we know that there isn't some kind of valid void at the end?) Arrays are much more general and versatile in JS (much like in Perl), as opposed to e.g. Python, where there are multiple types and variants for various use cases, which, on the other hand, may encourage type errors.

  • Hasseman (unregistered)

    Only two things hard while programming

    1. Name things properly
    2. Cache invalidation
    3. Off by one errors
  • Martin Tilsted (unregistered) in reply to Jonathan

    Use Java. It can be compiled to javascript and run in the browser.

  • Tim (unregistered)

    Though relying on an exception thrown by an inner function is obviously terrible, I think the "infinite loop with break or return" paradigm can often produce more concise and readable code. quite often the loop termination condition is most obvious part way though, not at the beginning or end.

    Having said that, iterating over an array is obviously not such a case. Though I can't remember last time I wrote an indexed loop in javascript; 90% of the time it's .map() and 10% of the time it's for...of

  • Officer Johnny Holzkopf (unregistered)

    My recommendation: "Using endless loops and exceptions for flow control. A practical lesson in advanced AI driven programming for expert`s". Buy now. Buy now more. Buy... and be happy.

  • (nodebb)

    In the early days of Java there were people of, um, let's just say limited understanding, who decided that iterate until exception was "more efficient". You see, you didn't have to spend nanoseconds comparing a loop index so wow! savings!

    These people didn't understand, of course, just what a clusterfuck creating, throwing, and catching an exception is (because, exceptions are supposed to be reserved for exceptional cases). Not just the allocation of dozens of objects, but also the disruption to the CPU's caches caused by the non-locality of the instructions it suddenly has to execute.

  • (nodebb)

    But this works no matter what the size of the array is!

  • JJ (unregistered) in reply to Erik

    No, you're reading it wrong. The bloc 2 partial happened due to a) bad training, b) a stuck pilot operated relief valve, c) an open check valve, d) block valves in the emergency feedwater pump lines to the steam generators left closed after a test a few days earlier and e) a bad ops system design.

    All of the above lead to a perfect storm and a confederacy of dunces. Particularly a.

    Oh, and the gauge to which you were referring wasn't on the backside of anything. It was in the end line, the tail pipe, which led from the PORV to the coolant relief tank, and was presented to the ops. If a) hadn't happened, especially given e), the ops would've noticed the overtemp earlier (or at all).

  • No point (unregistered)

    Poor junior developer that applies his best practices of checking item for undefined before trying to doSomethingWithItem

  • Twither (unregistered) in reply to NoLand

    Also, iterators, which are quite messy in terms of runtime efficiency, in about any language.

    Rust would like to have a word.

  • (nodebb) in reply to hlship

    That, plus comparing the loop index has to happen anyway, under the hood. After all, that's how the language notices that you've gone past the bounds of the array, so it knows when to throw the exception.

    I guess it's possible that in the early days, optimizers weren't good enough to combine the loop's comparison and the array access's comparison into a single operation, in which case skipping the explicit comparison might have done some good for big enough arrays. But there's no way it has any benefits nowadays.

  • (nodebb) in reply to Dragnslcr

    There's a forum thread out there with the many, many ways to iterate with Ruby. It's horrifyingly impressive.

  • (nodebb) in reply to Jonathan

    WebAssembly

  • Peter of the Norse (unregistered)

    This reminds me of a PHP programmer I knew who didn’t like to use null for anything. Instead, the method would throw an exception. A generic exception. (And since he was the lead, everyone followed suit) That exception would then trigger the cache for invalid values. You can guess what happened next. One DB error cascades into hundreds of caches and the whole system grinds to a halt. After the bug was fixed, and every single cache was cleared, it was my job to turn them into InvaldArgumentExceptions. Again, throwing exceptions are slower than return null;

  • löchlein deluxe (unregistered)

    :deep sigh: Well whatcha gonna do. There's seventeen ways to die, or iterate, in JS, depending on whether you have an Object or not, want to include properties or not, including those inherited from prototypes or not. (I'll bet you this was intended to fail on accessing an invalid index.) I don't blame somebody who only once every six months uses JS to bash together JS snippets until it kinda sorta works and that's not a shotgut tied to your foot at all. (Well, I blame them for not giving the job to somebody more qualified and/or get the mentoring.)

  • (nodebb)

    When I first learned to program (Sinclair ZX81 BASIC, 1983) I wrote a little game that allowed you to use the cursor keys so navigate a character around the screen and "eat" other characters. The idea was to clear the screen before the FOR loop ran out of increments. Subsequently I wrote other programs, but the FOR loop was still my goto (pun intended) for any long running anything... but the stupid thing would always just eventually finish and I had to rerun my program doing whatever. Finally I heard about the mighty GOTO command and I knew I had the power of running programs that never ended. Now I'm an enterprise developer. Do with that what you want...

  • Mike Sandbox (unregistered) in reply to JJ
    Comment held for moderation.

Leave a comment on “While This Works”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article