3 ms·

> Temporary variables are certainly really tedious in many situations: const string = "hello" const capitalizedString = capitalize(string) const paddedStr

> 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
  For a direct comparison: wrapTag('p', capitalize(parseTemplate(sanitize('hello, %s'), 'Sam'))) 'hello, %s' |> sanitize |> parseTemplate(%, 'Sam') |> capitalize |> wrapTag('p', %) And with some little adjustments with currying even those % placeholders can go away.
  - inbx0 5y ago
    Note that, in the current form of the JS proposal, you also need to use the placeholder in unary functions. I.e. sanitize(%) and capitalize(%)
benatkin 5y ago
I think we got used to nested function calls, but they often aren't as good as the pipe operator. It might seem like pipe is for unix geeks, but it's good enough for designers too. See Django's template system. https://docs.djangoproject.com/en/3.2/misc/design-philosophies/#don-t-invent-a-programming-language https://docs.djangoproject.com/en/3.2/misc/design-philosophi... https://docs.djangoproject.com/en/3.2/ref/templates/language/#filters https://docs.djangoproject.com/en/3.2/ref/templates/language...

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
For a direct comparison: wrapTag('p', capitalize(parseTemplate(sanitize('hello, %s'), 'Sam'))) 'hello, %s' |> sanitize |> parseTemplate(%, 'Sam') |> capitalize |> wrapTag('p', %) And with some little adjustments with currying even those % placeholders can go away.
- inbx0 5y ago
  Note that, in the current form of the JS proposal, you also need to use the placeholder in unary functions. I.e. sanitize(%) and capitalize(%)

benatkin 5y ago

I think we got used to nested function calls, but they often aren't as good as the pipe operator. It might seem like pipe is for unix geeks, but it's good enough for designers too. See Django's template system. https://docs.djangoproject.com/en/3.2/misc/design-philosophies/#don-t-invent-a-programming-language https://docs.djangoproject.com/en/3.2/misc/design-philosophi... https://docs.djangoproject.com/en/3.2/ref/templates/language/#filters https://docs.djangoproject.com/en/3.2/ref/templates/language...