from Hacker News

TC39 Pipeline Operator – Hack vs. F#

by jashkenas on 9/14/21, 7:38 PM with 75 comments

• by johnfn on 9/14/21, 8:40 PM

  The thing about the pipeline operator that strikes me is how toylike all the examples are. Look at this article for example - it’s a bunch of examples of adding and exponentiating numbers, as if you couldn’t do that already in a single line of code.

  My suspicion is that once you move away from toy examples, most pipeline operator use cases are already covered by chaining class methods on classes. I suppose you could argue that the pipeline operator allows you to operate across multiple different data types, but I further suspect that handling many different data types with a single function is an annoying thing to get right and this won’t come up in practice all too often.

  To be fair, the case of pulling in only the methods you need on rxjs seems somewhat useful… but do we really need a whole new operator just for that? And isn’t that the point of ::?

• by Kaze404 on 9/14/21, 8:49 PM

  I've wanted a pipeline operator in JavaScript for a while now. Working with Elm and Elixir has made me think of problems in terms of data transformation, and the pipeline operator is the biggest reason why. "Take X then do Y, Z, J, K, L and finally send it over to the client" makes what would be complicated code be only as complicated as the reader wants, as they can inspect the functions they care about (assuming they even want to).

• by abecedarius on 9/14/21, 9:15 PM

  If you're inventing a special shorthand for functions like foo(42, ^), then why only in the context of a pipe? Make up some punctuation to introduce or surround this kind of expression, then use it anywhere. Less to learn, more useful.

• by junon on 9/14/21, 9:10 PM

  I don't see how any of this is more readable than:

      let v = first();
      v = second(v, 10);
      v = third(x, y, v);
      return v;
  

  Why do we need a new operator for this?

• by ibraheemdev on 9/14/21, 9:37 PM

  I would love the pipeline operator in Ruby, but unfortunately the unstable feature [0] was removed:

      1.. |> take 10 |> map {|e| e*2} |> (x)
  

  > After experiments, |> have caused more confusion and controversy far more than I expected. I still value the chaining operator, but drawbacks are bigger than the benefit. So I just give up the idea now. Maybe we would revisit the idea in the future (with different operator appearance).

  [0]: https://bugs.ruby-lang.org/issues/15799

• by ranguna on 9/15/21, 7:13 AM

  > little hard on the eyes

  Understatement of the year, that's the worst token I've seen in all my years of working with javascript and I hope it doesn't go through.

• by rk06 on 9/15/21, 10:13 AM

  I don't get one thing.

  if pipe() works for RxJs, and hackpipe is not better, then why don't you simply stick with pipe()?

  Just because one operator is there, doesn't mean you have to use it.

  JS classes are notoriously under powered, so much that both react and vue prefer functions over class components

  Besides, it is possible that RxJs (and other libraries) may modify how they work to better utilise hack pipe

• by jasperry on 9/14/21, 9:15 PM

  I had never seen Hack's pipeline before, which uses an explicit marker ^ to indicate which argument the piped object goes to. This seems like a really cool idea--you can wire functions together any way you want without having to create lambdas. Do any other languages use anything like this?

• by nsonha on 9/14/21, 9:08 PM

  cons miss the most important downside of F# proposal which is the runtime optimization aspect of requiring extra lambda functions.

  I went through the github issue the other day, syntax aside, the two proposal boil down to functions vs expressions (no extra functions)