Hacker News Reader

Comment by vunderba | Hacker News Reader

While I wouldn't say "mind blown", I really like F#'s built-in support for fluent interface style programming using the pipeline operator, e.g.

  X |> one |> two |> three

  versus the more conventional

  three(two(one(X)))

View on HN

I find this style changes the way I think about and write code transformations. It's also in shell pipelines, R's magrittr, and Clojure's thread macros, and can be emulated in some OO languages with methods that return the transformed object itself.

It also works with universal function call syntax line in Nim. Though aesthetically I prefer `|>` for multi-line expressions.

> R's magrittr

These days, base R already includes a native pipe operator (and it is literally `|>`, rather than magrittr's `%>%`).

yeah, in lua some libs are used just like this, using the : syntatic sugar, something line

value = table:function1():function2():function3()

I wish there was a linter that could limit it though. It's like coders' subconsciouses say "the feature exists, so I have to use it to the greatest extent possible". Or, "assigning intermediate values is now an anti-pattern", and we end up with things that are like 20 straight pipes, with more pipes inside lambdas of those pipes, etc., that result in a function that is totally incomprehensible. All it really saves us from is this:

let x1 = one(x); let x2 = two(x1); let x3 = three(x2);

The other advantage of being explicit is you can set breakpoints and see the intermediate values when debugging.

Granted, the same could be said about `three(two(one(X)))`, so it's not specifically a pipe operator problem. It's just that I see it a lot more ever since pipe operators (or their cousins "streams", "extension methods", etc) have been popularized.

My guess is it's because `three(two(one(X)))` across multiple lines would need indentation on each nested function, and end up looking obviously obtuse with too many levels of nesting. Pipes make it look cleaner, which is great at some level, but also more tempting to get caught up in "expression golf" leading to extremely concise but incomprehensible code.

Same in Elixir

and in Haskel/Elm

And clojure -> or ->> (thread first or thread last)

At least for me once I first encountered the pipeline operator it has made me dislike traditional inside out code a lot more.

Reply on news.ycombinator.com