Live data from Hacker News

ES7 Proposal: The Pipeline Operator

github.com

1–10 of 78 posts

Re: ES7 Proposal: The Pipeline Operator

#4
Can we just put more focus on sweet.js so we can do this kind of in a library with standard build tooling? http://sweetjs.org/

There's a lot more operators than |> that you would want. Clojure commonly uses ->, ->>, as->, etc. It should be done in a library if it is done at all.

Also, going full-on functional in javascript is going to end badly, javascript simply wasn't designed for it. If you go down this path in real projects, sooner or later you inevitably end up at clojurescript or whatever other real FP language suits.

Re: ES7 Proposal: The Pipeline Operator

#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 way to decorators, although they won't be interchangeable in most cases, with decorators working on class constructors and property descriptors, instead of just any value.)

Presumably, at most one of these proposals will make it in :)

[1]: https://github.com/zenparsing/es-function-bind

Re: ES7 Proposal: The Pipeline Operator

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

Post reply on HN