TC39 Pipeline Operator – Hack vs. F#

https://benlesh.com/posts/tc39-pipeline-proposal-hack-vs-f-sharp/

by jashkenas • 5 years ago

50 72 5 years ago

johnfn• 5 years ago

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 ::?

Smaug1235• 5 years ago

It's a mindset thing. The pipeline operator encourages you to think about repeatedly transforming static dumb data. Dot-operators encourage you to think about repeatedly asking some smart blob of state to mutate itself. So the pipeline lends itself well to a purer mindset.

F# itself much prefers the pipeline, because of how its type inference algorithm works. F#'s type inference finds it much harder to work out the types when you use a dot operator, because so many possible types T could have `(x : T).Foo(bar)`, all those types are unrelated to each other, and notions of "has a member `Foo`" are quite hard to get right in the type system. By contrast, if you call `x |> List.map bar`, the types are almost totally fixed in an easy-to-understand way.

"Handling many different data types with a single function is an annoying thing to get right" - no, this is very common, and generics even make it easy.

adz5a• 5 years ago

Dot operators vs plain functions are just two different ways to call a function, binding the lexical context `this` to a different value, possibly `undefined` in a strict context (which is default in es6 modules). The two are not uncompatible and libraries like jQuery make a wonderful use of the first version (dot call). The fact is that everything is mutable in JavaScript and one of its main API (the DOM) is actually built around this concept.

I really fail to see how those kind of changes bring anything of value to the language, apart from creating complexity where there is much already: some codebases will try and use this before it's ironed out with different / changing / competing transpiler implementation while it is only stage 2. What happened with decorators (see babel-legacy-decorators) should be a warning against enthusiasm for these kind of things and remind me of the pitfalls of macros in the Lisp world...

I am not saying that you should stick with an idiom till the end of time but changes should try and lower that complexity while (in the case of EcmaScript) being backward compatible so as to not break existing stuff.

Btw I love RxJS and its variants, Ben Lesh's talks (as well as those by Matthew Podwysocki, Andre Staltz etc...) from around 2015 and then on were one of the reasons I got into JS as a professional.

LAC-Tech2• 5 years ago

Dot-operators encourage you to think about repeatedly asking some smart blob of state to mutate itself.

Smart Blobs don't have to mutate themselves anymore than procedures have to have side effects.

Zababa7• 5 years ago

I think one of the use cases is that it's easier to have a series of functions on immutable data compared to chaining classes. Considering JavaScript may get immutable data structures at some point, this would work well with them.

There is also the fact that JavaScript supports different types of programming, functional being one of them. Having a pipe operator helps you to make very clean and readable functional code.

Edit: the article also mentionned that methods can't be tree shaken. That's another improvement.

graftak• 5 years ago

Tuples and records are proposed immutable data structures and currently in stage 2[1] (same as the pipe operator).

[1] https://github.com/tc39/proposal-record-tuple

azangru2• 5 years ago

once you move away from toy examples, most pipeline operator use cases are already covered by chaining class methods on classes

But what if we don't want to use classes? What if we want to be cool and compose functions out of functions, Ramda-style, or Elm-style?

nsonha7• 5 years ago

Unpopular opinion: we could just add, say, `pipe` and `pipeAsync` into the standard library, appart from aesthetic, I don't see the pipe operator to be very useful, at least the F# one doesn't because it's literally just another syntax for function invocation.

akra2• 5 years ago

Chaining methods on classes

But defining these is typically left to library authors in many languages. Writing your own Fluent/chaining interface isn't usually worth the effort. Where in these languages because any function is "chainable" and gets it for free a lot of programming ends up being chained pipelines. Anything where there is a logical workflow (a lot of programming) ends up being nice to read when expressed with pipes (i.e. do this, then this, then that, and finally return this). The pipe operator goes hand in hand with currying as well since you can complete some of the arguments before wiring the partial completed function into a generic workflow; a pattern that typically isn't be done with Fluent/Chaining methods on classes.

overton• 5 years ago

The primary usecase (which happens to me fairly frequently in Javascript) is when you need to operate on a native or library data structure with some function other than its built-in methods.

Some people also find it easier to program in an FP style (separating data and functions) in their app code. It seems to be a matter of neurodiversity.

Kaze404• 5 years ago

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

nsonha7• 5 years ago

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)

junon7• 5 years ago

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?

paulddraper• 5 years ago

    return first() | second(_, 10) | third(x, y, _)

I somewhat agree.

junon7• 5 years ago

Further, it has to be |> to disambiguate from bitwise OR. So yet another symbol to confuse readers.

And the placeholder can't be _ as that's a valid identifier. The first issue on the tracker is the bike shedding thread about what the placeholder symbol should be, and it's neither _ nor ^, but instead probably something like ^label.

nsonha7• 5 years ago

Agree what? You can't overload bitwise with another semantic

Zababa7• 5 years ago

In your example you're mutating v, which is something people try to avoid these days, as immutable data is easier to work with. There's also a good chance you can't find a good name for v that fits what it is at every step. A good part of the pipeline operator is that you don't have to name every step. Sometimes there's just no good name.

junon7• 5 years ago

as immutable data is easier to work with

Source? This hasn't been my experience. Going on 10 years of heavy Node.js ecosystem involvement, immutable data enthusiasts are exceedingly rare.

Plus, this is const vs let, which is a reach to call "immutable data". We're not talking about object properties.

eyelidlessness5• 5 years ago

- One thing not discussed in the article is type safety. But TC39 increasingly considers the impact of proposals on typed extensions to JS like TypeScript/Flow. In your example, v must be a union type of the return types of each of the called functions.

- The pipeline operator can be used to assign to a const, to prevent further assignments. While const isn’t necessarily immutable, it is often idiomatically used to signal that the assigned value is intended to be final. The same can’t be achieved with your example without wrapping it in an IIFE, which is (IMO) much harder to follow than the pipeline operator.

- More subjectively, it (in the F# variant) encourages better interfaces. For most use cases where piping would be appropriate, it’s generally a good idea to make the data you’re processing the last parameter. This also, as the article notes, works well with partial application. Which in turn also encourages good practices like composition.

junon7• 5 years ago

I think your first point is the only compelling reason (for me) yet I also hold the stance that TC39 shouldn't cater to corporate projects such as Typescript as they are not maintained by the same committee.

Those are my opinions, however.

dtech3• 5 years ago

The advantage is that you don't have to name things. "v" is a bad name in a larger context, and it quikly becomes unwieldy if you use a full name.

    let transformedData = transformFoo(data);
    transformedData = transformBar(transformedData);
    transformedData = transformBaz(transformedData);

 vs.

    const transformedData = data
      |> transformFoo
      |> transformBar
      |> transformBaz

If you want have const's the first becomes even more unwieldy, and in general I'd recommend using const by default.

Just like lambda syntax makes it much easier and readable to write small functions, the pipe operator make it much easier and readable to write chains.

throw_m2393392• 5 years ago

Just like lambda syntax makes it much easier and readable to write small functions, the pipe operator make it much easier and readable to write chains.

succinct =/= more readable.

Readability here is really in the eye of the beholder...

It's certainly quicker to type, but that's not a good argument enough to make such a drastic change in javascript.

tzs• 5 years ago

I find |> annoying to type. How about making it so unary functions can be invoked like this?

  arg function_name

Then instead of

  arg |> func1 |> func2 |> func3

you could simply write

  arg func1 func2 func3

It might get a bit ugly when used with arrow functions instead of named functions, and there might need to be a special case when arg is a function, but if those problems could be handled not too unreasonably this seems a fine approach for a programming language.

jasperry2• 5 years ago

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?

Smaug1235• 5 years ago

Mathematica has `f[a,#,b]&`, for example, which is syntactic sugar for `Function[{x}, f[a,x,b]]`, i.e. the function that takes one argument and calls `f` with that argument as the middle parameter and `a, b` as the first and last parameters. It's not quite what you're referring to, but it's similarly an extremely lightweight syntax.

awild• 5 years ago

Tidyr/dplyr (R) can do something very close to this but I don't know how it is achieved. There it is a dot

uryga• 5 years ago

  y %>% f(x, ., z)  ===  f(x, y, z)

R lets you do macro-ish things at at runtime [1], and `.` is a valid variable name [2]. so %>% can just evaluate the AST of its right argument in an environment with `. = a`.

(it's probably a bit more involved because %>% also supports

  a %>% f(b)  ===  f(a, b)

in which case %>% has to do some AST surgery to splice another argument in front of `b`.)

---

[1] https://en.wikipedia.org/wiki/Fexpr

[2] think `_` in python etc. R uses dots instead of underscores

rojoca• 5 years ago

Clojure has the as-> threading macro (probably borrowed from another lisp) where you can specify the placeholder:

  (as-> [:foo :bar] v
    (map name v)
    (first v)
    (.substring v 1))

ducaale• 5 years ago

FYI, you can achieve the same thing with F# pipelines + partial application proposal [1]

  input |> func(?, 2)
  input |> func(1, ?)

While hack's placeholders work exclusively in pipelines, the partial application proposal can be used with any function

  "123"
    .split("")
    .map(parseInt(?)) // make sure radix param is not set

[1] https://github.com/tc39/proposal-partial-application

nsonha7• 5 years ago

scala, with its magical underscore. Although it likely desugars to lambdas (or even anonymous classes lol, given how java works)

Actualy this whole debate should be called scala vs F# because they are more corresponding, being both functional language on a OOP runtime.

akra2• 5 years ago

There is pros/cons to both approaches. The Pipe operator in F# works in conjunction with the HM type inference in the language and static functions often assisting the type checker. i.e. features that work together in a language vs tacked on. F# idiomatic code avoids a lot of virtual dispatch seen in Java/C#, etc as compile time polymorphism is typically how re-use occurs vs objects. I find F# favors compile time abstractions a little more than Scala historically although I note that could be changing.

For most of these proposals it is just syntactic sugar around invoking the function with a placeholder. The pipe in F# is slightly different in that most of the time it has no intermediate lambdas and is compiled in a more performant form. The downside is that unless you allocate that lambda yourself it has to be the last arg. On the plus side like most things in F# it is concise but shows all behavior explicitly - its usually a warning sign if you have to do that and helps reason about performance. Sometimes its a sign that the original function isn't written right or some other inline wrapper could be used for other usages of the function. You can inline a template to rearrange the arg's (inline) to avoid the lambda allocation as well.

This allows some level of re-use and performance benefits avoiding virtual table dispatch and a lambda allocation for many common methods (e.g. map, fold, iter, etc)

abecedarius3• 5 years ago

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.

throw_m2393392• 5 years ago

and why stop there? Introduce lazy evaluation, type classes, custom operator overloading and what not...

I'm jesting of course, I find JavaScript already too complicated, it's like some people want to make it look like Scala... just no.

dtech3• 5 years ago

I'm mainly puzzled why they want to introduce additional syntax specific for it, when higher order function are perfectly possible in the current language already and integrate well with the F#-style pipe.

abecedarius3• 5 years ago

Very reasonable, and that's why I phrased it like "if we do this".

A TC39 member on this topic of restraint and priorities: https://erights.medium.com/the-tragedy-of-the-common-lisp-wh...

nsonha7• 5 years ago

I find JavaScript already too complicated

I get that you don't want it *to become* complicated, but as it currently is, JavaScript is still a rather simple language.

dtech3• 5 years ago

This is sort-of how Scala does it. _ in the context of a lambda means "the next argument", so it is general:

    val plus: (Int, Int) => Int = _ + _

jasperry2• 5 years ago

It looks like Hack doesn't support first-class functions, which would explain why they don't do this. But I agree that it would be a neat short notation for lambdas.

ejones• 5 years ago

There's a proposal for this: https://github.com/tc39/proposal-partial-application

abecedarius3• 5 years ago

That's more specialized: it can express

    foo(42, ?)

but not what you'd write within this pipe syntax as

    foo(42, ^) + 1

The tradeoff is that it doesn't need some extra delimiter since the function call is what delimits it. Perhaps that's a better tradeoff, I'm not sure; but for sure we shouldn't have both.

ibraheemdev• 5 years ago

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

ranguna• 5 years ago

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.

rk06• 5 years ago

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

TC39 Pipeline Operator – Hack vs. F#

Related Stories