Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ES7 Proposal: The Pipeline Operator

github.com

Post reply on HN
Print view View original

31–40 of 78 posts

Re: ES7 Proposal: The Pipeline Operator

#31

Post by andrewpe »

radicalbyte wrote: post #21
pskocik wrote: post #8

What's so painful about just doing `exclaim(capitalize(doubleSay("hello")));`? Why introduce needless syntactic sugar that'll only confuse people about how UNIX pipes work?

To understand the nesting you have to evaluate the functions in the opposite order than you're reading them: exclaim capitalize doubleSay Sure, some of us has spent 20 years doing this so it's easy, but you can't deny that this is far nicer to read: doubleSay capitalize exclaim I'm a big fan of Fluent Interfaces, so I use this construct fairly often: "hello".doubleSay().capitalize().exclaim()

This should be how it's done, simplistic, nothing new to learn, easy to read.

Re: ES7 Proposal: The Pipeline Operator

#32

Post by wycats »

vruiz wrote: post #25
wycats wrote: post #15

If we're going to do this operator, I would prefer a regular arrow: import { sortBy, filter, map } from 'array-like'; let names = document.querySelectorAll('.entry') -> sortBy('title') -> filter(entry => entry.getAttribute('data-url') in whitelist) -> map(entry => entry.getAttribute('name'); I personally find this more readable than either the bind proposal (which looks too much like a property access, and not enough…

> I personally find this more readable than ... the proposed pipeline operator, which doesn't have an immediate meaning to my eyes. Really? have you never seen unix pipes?

I would find pipes to be very readable (but the single pipe operator is taken). The triangle isn't immediately an analogy to "unix pipes".

Re: ES7 Proposal: The Pipeline Operator

#33

Post by wycats »

tallerholler wrote: post #27
wycats wrote: post #15

If we're going to do this operator, I would prefer a regular arrow: import { sortBy, filter, map } from 'array-like'; let names = document.querySelectorAll('.entry') -> sortBy('title') -> filter(entry => entry.getAttribute('data-url') in whitelist) -> map(entry => entry.getAttribute('name'); I personally find this more readable than either the bind proposal (which looks too much like a property access, and not enough…

that won't play nice with coffeescript!

CoffeeScript should have thought of that ;)

Re: ES7 Proposal: The Pipeline Operator

#34

Post by danbruc »

wycats wrote: post #15

If we're going to do this operator, I would prefer a regular arrow: import { sortBy, filter, map } from 'array-like'; let names = document.querySelectorAll('.entry') -> sortBy('title') -> filter(entry => entry.getAttribute('data-url') in whitelist) -> map(entry => entry.getAttribute('name'); I personally find this more readable than either the bind proposal (which looks too much like a property access, and not enough…

Why the arrow? That works just fine with a dot.

  let names = document.querySelectorAll('.entry')
                      .sortBy('title')
                      .filter(entry => entry.getAttribute('data-url') in whitelist)
                      .map(entry => entry.getAttribute('name');

Re: ES7 Proposal: The Pipeline Operator

#35

Post by coldtea »

donatj wrote: post #7

I feel like that just confuses things for no good reason. It's no fewer characters than parens but provides as I see it less clarity.

How it's "less clarity"?

What happens is much easier to read if you know what the operator means.

The only way the old way has more clarity is in the "we are already familiar with it" way. In any other way, this method trumps it.

Re: ES7 Proposal: The Pipeline Operator

#37

Post by wycats »

danbruc wrote: post #34
wycats wrote: post #15

If we're going to do this operator, I would prefer a regular arrow: import { sortBy, filter, map } from 'array-like'; let names = document.querySelectorAll('.entry') -> sortBy('title') -> filter(entry => entry.getAttribute('data-url') in whitelist) -> map(entry => entry.getAttribute('name'); I personally find this more readable than either the bind proposal (which looks too much like a property access, and not enough…

Why the arrow? That works just fine with a dot. let names = document.querySelectorAll('.entry') .sortBy('title') .filter(entry => entry.getAttribute('data-url') in whitelist) .map(entry => entry.getAttribute('name');

Only if those methods are added to NodeList, which they haven't been.

(and of course 'sortBy' is nonstandard)

Re: ES7 Proposal: The Pipeline Operator

#38

Post by mbreese »

efdee wrote: post #14
donatj wrote: post #7

I feel like that just confuses things for no good reason. It's no fewer characters than parens but provides as I see it less clarity.

I think the clarity comes from the reading order. str |> method1 |> method2 |> method3 vs method3(method2(method1(str))).

That's readable in the simple case, (arg1 is a string, returns a string). What about the more complex cases? Different method signatures, required extra arguments, returning objects or arrays? This will either a) break in those cases, or b) not be applicable. In which case, it's extra complexity for very little gain.

Seriously, this just seems like syntax sugar that just isn't needed. I get that you might not think it's elegant, but is anyone seriously troubled or confused by method3(method2(method1(str)))? How would the pipeline syntax help here?

Re: ES7 Proposal: The Pipeline Operator

#39

Post by pygy_ »

wycats wrote: post #15

If we're going to do this operator, I would prefer a regular arrow: import { sortBy, filter, map } from 'array-like'; let names = document.querySelectorAll('.entry') -> sortBy('title') -> filter(entry => entry.getAttribute('data-url') in whitelist) -> map(entry => entry.getAttribute('name'); I personally find this more readable than either the bind proposal (which looks too much like a property access, and not enough…

> I would prefer a regular arrow

And I want it painted green ;-)

> ... which doesn't have an immediate meaning to my eyes.

It's a matter of background. F#, Julia and Livescript have identical operators, likely among others.

https://msdn.microsoft.com/en-us/library/dd233229.aspx#Ancho...

http://docs.julialang.org/en/release-0.4/stdlib/base/?highli...

http://livescript.net/#piping

Re: ES7 Proposal: The Pipeline Operator

#40

Post by abrezas »

pskocik wrote: post #8

What's so painful about just doing `exclaim(capitalize(doubleSay("hello")));`? Why introduce needless syntactic sugar that'll only confuse people about how UNIX pipes work?

it's very common in javascript to have chained methods, to be able to do things like

    _(array)
    .compact()
    .map(function(x) {
       return x * x;
    })
    .filter(function(x) {
        return x > 100;
    }).value()
(example from underscore/lodash)

The problem with this is to be able to add a custom function to this pipeline, you have to extend the prototype of the library with your own functions, or re-implement it.

Extending the prototype is considered bad practice for a lot of reasons, for example due to polluting code in other modules or upstream changes breaking your code.

If instead of chaining methods we chained functions we are left with this awkward syntax:

    custom(filter(map(compact(array), function(x) {
         return x * x;
    }), function(x) {
         return x > 100;
    }));
it's much cleaner to write it like this:

    compact(arr)
    |> map(function(x) {
        return x * x;
    })
    |> filter(function(x) {
        return x > 100;
    })
    |> custom
The linked page has a nice example and explanation about this concerning promises https://github.com/mindeavor/es-pipeline-operator#sample-usa...
Post reply on HN