This actually surprises me!

One habit introduced to my current team by a former co-worker involves having even more intermediate keys than that:

    const sensitiveEnv = [...];
    const envKeys = Object.keys(envars)
    const safeKeys = envKeys.filter(envar => !sensitiveEnv.includes(envar));
    const safeEnv = safeKeys.map(envar => `${envar}=${envars[envar]}`).join(' ');
    const styled = chalk.dim(`$ ${envStr}`, 'node', args.join(' '));
    console.log(styled);

In the beginning I wasn't a fan of it, as I do a lot of Haskell (and have point-free idioms on the tip of my fingers), and it's obviously unnecessary, as you said yourself. But with time I learned to appreciate this kind of function for its simplicity and consistence.

Now, of course, with a pipe operator (or other similar constructions) you can get the consistency without the intermediate names.

I just find it easier "thing" that happens is one self-contained statement, if that makes sense. Makes it easier to see what does what. I don't think one way is "better" or "worse" btw; all I can say to my brain, I find it harder to follow. This is what can make programming in a team hard.

I'm also one of those people that likes single-letter variables. I know some people hate it with a passion, but I find it very convenient. Just makes it easier to read as there's less to read.

I'm not smart enough to do Haskell, so I can't say much about that.

Oh, a kindred spirit. I also love single-letter variables where they make sense. I have a math-heavy background, so they're totally cool for me, BUT I get why most programmers would hate 'em. I also like them since they were the "norm" in old C# LINQ code where I learned functional programming. If I were alone in the programming world I would have written the example above with single letter vars.

I agree with your remarks, there's no right or wrong, it's like tabs and spaces.

Btw I'm also not smart enough for Haskell, but it hasn't stopped me so far ;)

Extracting `envStr` is definitely the highest impact change for me. I dislike temporary variables too when they don't represent a meaningful intermediary result, but in this case I see them as a lesser evil. I agree that `styled` is more about personal preference.

This is why I'm happy to see the pipe syntax proposal, it avoids unnecessary temporary variables while simultaneously aiding readability.

> This is why I'm happy to see the pipe syntax proposal, it avoids unnecessary temporary variables while simultaneously aiding readability.

The thing is I don't think it's all that much more readable. No matter which syntax you use, there's still the same number of "things" going on in a single statement.

I do have to admit I never worked with a language that uses |>, so I'm sure that with increased familiarly with this it would become "more readable" to me, but one has to wonder: just how many calling syntaxes does one language have to support? More syntax also means more potential for confusion, more ways to abuse the language/feature, more "individual programming styles", more argueing over "should we write it like this or that?", more overhead in deciding how to write something, harder to implement the language and write tooling for it, and things like that.

There is always a trade-off involved. The question to ask isn't "would this be helpful in some scenarios?" because the answer to that is always "yes" for practically any language feature. The question to ask "is this useful enough to warrant the downsides of extra syntax?" I'm not so sure that it is, as it doesn't really allow me to do anything new that I couldn't do before as far as I can see. It just allows me to make things that are already too complex a bit more readable (arguably).

> I do have to admit I never worked with a language that uses |>

Have you never worked with Bash? It's basically the same thing

Indeed it is, but it's kind of a different context than a "real" programming language. What works for one doesn't necessarily work well for the other.

Truly, one of the main reasons I might stop increasing the complexity of a bash one-liner and move it to a full shell script, or bail for Python, is specifically so I can turn those chains of pipes into imperative steps with temp vars so that they're actually legible and easy to reason about. I can't imagine why I'd want to go the other direction.

Those variables help to document intent by naming the intermediate values. They also make step-debugging more convenient. In languages with type declarations, they also serve to inform about the type of the intermediate value, which otherwise is invisible in a pipe sequence.

IDEs for languages with pipes allow break points on pipelines and can show inferred type annotations mid pipeline. Given the popularity of JS, this tooling will appear rapidly after pipe standardisation.

In this case I like that it gives you a hint about what's going on. "chalk.dim" sure doesn't.