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

11–20 of 78 posts

Re: ES7 Proposal: The Pipeline Operator

#13

Post by edgyswingset »

wnfewnlkew wrote: post #9

Please no. Javascript's beauty lies in its versatile simplicity. Can we just leave these sorts of things to systems programming languages like C++? I came to javascript because of its lack of cruft, but if libraries start adopting this then I'll be forced to put it in my code as well. If that happens then I'll probably leave for nim or clojure, though that's not preferable.

Can't speak for nim, but Clojure has a near-exact feature which is used all over the place, the thread-first and thread-last macros.

Example:

    (defn do-stuff [params-map]
       (->
          (build-object params-map)
          (do-thing-with-object)
          (extract-thing)
          (format-thing)))
I'm not sure why you'd choose Clojure to get away from things like |>.

Re: ES7 Proposal: The Pipeline Operator

#14

Post by efdee »

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))).

Re: ES7 Proposal: The Pipeline Operator

#15

Post by wycats »

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 like a function call, to me) and the proposed pipeline operator, which doesn't have an immediate meaning to my eyes.

Re: ES7 Proposal: The Pipeline Operator

#16

Post by pskocik »

thescriptkiddie wrote: post #11
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?

(because (there (is (such (a (thing (as (too (many parens)))))))))

I bet Lispers would beg to differ. :D

Nested function do one thing on a chunk of data, then another, then another.

*nix pipelines apply all the filters at once and control the scheduling and lifetime of the filters.

Those are quite different concepts, and I think it's confusing to conflate the two. Plus every decent editor can handle paired parentheses.

Re: ES7 Proposal: The Pipeline Operator

#17

Post by wycats »

renekooi wrote: post #5

I like this a lot. It's similar to the proposed function bind syntax[1], but a bit more friendly to not-`this`-related use: function bindMap(fn) { return this.map(fn) } [ 1, 2, 3 ]::bindMap(n => n + 1) // standalone use: bindMap.call(arr, fn) function pipelineMap(fn) { return arr => arr.map(fn) } [ 1, 2, 3 ] |> pipelineMap(n => n + 1) // standalone use: pipelineMap(fn)(arr) (Also nice that it works in a very similar…

I agree that a "functional" operator that uses `this` as the first argument is weird.

The main goal of all of these proposals is "left to right" composition when working with functions, and functions take parameters.

Re: ES7 Proposal: The Pipeline Operator

#18

Post by abrezas »

wnfewnlkew wrote: post #9

Please no. Javascript's beauty lies in its versatile simplicity. Can we just leave these sorts of things to systems programming languages like C++? I came to javascript because of its lack of cruft, but if libraries start adopting this then I'll be forced to put it in my code as well. If that happens then I'll probably leave for nim or clojure, though that's not preferable.

C++ has a piping operator?

Re: ES7 Proposal: The Pipeline Operator

#19

Post by efdee »

thescriptkiddie wrote: post #11
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?

(because (there (is (such (a (thing (as (too (many parens)))))))))

I think you meant many_parens(too(as(thing(a(such(is(there(because)))))))).

Re: ES7 Proposal: The Pipeline Operator

#20

Post by wycats »

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 said, the main counterargument to this proposal is that it's already possible to get "left to right" composition in userland without this operator, as underscore shows.

The main counterargument to "do it like underscore" is that underscore still ends up being an object whose methods are added to a prototype, not imported.

The benefit of the "pipeline" or "bind" approach is that you get left-to-right composition while still importing the names you're using.

Post reply on HN