[skybrian]

(Raises hand.) I prefer the for loop. Pushing items to an array is idiomatic Javascript for creating an array. An if statement is an idiomatic way to do it conditionally. It's also easier to debug.

The map and filter methods are nice too, but they're for one-liners.

[nine_k]

Writing assembly was the idiomatic way of programming before Fortran and human-readable languages came.

Writing with goto was the idiomatic way before Algol and structural programming came.

Having only a handful of scalar types was the idiomatic way until structural data types came (and later objects).

Writing programs as fragments of text that get glued together somehow at build time was the idiomatic way until module systems came. (C and partly C++ continue to live in 1970s though.)

Callback hell was the idiomatic way to do async until Futures / Promises and appropriate language support came.

Sometimes it's time to move on. Writing idiomatic ES5 may feel fun for some, but it may not be the best way to reach high productivity and correctness of the result.

[skybrian]

Making analogies like this doesn't prove anything, they're just suggestive. All I'm getting out of this is that you think for loops are old-fashioned.

[Jean-Papoulos]

That's because they are. Functional code is more readable. And if you look back, basically all advances in programming languages have been about "making stuff more readable". Thus, for loops (for this usage) are "old".

[Joker_vD]

> Functional code is more readable.

There is no way that

    name: R.pipe(R.prop('name'), R.toUpper),
    age: R.prop('age'),
    isAdult: R.always(true)

is more readable than

    name: user.name.toUpperCase(),
    age: user.age,
    isAdult: true

[nine_k]

Certainly so! The first example is needlessly contrived.

But instead of

  for (const i=0; i < data.length; i++) {
    new_data[i] = old_data[i].toUpperCase();
  }

you can write

  const new_data = old_data.map((x) => x.toUpperCase());

I think it's both more clear and less error-prone.

[nuancebydefault]

The second code does not compile and introduces a new dependency.

[kazinator]

But those are both functional, or can easily be.

[skybrian]

You say it’s more readable and I disagree with that!

Is this just fashion? Is there a way to settle it other than “I like it better?”

[klibertp]

> Is this just fashion?

Yes.

Readability is a characteristic of the reader, not what is being read.

This simple truth seems to be so hard for many people to internalize. My theory as to why is that most programmers never get exposed to drastically different and unfamiliar languages and styles of programming. If they were forced to confront and internalize 2-3 different ways of writing code, they would realize this truth.

Personally, I once thought Lisp was unreadable... until I learned it. I once thought BASH was unreadable... until I learned it. Same with half a dozen other languages. Same for styles. "Readability" is just a familiarity and proficiency of the reader.

[kazinator]

30 plus years ago, it was a common trope in programming circles that C code is unreadable, except to, or perhaps even to the author.

[CRConrad]

> Functional code is more readable.

All I get out of that is that you like functional code.

[bobthepanda]

I will say in 2024 i feel like for/of or forEach would at least let you avoid the boilerplate of an index.

[skybrian]

Yes, I agree.

[mabster]

I don't code in JS very often, so there's that.

Both sets of code were fine, but I understood the loop variant instantly, while it took me a bit longer with the FP code.

As a side note: The only real JS I did was optimising some performance critical code, and I did have to refactor a number of FP chains back to loops. This was because the FP way keeps constructing a new list for each step which was slow.

[asddubs]

I also prefer the loop, I would negate the condition and use continue, but otherwise leave it unchanged. I don't have a problem with the functional version but it doesn't scan as well to me.