> Chaining nudges you toward “process everything,” even when that’s not what you meant to do.

It feels pretty clear that the chains in that example (filter/map) are meant for operating on collections. And that if you're searching for a single item then chaining isn't the way to go?

Personally, if I knew I wanted only a single item I wouldn't feel more "nudged" towards appending a [0] on the end of a long chain rather than doing a refactor to the find().

As to:

    data
      .transform()
      .normalize()
      .validate()
      .save();

As apples-to-apples unchained equivalent isn't really any better

    const transformedData = transform(data);
    const normalisedData = normalise(transformedData);
    const validatedData = validate(normlisedData);
    save(validatedData);

I can only say: learn how to use reduce and you never loop twice through a list of items or objects.

To me reduce is very easy to reason about and makes it super easy to properly filter, combine, extract values without ending with filters on filters on maps and maps

Note that for little while now lazy iterators have been available:

- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

- Array.prototype.values https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

This addresses a few criticisms here, and the main criticisms I had.

The point of chaining is generally to avoid making intermediate objects.

> Yeah, it’s more lines. But each step is just sitting there. No decoding required.

I actually think the first code block is easier to read. It's a familiar (to me) and simple pattern that is quick to read. I don't get how it would require more "decoding" than the second example which is more disjointed and needs more "parsing" for such a trivial case. Maybe it's about what you're used to?

I agree there are downsides to chaining. With more complex operations it can complicate debugging, and readability can suffer, so chaining is not a good fit there.

What a high-level boring list of examples. Why not have one complex example that clearly shows your "take". (Quotations, because these "I stopped doing X, and now doing Y" posts are stupid. They're also easier to write now with LLM's.)

I'm sure there's a case to be made for either, this post just doesn't do it.

Kinda feels like a code smell having to optimize your code this way. Normally, data state would be abstracted away in a data store (e.g., Redux), and then specific sub-selections are pulled out using pure functions, e.g., `getActiveUserNames`, `getActiveUsers`, `getTop5ActiveUsers`.

Not trying to sound snarky, but this is just part of transitioning from a junior/mid to a more senior developer: realizing that code readability matters more than terse-ness.

When I see a magnificent series of functions, I feel a strange, indescribable feeling. However, it's difficult to feel the desire to actively engage with them.

a non-AI similar take:

https://grugbrain.dev/#grug-on-expression-complexity

I agree that debugging these pipelines are a nightmare sometimes. It's something that frustrates me sometimes because even though in OOP it won't be terse the action would be clearer. OOP can at times also introduce less cognitive load as well. I wonder if the issue is the mixing of paradigms. Although I don't think everything should follow purity boundaries: functional must always be functional and OOP languages should just be OOP but perhaps the mixture of doing functional programming in a OOP paradigm introduces unintended quirks that are cognitively taxing when bugs occur. (I've written 10 drafts and I'm not sure what I want to say so I'm going to just land it here and see what happens)

I read two paragraphs of this and was already sure this article is AI generated. Read more, and "This isn’t just about..." there we go

This is what tends to happen to code when your focus starts to shift away from how expediently you can write it and closer to how readable/maintainable it really is.

I whole-heartedly sympathise with the problem author is trying to describe. He does not introduce it very well, but if you read through the whole thing, you should be able to get the gist of it.

For me, the problems with chaining from the point of mostly maintaining existing software are:

1. Harder to impossible to reason about.

As the author alludes to, 1-2 chains are fine, but it starts getting impossible when you get into a territory where you have a longer chain which has a deeper call tree. This happens over time where you start with a smaller chain and people start lengthening it, adding helper functions which grow into large call trees, etc. This makes it so that you have sort of a blackbox pipeline that is, at the very least, annoying and time-consuming to inspect.

2. Harder to debug

Author tries to mention this but he seems to fail/stop short of pointing out what is wrong with the example he provides. For me, I work with Kotlin. In Kotlin, you cannot put a breakpoint in the middle of the chain! As far as I know, you can only put a breakpoint inside of the chained function calls and do step-into/step-over and such, but you cannot put a breakpoint in-between chain function calls. This means that debugger is basically useless if your codebase looks as described in my previous point. The solution is to write a bit more code at the start, naming each variable. This makes it much easier to debug the code/logic (because you can put a breakpoint on the specific variable/step you are interested in) and, more importantly, to understand, because you explain the steps with the variable names and optionally also with comments.

3. Related problem - return chaining

Another issue I have in codebases I inherited is what I would describe as return chaining. It is what happens when you have code which returns a function call and the called function does the same thing and so on and so on. Minimalistic example:

  foo() {
     return x
        .map()
  }


  baz() {
     return foo()
        .map()
  }

  fbaz() {
      return baz()
        .map()
  }

  foo() {
     const helpfulName = x.map()
     
     return helpfulName
  }


  baz() {
     const anotherHelpfulName = foo.map()
     
     return anotherHelpfulName
  }

  fbaz() {
      const superHelpfulName = baz.map()
      
      return superHelpfulName
  }

Agreed, while chaining can look very pretty, it's a pain to re-parse and a pain to modify.

It's the same reason I don't like this style of function:

    .map(var => var.toUpperCase())

    .map((var) => {
        return var.toUpperCase();
    })

I've asked many people to re-write perfectly functioning code for this same reason. "Yes, I know you can do it all in 1 line but let's create variables for each step so the code is self-documenting".

Name return variables bro.

This is a solution that people fixed 25 years ago with detailedReturnObjectNames.

Uh huh.

I thought this would have some decent insight as to memory usage or something.

Nope. It's just clinically stupid.

His first example is pretty much the same either way. I would say the "better" way is a little more involved to read. But it's nothing either way.

His second example makes unnecessary chains. He filters, then maps. When he could just use find and get the name like he does in the "steps" version.

Maybe we need fewerthingssmitty