OT: Converting some js to Perl

[BrowserUk]

I'm converting some js, and have come across numerous examples of this construct:

if(function(){return a.indexOf(Lb)!=-1 }())return Mb;

I can convert that to:

if( sub{ return index( $a, $lb ) != -1  }->() ) return $Mb;

But this achieves the same thing (in Perl):

if( index( $a, $lb ) != -1 ) return $Mb;

The question(aimed at js progs): Is there anything inherent in the js code that my second Perl versions misses?

Or is this just a case of someone defining an inString() function, that then got inlined, but not unwrapped?

[LanX]

My guess: Either ...
• we don't see enough code
• or the programmer was cargo culting
• or the code is generated.

JS's way of scoping variables is significantly different to Perl, because of the hoisting of variable declarations in JS, i.e. the scope is the whole surrounding function from start to end, i.e. even prior to var !!!

As a consequence there is no block scope like in Perl

A usual work around for block scopes is to use a "throw away" anonymous function and to call it right away.

This doesn't seem to make sense here, because we don't see any potential conflict or even var declarations (see my first statement)

As a side note: there are plans to introduce a let command which works almost the same like my in Perl.

[BrowserUk]

or the code is generated.

That seems to be the case. It uses/is generated by GWT; which appears to generate obfuscated js client code from Java.

None the less, I've managed to extract the calculation code I was after.

[Anonymous Monk]

Hi. AFAIK js do not have inlining in c sense. So thats obfucargocult or codegen... https://stackoverflow.com/questions/35426280/function-declaration-as-if-statement-condition

[LanX]

> js do not have inlining in c sense.

This pattern is so common and most JS engines do so many optimizations behind the scene, that it would really surprise me if this is not already handled .

[Anonymous Monk]

Js programmers don't try to game engines. They strive go avoid engine quirks

[gsiems]

++ obfucargocult: my word for the day

[Anonymous Monk]

The index() function always returns -1 or greater, so I think, we could further simplify the perl code as such:

return $Mb if (index($a, $Lb) >= 0);

We could achieve the shortest code by writing:

index($a,$Lb)<0 or return $Mb;

OR if we could see the rest of the code, then write it all in one line like this:

return index($a, $Lb) < 0 ? $Xb : $Mb;

The JavaScript code, of course, could have been more clearly written as such:

if (a.indexOf(Lb) >= 0) return Mb;

There is no need to enclose the code in self-executing anonymous functions in JS as long as the code is just a few lines or uses no private variables. It just makes no sense. It just makes the program slower.

Function calls waste CPU time. I did a benchmark test one time. So, if a part of the program runs in a cycle many times, then it's best to write it in such a manner that it involves as few function calls as possible.

For example, if a sort algorithm needs to swap two elements of an array, it's best to not write a swap() function for that. Your program will run a lot faster without calling swap().

Prototype functions are the worst. If you call ARRAY.swap(index1, index2) vs swap(ARRAY, index1, index2) the first function call will be 2-3X slower than the second one. There is no difference in the output result. It's the same thing, but one makes your code extremely inefficient. I know, I am way out on a limb here, but just wanted to let you know. Speed matters! You know, users don't care about how the code looks under the hood. All they care about is the speed of the website.

[BrowserUk]

The entire question was one of whether that particular construct -- a library call wrapped in an anonymous function at the call site -- had any subtle side effects that were not obvious to me as a programmer with limited js experience. The upshot is that the js is generated code (GWT) and the anonymous function wrapped call to index() is probably an isFound() or doesContain() method call, that get optimised down by the Chrome js engine.

As for the Perl; the part of the js code -- a fairly obscure algorithm -- I was interested in, was brute force extracted to perl; then refactored to suit my needs, in my favorite and most natural programing language, then that was translated again into yet a third language; so the performance of the Perl code wasn't important; ensuring that I understood the subtleties of the somewhat obfuscated js code was.

[Your Mother]

I did a benchmark test one time.

For JS in particular this would have to be repeated somewhat often on multiple platforms to remain current knowledge since major features keeping rolling in and the engines get tweaked and completely swapped out now and then.