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++));
}
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.
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:
-
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:
<code>var fs = [], i = 0;while (i <= 4) {(function(i) {fs.push(function(){return i;});}(i++));}var gs = [], j = 0;while (j <= 4) {gs.push(function(){return j;});j++;}</code><code>var fs = [], i = 0; while (i <= 4) { (function(i) { fs.push(function(){ return i; }); }(i++)); } var gs = [], j = 0; while (j <= 4) { gs.push(function(){ return j; }); j++; } </code>var fs = [], i = 0; while (i <= 4) { (function(i) { fs.push(function(){ return i; }); }(i++)); } var gs = [], j = 0; while (j <= 4) { gs.push(function(){ return j; }); j++; }Then execute some of the functions in
fsandgs. Why are the results what they are? -
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.
-
iis shadowed, and I don’t really see any good reason for that. Now, in every scope, you have to figure out whichiis being referred to. Ouch. Poor kittens.
1