Take the 2-minute tour ×

I saw below test question the other day in which the authors used a flowchart to represent the logic of loops, and I got to thinking it would be interesting to do this with some more complex logic. For example, the closure in this immediately-invoked function expression (IIFE) sort of boggles me:

while (i <= qty_of_gets) {
    // needs an IIFE
    (function(i) {
        promise = promise.then(function(){
            return $.get("queries/html/" + product_id + i + ".php");

I wonder if seeing a flowchart representation of what happens in it could be more elucidating. Could such a thing be done? Would it be helpful, or just messy? I haven't the foggiest clue where to start, but thought maybe someone would like to take a stab. Probably all the ajax could go and it could just be a simple return within the IIFE.

logic test

share|improve this question
@JimmyHoffa It was originally from this SO question of mine. Maybe that gives it a bit more context..? Does it still seem bad to you? –  thomas Jun 24 '13 at 21:41
@JimmyHoffa Also thanks for that edit haha :) –  thomas Jun 24 '13 at 21:42

1 Answer 1

Unfortunately, I don't think a flowchart would be very helpful for this problem, because the code takes advantage of certain Javascript language details that I think would be quite hard to represent effectively in a flowchart, such as first-class functions and variable scope. I expect that you would find it easy to use flowcharts to represent some subset of Javascript code, but painful and unhelpful (because the flowchart would be complex) to represent other code. You could probably create a clear flowchart for what the code is supposed to be doing, though (ignoring the details of how it works around Javascript).

Although textual forms create a number of problems (such as yours), they seem to be the most efficient way of writing programs. I say this not because I hope it's true (I don't) or that I think it will always be this way, but because I've never really seen a better way to represent programming, in its full complexity, but through plain text. Unfortunately, neat projects like this don't seem to have caught on. Maybe that will change soon.

Let me mention that I'm not an expert -- my only experience on this matter is from using LabView, with which I eventually became disgusted due to the difficulty of implementing even simple logic and functions, let alone actual substantial abstractions.

That said, the code is extremely hard to understand, because:

  1. you have to think about whether the closures are "by reference" or "by value" (I put those in quotes because I'm not sure what the correct terms are). This is something that Javascript programmers often have trouble with. I believe the outer function is there specifically to deal with this issue, since it's immediately executed.

    You can investigate this issue by comparing the following two code snippets:

    var fs = [],    i = 0;
    while (i <= 4) {
        (function(i) {
                return i;
    var gs = [],    j = 0;
    while (j <= 4) {
            return j;

    Then execute some of the functions in fs and gs. Why are the results what they are?

  2. nested anything is relatively hard to understand, and typically obscures the solution. For comparison, nested loops are relatively hard to understand, as are nested objects/classes, nested tables, etc. The nested closures means there's multiple scopes and execution times to think about.

  3. i is shadowed, and I don't really see any good reason for that. Now, in every scope, you have to figure out which i is being referred to. Ouch. Poor kittens.

share|improve this answer
Thanks for this answer. Super in-depth. And confirmed some suspicions. Your second snippet was actually something I'd tried to compare with the first before, but hadn't found the time yet. You've given me an interesting direction to go in to experiment a bit. Thanks for your help! –  thomas Jun 24 '13 at 21:39

Your Answer


