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

21–30 of 78 posts

Re: ES7 Proposal: The Pipeline Operator

#21

Post by radicalbyte »

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

Re: ES7 Proposal: The Pipeline Operator

#22

Post by toni »

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.

    attrs
        |> bounded('age', 1, 100)
        |> format('name', /^[a-z]$/i)
        |> Person.insertIntoDatabase
This reminds me of those "Perl Poetry" code snippets from 2001.

Re: ES7 Proposal: The Pipeline Operator

#23

Post by edgyswingset »

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 that's a terrible code smell! The proper way to handle that case in a language which doesn't support pipelining would be to break each call into a variable and use those those variables. But even that can be tedious, hence the pipelining operators which have cropped up in some languages.

Re: ES7 Proposal: The Pipeline Operator

#24

Post by danneu »

pskocik wrote: post #16
thescriptkiddie wrote: post #11

Earlier quoted context omitted.

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

    > I bet Lispers would beg to differ. :D
Would they?

I wrote and read threading macros all the time when I used Clojure. Turns out it cleans up code.

Re: ES7 Proposal: The Pipeline Operator

#25

Post by vruiz »

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?

Re: ES7 Proposal: The Pipeline Operator

#26

Post by wycats »

dustingetz wrote: post #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 re…

Can you elaborate on the rough seams between JavaScript and "full on functional"?

I'm not a believer in the FP vs. OO religion, and have historically been skeptical of the bind operator. That said, I think that both composition via objects and composition via functions have their place.

The pipeline operator attempts to make composition via functions more readable (left-to-right instead of right-to-left) and unless you think composition via functions is a bad idea in JS in all cases, I'm not sure what "full-on functional" has to do with it.

Re: ES7 Proposal: The Pipeline Operator

#27

Post by tallerholler »

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!

Re: ES7 Proposal: The Pipeline Operator

#29

Post by mbreese »

toni wrote: post #22
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.

attrs |> bounded('age', 1, 100) |> format('name', /^[a-z]$/i) |> Person.insertIntoDatabase This reminds me of those "Perl Poetry" code snippets from 2001.

Yes, and we all know how that turned out with Perl. I don't think Perl is necessarily a good model for readable code.

This seems to me to be a case of "just because we can, doesn't mean we should."

Re: ES7 Proposal: The Pipeline Operator

#30

Post by wnfewnlkew »

edgyswingset wrote: post #13
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 |>.

Clojure is a functional language, so it meshes well with the rest of the syntax, but in javascript's case it's just syntax bloat. It's going to be really jarring in the middle of regular imperative code, and it's not going to be too far removed from

  cout
Post reply on HN