ES7 Proposal: The Pipeline Operator • Hacker News Board

Re: ES7 Proposal: The Pipeline Operator

#51

Post by toni » Sun, Dec 06, 2015, 9:22 PM UTC

mbreese wrote: post #29

toni wrote: post #22

Earlier quoted context omitted.

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

There are a lot of programmers coming from other functional programming languages to Javascript, bringing a lot of ideas from their own language to "make Javascript better".

On top of that, there are also "transpiler folks": Ruby |> CoffeeScript, C#/F# |> TypeScript, etc...

The classical Javascript programmer might be the last of a dying breed.

Re: ES7 Proposal: The Pipeline Operator

#52

Post by danbruc » Sun, Dec 06, 2015, 9:23 PM UTC

radicalbyte wrote: post #12

That's beautiful, the linear pipeline better matches your intuition about the computation than the nested functions. Can we have this in C# 7? :)

This essentially exists - extension methods.

Re: ES7 Proposal: The Pipeline Operator

#53

Post by simplify » Sun, Dec 06, 2015, 9:25 PM UTC

Animats wrote: post #49

The single-argument case is elegant, and the multiple-argument case is awful. var newScore = add(7, validateScore( double(person.score) )) becomes var newScore = person.score |> double |> score => add(7, score) |> validateScore This is very Forth-like. Operands get pushed on the stack, and operators take from the stack and push results back. In Forth, there's no operator precedence and no parentheses; it's pure rever…

It's not just syntax; it actually opens new ways for API design. See abreza's comment: https://news.ycombinator.com/item?id=10686596

Re: ES7 Proposal: The Pipeline Operator

#54

Post by Sonata » Sun, Dec 06, 2015, 9:35 PM UTC

After having used this operator in Elixir and Elm, I would love to see it in JS. I know it seems like a superficial issue, but I think the left-to-right chaining flow is one of the main things people miss as they move from an OO style to a more functional one.

Re: ES7 Proposal: The Pipeline Operator

#55

Post by gotchange » Sun, Dec 06, 2015, 9:35 PM UTC

wycats wrote: post #26

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 y…

I think maybe he means that it is not idiomatic. It doesn't feel like JS with the proposed Ruby-like new bind syntax and now with this Unix-flavored pipeline operator, the language is taking on a new identity that some may not like.

Re: ES7 Proposal: The Pipeline Operator

#56

Post by gotchange » Sun, Dec 06, 2015, 9:39 PM UTC

Sonata wrote: post #54

After having used this operator in Elixir and Elm, I would love to see it in JS. I know it seems like a superficial issue, but I think the left-to-right chaining flow is one of the main things people miss as they move from an OO style to a more functional one.

It is not superficial or trivial at all. This proposal helps to ease the cognitive load required when reading or debugging code at least for the straightforward cases and makes writing code even more interesting and intuitive.

Re: ES7 Proposal: The Pipeline Operator

#57

Post by pygy_ » Sun, Dec 06, 2015, 9:42 PM UTC

@dang, was this manually penalized? Or is it a false positive to the flamewar detector?

It looked like a fine submission.

52 points, an hour ago, and it lies on the third page...

Re: ES7 Proposal: The Pipeline Operator

#58

Post by gotchange » Sun, Dec 06, 2015, 9:45 PM UTC

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.

This is syntactic sugar not cruft. They're not proposing to add any new functionality to what we already have.

Re: ES7 Proposal: The Pipeline Operator

#59

Post by lisivka » Sun, Dec 06, 2015, 9:51 PM UTC

dustingetz wrote: post #47

wycats wrote: post #26

Earlier quoted context omitted.

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 y…

js objects are mutable; utliliy libraries like underscore, lodash, jquery, do not provide purity guarantees, they export impure functions that mutate objects (e.g. https://lodash.com/docs#merge ). When we start leaning heavily on function composition to build our abstractions, we simply must have purity guarantees for everyday utilities or everything falls apart. So to go "full-on functional" in javascript means we n…

So we need an (a) method to freeze object and it children, (b) to indicate that function will accept and/or return only read-only objects. Reserved "const" keyword is perfect for that.

Re: ES7 Proposal: The Pipeline Operator

#60

Post by mateuspv » Sun, Dec 06, 2015, 10:04 PM UTC

If is to be more functional like e prefer add functions: compose and curry:

1 - // With pipe: var result = "hello" |> doubleSay |> capitalize |> exclaim;

  With compose:
  var greet = compose(exclaim, capitalize, doubleSay);
  greet("hello");
  // or compose(exclaim, capitalize, doubleSay)("hello");

2 - var person = { score: 25 };

  // With pipe:
  var newScore = person.score
    |> double
    |> score => add(7, score)
    |> validateScore

  // With compose and curry:
  var newScore = compose(validateScore, curry(add(7), double);
  newScore(person.score);

3 - Mixin paradigms

  // With compose and curry :
  var newScore = Function.compose(validateScore, add.curry(7), double);
  newScore(person.score);