The whole point of composable things like chains is that it's trivial to split them out into intermediate variables if you like. Or into other functions -- which JS's syntax makes slightly more annoying, but you can still depend on the semantics not changing from being moved around.
So if you like intermediate variables, great. I like them too. I also like having the option of chaining where it's necessary or just more expressive. Writing composable APIs means everyone wins.
> 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();
here the problem isn't that you've done method chaining, it's that you've named your functions with terse names that you're going to forget what they do later on e.g. a generic "normalise" vs a "toLowerCase()" or whatever.
As apples-to-apples unchained equivalent isn't really any better
One benefit of the more verbose lower example is, that when it fails somewhere you get a clear line where it failed so can focus already deeper. In chain, unless I am mistaken here (maybe mixing java and javascript so sorry if I am off), its just a general error somewhere in that chain.
Nothing earth-shattering, but who never had to debug something someone saw in production once and never again, then any additional useful info is weighted in gold.
Generally I agree with the sentiment, for one major reason: debugability/dev loops.
Inevitably you're going to end up having to debug that each of those steps is correct, for that you'll find it a lot easier to break it out.. and the next person who has to do it will as well.
I do think the example is somewhat loaded though, rename "result" to "top5ActiveUserNames" would do a lot there.
// This type of usage creates intermediates
array.map().filter()
// But these would not?
array.values().map().filter().toArray()
array.values().reduce()
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
> 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.
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.
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`.
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 guess I'm struggling because I also do like the IDEA of the unix commands being text that is piped around through commands so I do enjoy the concept of the purity of that mechanism.
This is the difference between a command (which is discarded after it's executed), and production code (which you probably want to keep around for a little bit).
But I'm in the same boat. I love the expressiveness of chaining a whole thing into a single call, but I have to break it apart for my own sanity.
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.
Mostly though, it's a combination of a thousand little things. There's no perfect bullet point list for 'this is AI', and if there was, AI would be able to hide it.
What humans are good at is seeing the uncanny valley in both images and prose. It's an old test [0] and we haven't managed to formalise it (or, as above, would even want to), but it's reliable for people with sufficient literacy.
Yeah, nowadays I'm finding more and more of such things and not wanting to read the article further. Sometimes I feel we ignore some good pieces because of LLMification!
When I write, I now use LLMs as an alternative to Grammarly and explicitly instruct it to not to rewrite. Sometimes the choice of words are very intentional and LLMs dont "feel"/understand the emotional reason behind that.
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.
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())
Sure, it's great today but but I want to debug it I need to add `{}` in and/or if I need to add a second operations I need to add the curly braces as well. That's I prefer explicit:
.map((var) => {
return var.toUpperCase();
})
Since it's much easier to drop in a debug line or similar without re-writing surrounding code. It also makes the git diff nicer in the future when you decided to do another operation within the `.map()` call.
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".
Don't forget your humble ifs. Add the {} even if it's one line and the language makes the block optional. You'll thank yourself in 1 year when you come back to that piece of code.
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:
This way, there is usually no good place to inspect the values and it is hard to reason about what even is the return type/value. Yes, the type system can take it, but good luck figuring out what is Map<Map<String,String>,List<String>>. Do this instead even though it looks "less clean"/uses a supposedly useless variable:
In summary: please, for the love of all that is holy, resist the urge to write function chains, always store meaningful intermediary values in named variables with "why" comments in relevant places and do so especially with return values.
1. The pipeline is simple to split or cut entirely, though. No reason to grow it into a monstrosity, but many reasons to not do it. This problem sounds similar to growing a function too much.
2. I agree in general when talking about more complex operations. Simple transformation and filtering rarely needs intermediate variables for readability or debugging. And the naming of result variable already describes the final collection.
3. Never had to deal with this kind of code but I haven't used Kotlin.
The whole point of composable things like chains is that it's trivial to split them out into intermediate variables if you like. Or into other functions -- which JS's syntax makes slightly more annoying, but you can still depend on the semantics not changing from being moved around.
So if you like intermediate variables, great. I like them too. I also like having the option of chaining where it's necessary or just more expressive. Writing composable APIs means everyone wins.
Folks need to learn how to debug chains. The juice of writing with intermediate variables is not worth the squeeze.
I prefer chaining. Less code usually means more readability. I don't want to save intermediate variable if I don't need it.
const filteredUsers = users.filter();
Why create a variable if we use it on a single place anyway. Feels redundant like prefixing "I" in interface names.
> 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:
here the problem isn't that you've done method chaining, it's that you've named your functions with terse names that you're going to forget what they do later on e.g. a generic "normalise" vs a "toLowerCase()" or whatever.As apples-to-apples unchained equivalent isn't really any better
Is not more readable or understandableIt's easier (at least for me), in a debugger, to hover over the intermediate variables in the bottom version and see what the result is.
One benefit of the more verbose lower example is, that when it fails somewhere you get a clear line where it failed so can focus already deeper. In chain, unless I am mistaken here (maybe mixing java and javascript so sorry if I am off), its just a general error somewhere in that chain.
Nothing earth-shattering, but who never had to debug something someone saw in production once and never again, then any additional useful info is weighted in gold.
Generally I agree with the sentiment, for one major reason: debugability/dev loops.
Inevitably you're going to end up having to debug that each of those steps is correct, for that you'll find it a lot easier to break it out.. and the next person who has to do it will as well.
I do think the example is somewhat loaded though, rename "result" to "top5ActiveUserNames" would do a lot there.
The point of chaining is generally to avoid making intermediate objects.
the intermediate objects are still created, they just aren't given names/saved to a specific memory location somewhere
do you mean like streaming APIs where intermediate data structures aren't created? Is that what javascript does w/map() etc?
> the intermediate objects are still created
Yeah; this is what the new iterator methods were intended to solve
https://x.com/MozDevNet/status/2029527411424219254
Basically?
unfortunately iterators have their own set of overheads and it's not clear that these new methods are any faster for most use cases.
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.
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
> 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.
There was a pipeline operator proposal for javascript using `|>`. Whatever happened to that?
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.
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`.
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 guess I'm struggling because I also do like the IDEA of the unix commands being text that is piped around through commands so I do enjoy the concept of the purity of that mechanism.
This is the difference between a command (which is discarded after it's executed), and production code (which you probably want to keep around for a little bit).
But I'm in the same boat. I love the expressiveness of chaining a whole thing into a single call, but I have to break it apart for my own sanity.
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
Which part in OP article indicated AI? Probably is, but hard to tell exactly.
Staccato prose, subtitles like a sales pitch.
Mostly though, it's a combination of a thousand little things. There's no perfect bullet point list for 'this is AI', and if there was, AI would be able to hide it.
What humans are good at is seeing the uncanny valley in both images and prose. It's an old test [0] and we haven't managed to formalise it (or, as above, would even want to), but it's reliable for people with sufficient literacy.
[0] https://en.wikipedia.org/wiki/I_know_it_when_I_see_it
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
Yeah, nowadays I'm finding more and more of such things and not wanting to read the article further. Sometimes I feel we ignore some good pieces because of LLMification!
When I write, I now use LLMs as an alternative to Grammarly and explicitly instruct it to not to rewrite. Sometimes the choice of words are very intentional and LLMs dont "feel"/understand the emotional reason behind that.
> Sometimes I feel we ignore some good pieces because of LLMification!
As a heuristic for attention, "does the claimed author care about, understand, or even know what they're writing about?" is not a bad start.
Yeah, and the content is not really thought provoking by any means.
I was surprised to see such obviously low quality slop here on HN.
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.
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:
Sure, it's great today but but I want to debug it I need to add `{}` in and/or if I need to add a second operations I need to add the curly braces as well. That's I prefer explicit: Since it's much easier to drop in a debug line or similar without re-writing surrounding code. It also makes the git diff nicer in the future when you decided to do another operation within the `.map()` call.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".
Don't forget your humble ifs. Add the {} even if it's one line and the language makes the block optional. You'll thank yourself in 1 year when you come back to that piece of code.
Name return variables bro.
This is a solution that people fixed 25 years ago with detailedReturnObjectNames.
Can you elaborate on that? I'm not following. What makes return variables special?
I'd expect that much of the time, the return variable is closely linked to the name of the function. So closely linked that it risks being redundant.
Not JS but I like having explicit return var assignments because it's easier to break on and inspect. I don't know why tools don't make this easier.
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:
This way, there is usually no good place to inspect the values and it is hard to reason about what even is the return type/value. Yes, the type system can take it, but good luck figuring out what is Map<Map<String,String>,List<String>>. Do this instead even though it looks "less clean"/uses a supposedly useless variable: In summary: please, for the love of all that is holy, resist the urge to write function chains, always store meaningful intermediary values in named variables with "why" comments in relevant places and do so especially with return values.1. The pipeline is simple to split or cut entirely, though. No reason to grow it into a monstrosity, but many reasons to not do it. This problem sounds similar to growing a function too much.
2. I agree in general when talking about more complex operations. Simple transformation and filtering rarely needs intermediate variables for readability or debugging. And the naming of result variable already describes the final collection.
3. Never had to deal with this kind of code but I haven't used Kotlin.
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