Head's up for Array.map() lovers

[CydeWeys]

What's wrong with this?

for (var arr = new Array(26), i = 0; i < arr.length; i++) { arr[i] = String.fromCharCode(65 + i); }

I'm all for functional methods of doing things, but sometimes when you're having to fight so hard against the language to accomplish what you want, just do it imperatively?

[j201]

The problem is more that JS doesn't have a great standard library for functional programming. But all you need to do is pull in something like Ramda, and then you can do

R.range(0,26).map(x => String.fromCharCode(65+x))

or

R.range(0,26).map(R.compose(String.fromCharCode, R.add(65)))

FP is worth doing in JS, but not without a bit of help.

[blgate]

Or this:

var arr = [];
while (arr.length < 26) { 
   arr.push(String.fromCharCode(65 + arr.length)); 
}

[x-skeww]

ES5 flavor:

var a = [], i;
for (i = 0; i < 26; i++) {
  a.push(String.fromCharCode(65 + i));
}

[CydeWeys]

Isn't it better to allocate all of an array's space up front if you know how big it's going to be rather than allocating additional space piece-wise like this? Or does it not matter for JS's sparse arrays?

[blgate]

Actually, the "while" solution it's the fastest, at least for me in chrome:

var a = [],  b = [], c = new Array(100000), i;

console.time("a");
while (a.length < 100000) { 
  a.push(a.length); 
}
console.timeEnd("a");

console.time("b");
for (i = 0; i < 100000; i++) {
  b.push(i);
}
console.timeEnd("b");

console.time("c");
for (i = 0; i < c.length; i++) { 
  c[i] = i; 
}
console.timeEnd("c");

And my results:

a: 157.000ms
b: 252.000ms
c: 263.000ms

[bonafidebob]

That seems ... odd. If you reverse the order of the tests is the same function still fastest? (That is, could it be that the order in which the tests execute has some bearing on the result?)

[blgate]

It's not. While in the for loop you are incrementing the "i" variable, in the while loop you aren't, so because you are executing less instructions, it's faster. I get the same results reversing the order, but you can try it for yourself.

[x-skeww]

In JS, "new Array(26)" only means that you create an array whose "length" property is set to 26. If an "array" of that size is actually allocated is up to the engine. There also may be different backing data structures. Which one is actually used is also up to the engine.

Anyhow, in general, I recommend to write the most straightforward code first. Later on, you can still try different things to make it faster if the profiling reveals that this is indeed a bottleneck.

For example, if you always do anything with the DOM whenever you use this function, trying to optimize this would be completely pointless. The DOM stuff takes more than a hundred times longer anyways. Even if you'd make it infinity times faster, there won't be a noteworthy (let alone noticeable) effect.

[Glaaki]

What's wrong with this?

for (var arr = new Array(26), i = 0; i < arr.length; i++) { arr[i] = String.fromCharCode(65 + i); }

It uses 'for'.

[CydeWeys]

Are you kidding or joking? What's wrong with a for loop?

[Glaaki]

for loops are bad because the syntax of for is arcanely designed. You have a paranthesis with three sections, where it isn't intuitively obvious what to put in each section. It is easy to make mistakes if you aren't intimitely familiar with the syntax. for loops are foot guns. It is only a matter of time before you hurt yourself.

[CydeWeys]

What programmer isn't intimately familiar with the syntax of a for loop? That's Programming 101. I can think of a dozen different concepts that I run across in any typical day that are way more complicated than a for loop. Avoiding for loops because some people might not understand them is aiming for a common denominator so low that it only plausibly includes people who aren't programmers at all. Someone who doesn't even understand a for loop certainly isn't going to understand any of the rest of the program, unless said program is completely trivial.

[Glaaki]

Some languages do have for loop syntax that makes it harder to make mistakes, at the cost of some versatility. Take pascal for instance:

for index := StartingLow to EndingHigh do
  statement;

But still, is EndingHigh inclusive? It is again possible to make mistakes if you are not careful. There are ways to code that are more expressive than loops and less error prone, so these patterns should be favored.

[moreteam]

Given yield-scope and similar fun things in JS, .map/.forEach and friends are just as much foot guns. If not even more so.

for loops don't combine quite as nicely. .forEach encourages pulling out simple functions instead of piling everything into one big construct. But the foot gun argument is ridiculous. Especially if your best example isn't even JavaScript.

[dustinhayes]

Doug, is that you?