[michaelteter]

The first example complained about the refactor appealing to functional thinkers (implying that it would be difficult to grok by the existing devs), but then the “improved” version is virtually the same save for the (unnecessary?) use of Ramda in the first.

And while many devs are resistant to try functional ways, this first example reads so much better than the original code that I find it impossible to believe that some prefer the imperative loop/conditional nesting approach.

[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.

[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.

[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.

[p2501]

Aesthetic aside, I am under the impression that people start programming, by and large, with imperative for/if style => so the imperative style is readable by more people. Even for more experienced programmers, reading imperative probably cost less energy, since it is more internalised?

Futhermore, in JS, the functionnal style is less performant (nearly twice on my machine, i assume because it do less useless memory allocations)

So, same functionnality, readable by more people, more performant? The imperative example seems like the better code.

[The_Colonel]

> Even for more experienced programmers, reading imperative probably cost less energy, since it is more internalised?

I disagree. For-cycles are usually more difficult to reason about, because they're more general and powerful. If I see "for (...", I only know that the subsequent code will iterate, but the actual meaning has to be inferred from the content.

Meanwhile, a .map() or .filter() already give me hints - the lambda will transform the values (map), will filter values (filter), these hints make it easier to understand the logic because you already understand what the lambda is meant to do.

Other benefits stem from idiomatic usage of these constructs. It's normal to mix different things into one for-cycle - e.g. filtering, transformation, adding to the resulting collection are all in the same block of code. In the functional approach, different "stages" of the processing are isolated into smaller chunks which are easier to reason about.

Another thing is that immutable data structures are quite natural with functional programming and they are a major simplification when thinking about the program state. A given variable has only one immutable state (in the current execution) as opposed to being changed 1000 times over the course of the for-loop.

[persnickety]

> If I see "for (...", I only know that the subsequent code will iterate

And then someone slaps do {} while(0) in a macro.

[math_dandy]

No need to fear mutable local state. Shared state is where immutable data structures really shine.

[joshka]

I, a Datapoint of 1, find the functional style to generally express the ideas of what's happening to be significantly easier to grok. Particularly if intermediate variables and conversion constructors are introduced rather than relying on full chains. E.g.:

    function processUsers(users: User[]): FormattedUser[] {
      let adults = users.filter(user => user.age >= 18);
      return adults.map(user => FormattedUser.new_adult(user));
    }

On the performance tip, what scale are we talking? Is it relevant to the target system? Obviously the example is synthetic, so we can't know that, but does it seem like this would have a runtime performance that is meaningful in some sort of reasonable use case?

[zahlman]

> I am under the impression that people start programming, by and large, with imperative for/if style => so the imperative style is readable by more people.

IMO, this is a simple consequence of technology moving faster than society. There are still instructors out there who learned to program in an environment where the go-to options for imperative programming were C and FORTRAN; the go-to options for other paradigms (if you'd even heard of other paradigms) were things like Lisp, Haskell and Smalltalk; and CPU speeds were measured in MHz on machines that you had to share with other people. Of course you're going to get more experience with imperative programming; and familiarity breeds comprehension.

But really, I believe strongly that the functional style - properly factored - is far more intuitive. The mechanics of initializing some output collection to a default state (and, perhaps, the realization that zero isn't a special case), keeping track of a position in an input collection, and repeatedly appending to an output, are just not that interesting. Sure, coming up with those steps could be a useful problem-solving exercise for brand-new programmers. But there are countless other options - and IMX, problem-solving is fiendishly hard to teach anyway. What ends up happening all the time is that you think you've taught a skill, but really the student has memorized a pattern and will slavishly attempt to apply it as much as possible going forward.

> Futhermore, in JS, the functionnal style is less performant (nearly twice on my machine, i assume because it do less useless memory allocations)

Sure. Meanwhile in Python:

    $ python -m timeit "x = []" "for i in 'example sequence':" "  x.append(i)"
    500000 loops, best of 5: 796 nsec per loop
    $ python -m timeit "x = [i for i in 'example sequence']"
    500000 loops, best of 5: 529 nsec per loop

... But, of course:

    $ python -m timeit "x = list('example sequence')"
    2000000 loops, best of 5: 198 nsec per loop

Horses for courses.

[kazinator]

Functional programming is more intuitive for many pure data transformation tasks.

It's not more intuitive for the entire system.

When you make a new file in a file system, you're already violating functional programming, even if you atomically create that file with all the content specified, and make it immutable.

You must construct a new file system which is like the old one, but with that file, and then have the entire system tail call into a world where you pass that new file system as a parameter, so that the old one is not known (garbage).

Unix has been the most successful system in getting partial functional programming into ordinary people's hands.

A Unix pipeline like < source-file | command | command | ... | command > dest-file is functional except for the part where dest-file is clobbered. Or at least can be functional. The commands can have arguments that are imperative programs (e.g. awk) but the effects are contained.

In the famous duel between Doug McIlroy and Knuth in solving a problem, in which McIlroy wrote a concise Unix script combining a few tools, McIlroy's solution can be identified as functional:

  tr -cs A-Za-z '\n' |
  tr A-Z a-z |
  sort |
  uniq -c |
  sort -rn |
  sed ${1}q

Nowhere is there any goto statement or assignment.

[GuB-42]

One problem I have with functional programming is that I find it hard to debug.

With imperative programming you can follow a program step by step, line by line, it can be done with a debugger, pen and paper, or in your head.

With functional programming, not so much. It runs functions. What do these functions do? Don't know, they are pieced up from someplace else in the code. And thanks to lazy evaluation, they may not even exist. In the design phase, it is mostly a good thing, as it is flexible, and pure functions are less likely to make a mess than functions with side effects, but there will be a point where the program will not behave as it should, no matter your paradigm. And that's when it becomes a problem.

It is also a problem with object programming if you abuse abstraction, in fact, it is a general problem with abstraction, but functional programming makes it the default, whereas imperative programming is concrete by default.

As for the Python example, I am a bit surprised that the optimizer didn't catch it, all three are common and equivalent constructs that could have been replaced by the most performant implementation, presumably the third one. But well, optimizers are complicated.

[vasco]

People think imperatively though. If I think of visiting my friend, grabbing gas on the way back, the way I'll visualize the steps is not functional.

[whilenot-dev]

I disagree. People are sometimes just forced to think imperatively when dealing with computers, but I usually think declarative when I design my programs.

Say if I want to filter a sequence of users and omit users below the age of 18, I'll construct my predicate (a "what"), and want to apply that predicate to create a new sequence of user (another "what").

I really don't want to tell a computer how to process a list every single time. I don't care about creating an index first and checking the length of my list in order to keep track that I process each user in my list sequentially, and don't forget that important "i++". All I want at that moment is to think in streams, and this stream processing can happen in parallel just as well for all I care.

But I also do think Python, Haskell etc. are the most expressive here with list comprehensions. It can't get more concise than this IMHO:

  users_adult = [
    user
    for user in users
    if user.age >= 18
  ]

[The_Colonel]

That's quite debatable.

In this case, you first declare the end-goal - visit a friend and have full gas tank, with the actual steps to achieve them being much less important and often left to be defined at a later point (e.g. which particular gas station, which particular pump etc.). This corresponds more to functional thinking.

An imperative thinking would correspond more to "I will sit in the car, start the engine, ride on highway, stop at address X, converse with Y, leave 2 hours later, stop at gas station X" - in this case the imperative steps are the dominant pattern while the actual intent (visit a friend) is only implicit.

[vasco]

Your second part is how I think and how I think most people think. That's exactly what I meant.

[The_Colonel]

So when you arrange the visit with your friend two weeks in advance, you first think about sitting in the car, driving out of the garage, getting on the highway, turning on the radio, parking the car, ringing the bell and this other myriad of actions, and the actual talking with the friend is just one of the actions, with no prominence over the others?

I certainly don't think like that. My main goal is to visit a friend. The transportation is subordinate, it's only a mean to the goal, an implementation detail which I don't care about much. I might even take a train instead of driving the car, or even ride a bike, if I feel like it and the weather is nice on the day of the visit.

Now reflecting on this, I think such focus on the process (as opposed to focus on the goal), exact imperative order, not being able to alter the plan even if the change is meaningless in relation to the goal, is a sign of autism. But I don't believe most people think like that.

[harperlee]

I dont know a lot about the brain but I do know that people that research modeling brains have used models in which there are two types of things to think: declarative things AND procedural things. See SOAR and ACT-R.

The caveat here is to which extent computers have tinted their models of a brain, but they are professional cognitive researchers so I’d give them the benefit of the doubt :)

[yxhuvud]

While I think of things in a defined order, I also think in sets. If I grab a bunch of peanuts, I don't visualize grabbing every single peanut one by one, I visualize getting a bunch at the same time.

[vasco]

If you grab a bunch of peanuts you're probably thinking in "hand fulls", but the fact that the world and actions we take are fractal in the way we can analyze them doesn't prove one or the other.

[diatone]

> I find it impossible to believe that some prefer the imperative loop/conditional nesting approach.

Yeah, there’s your problem. This is in fact possible!

[jamil7]

I've haven't written JS in a long time – are engines like V8 smart enough to roll the filter and map into a single loop? Otherwise wouldn't a reduce be more efficient there?

[nevon]

It's not a matter of being smart enough. Since JavaScript is interpreted, the optimization happens at runtime. If the code is executed once and the number of items in the array is small, then it will take more time for the compiler to optimize the code than to naively execute it. Most code falls into this category.

As for whether or not it's possible at all to combine a map and filter into a single loop I guess depends on whether the first operation can have side effects that affect the second operation or the collection that is being iterated over. I don't know the answer, but I would be surprised if there wasn't some hard to detect corner case that prohibits this kind of optimization.

[happytoexplain]

Are you saying you find it hard to believe that some prefer the first "Before" example over the first "Bad refactor" example?