4 ms·

> Temporary variables are often tedious I could not disagree more. Temporary variables as you perform transformations are great because they force you to verba

> Temporary variables are often tedious I could not disagree more. Temporary variables as you perform transformations are great because they force you to verbalize what it is that you're actually doing. Descriptive naming is hard, but in contexts like this it's an actual godsend for anyone who isn't the person writing the initial code. I think the use cases are not convincing, I would much rather this be a Babel plugin than a core language feature.

handrous 5y ago
I hate that following assignment in the examples requires knowing precedence for the operator vs. the assignment operator. The = sign visually "points at" the first function call, but it's operating on the return value of the last function call, to which it has no spatial or visual connection.
ravenstine 5y ago
> Temporary variables as you perform transformations are great because they force you to verbalize what it is that you're actually doing. This is incredibly important because so many developers don't use ways to describe the intent of what they are writing at all. It's bad enough many believe the swill that "the code is the documentation", but to then add new ways to make code less self descriptive is... worrying.
Zababa 5y ago
Sometimes things just don't have a good name. Focusing on a few well-named temporary variables that corresponds to logical steps usually yield clearer code than trying to name everything.
- ravenstine 5y ago
  There's truth to that, but I also find that if I can't name something chances are that what I'm writing isn't as sensibly structured as it could be. I would rather solve these problems by creating new scopes than to effectively strip away names in favor of a chain of generic function calls.
  - Zababa 5y ago
    That's true, in these cases I usually write a function that's basically a composition of functions. The power of the pipeline operator is ad-hoc function composition. This is useful if you have lots of very generic functions, and don't want to name every single composition. There is already the f(g(h(x))) syntax, of course, but it's not the most readable. I do agree in general that this operator isn't really needed. Probably not worse than Python's := or structural pattern matching, it's one of those things where either you base the language on it, or you don't and adding it is not really necessary.
ledauphin 5y ago
this is the age-old "do it the way I'm used to and it'll be better" argument. Descriptive variable naming _is_ hard, and unlike function and parameter naming, it is avoidable in many cases! By naming a temporary variable, you ask other developers to consider the possibility that you might be doing multiple things with it - not doing so allows a simplified read with confidence that this is a pure function pipeline with no unrelated side effects. Naming is a great and hard and valuable thing - temporary variables are only good inasmuch as your readers habitually expect them - and habits can be changed, thank goodness!
sodapopcan 5y ago
In functional languages with pipes, if something is worth naming it would be generally be extracted to a function. "string" |> capitalize(%) function capitalize(str) { // do the thing } Temporary variables are certainly really tedious in many situations: const string = "hello" const capitalizedString = capitalize(string) const paddedString = leftPad(capitalizedString, 5) I'd have a very hard time buying any argument claiming naming those variables adds any kind of clarity to the reader or writer over: "hello" |> capitalize(%) |> leftPad(%, 5) But then, does _JavaScript_ need this? I dunno.
- baud147258 5y ago
  > Temporary variables are certainly really tedious in many situations: const string = "hello" const capitalizedString = capitalize(string) const paddedString = leftPad(capitalizedString, 5) In that situation, one shouldn't use temporary variables (or at least too many of them), but rather just chain the functions const paddedString = leftPad(capitalize("hello"), 5)
  - xcambar 5y ago
    A pipe operator aligns the order of operations with the reading order. As such, it does add to readability.
  - sodapopcan 5y ago
    But what happens when there are more than two or three transformations? wrapTag("p", capitalize(parseTemplate(sanitize("hello, %s"), "Sam")))) This is a contrived example in terms of the actual functions being called, but it's not out of the question to have at least this many transforms (just think of a method chain of more than two or three operations if you are coming from an OO point of view). My main reason for replying to this thread is to counter this idea that pipes are inelegant—this simply isn't true. At the same time, I personally don't care if they make it into JS or not. edited for clarity/grammar
    - crooked-v 5y ago

handrous 5y ago

I hate that following assignment in the examples requires knowing precedence for the operator vs. the assignment operator. The = sign visually "points at" the first function call, but it's operating on the return value of the last function call, to which it has no spatial or visual connection.

ravenstine 5y ago

> Temporary variables as you perform transformations are great because they force you to verbalize what it is that you're actually doing. This is incredibly important because so many developers don't use ways to describe the intent of what they are writing at all. It's bad enough many believe the swill that "the code is the documentation", but to then add new ways to make code less self descriptive is... worrying.

Zababa 5y ago

Sometimes things just don't have a good name. Focusing on a few well-named temporary variables that corresponds to logical steps usually yield clearer code than trying to name everything.

ravenstine 5y ago
There's truth to that, but I also find that if I can't name something chances are that what I'm writing isn't as sensibly structured as it could be. I would rather solve these problems by creating new scopes than to effectively strip away names in favor of a chain of generic function calls.
- Zababa 5y ago
  That's true, in these cases I usually write a function that's basically a composition of functions. The power of the pipeline operator is ad-hoc function composition. This is useful if you have lots of very generic functions, and don't want to name every single composition. There is already the f(g(h(x))) syntax, of course, but it's not the most readable. I do agree in general that this operator isn't really needed. Probably not worse than Python's := or structural pattern matching, it's one of those things where either you base the language on it, or you don't and adding it is not really necessary.

ledauphin 5y ago

this is the age-old "do it the way I'm used to and it'll be better" argument. Descriptive variable naming _is_ hard, and unlike function and parameter naming, it is avoidable in many cases! By naming a temporary variable, you ask other developers to consider the possibility that you might be doing multiple things with it - not doing so allows a simplified read with confidence that this is a pure function pipeline with no unrelated side effects. Naming is a great and hard and valuable thing - temporary variables are only good inasmuch as your readers habitually expect them - and habits can be changed, thank goodness!

sodapopcan 5y ago

In functional languages with pipes, if something is worth naming it would be generally be extracted to a function. "string" |> capitalize(%) function capitalize(str) { // do the thing } Temporary variables are certainly really tedious in many situations: const string = "hello" const capitalizedString = capitalize(string) const paddedString = leftPad(capitalizedString, 5) I'd have a very hard time buying any argument claiming naming those variables adds any kind of clarity to the reader or writer over: "hello" |> capitalize(%) |> leftPad(%, 5) But then, does _JavaScript_ need this? I dunno.

baud147258 5y ago
> Temporary variables are certainly really tedious in many situations: const string = "hello" const capitalizedString = capitalize(string) const paddedString = leftPad(capitalizedString, 5) In that situation, one shouldn't use temporary variables (or at least too many of them), but rather just chain the functions const paddedString = leftPad(capitalize("hello"), 5)
- xcambar 5y ago
  A pipe operator aligns the order of operations with the reading order. As such, it does add to readability.
- sodapopcan 5y ago
  But what happens when there are more than two or three transformations? wrapTag("p", capitalize(parseTemplate(sanitize("hello, %s"), "Sam")))) This is a contrived example in terms of the actual functions being called, but it's not out of the question to have at least this many transforms (just think of a method chain of more than two or three operations if you are coming from an OO point of view). My main reason for replying to this thread is to counter this idea that pipes are inelegant—this simply isn't true. At the same time, I personally don't care if they make it into JS or not. edited for clarity/grammar
  - crooked-v 5y ago