41–50 of 54 posts
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.
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.
There was a pipeline operator proposal for javascript using `|>`. Whatever happened to that?
> Chaining nudges you toward “process everything,” even when that’s not what you meant to do.
const firstActiveUser = users
.filter(user => user.active)
.map(user => user.name)[0];
> When what you actually wanted was:
const user = users.find(user => user.active);
const name = user?.name;
const name = users.find(user => user.active)?.name
Folks need to learn how to debug chains. The juice of writing with intermediate variables is not worth the squeeze.
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…
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 fina…
2. Yes, easy filterings usually don't need to be broken down/named, but it really depends. At the very least, if the culture is to name intermediary values, you might accidentally get useful information from the variable names even if people weren't diligently writing explanatory why comments.
3. This isn't Kotlin related, it is just that if you do not have a language/codebase with branded types (or some type system property I don't know the name of), the type system might only infer the base primitives of the result, ending up with stuff like the type I mentioned.
I love chaining because it reduce the number of occurrences of that problem.
Earlier quoted context omitted.
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 probably won't adopt this as a convention, just because most of the time when I have access to a debugger I'll also have access to the source code and handle it myself. But I'm going to keep it in mind, and perhaps get fed up at some point and decide to adopt the idea. Thanks.
My opion here but: generally not a fan. Explicitness is a virtue. That itself can go overboard too!
In the olden days the chained syntax was also worryingly low performance: ideally you want to iterate only as many times as you have to, doing as much work per pass as you can rather than spreading it out across passes. The example code also creates intermediate arrays, versus working on place: not always possible but over allocating was another "are you trying to make this page look jank" trigger. The chained syntax prevents you from dealing with either, albeit iteration helpers somewhat ameliorate this.
Perl was very fun to write because there are so many predefined variables that would automatically be written to and read from. It allowed for imperative-ish code that still was incredibly tacit. All the data flow was implicit. Fun to write, incredibly hard to visualize.
I do wish we saw IDEs that made data flow analysis more visible. Overlay the source code with the compiler's sea of nodes, show the us the graph of compute that actually constitutes a section. I think we could be augmenting ourselves to do much more with implicit styles, to get the visibility of our code "for free", and at an even more explicit visually clear way than using lots of intermediate variables. Oh to dream.