4 ms·

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 |> t

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

leansensei 2y ago
Same in Elixir
- b6dybuyv 2y ago
  and in Haskel/Elm
  - MarkMarine 2y ago
    And clojure -> or ->> (thread first or thread last)
- deleted 2y ago
  [deleted]
fantispug 2y ago
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.
- elcritch 2y ago
  It also works with universal function call syntax line in Nim. Though aesthetically I prefer `|>` for multi-line expressions.
- fjkdlsjflkds 2y ago
  > R's magrittr These days, base R already includes a native pipe operator (and it is literally `|>`, rather than magrittr's `%>%`).
- evandrofisico 2y ago
  yeah, in lua some libs are used just like this, using the : syntatic sugar, something line value = table:function1():function2():function3()
runevault 2y ago
At least for me once I first encountered the pipeline operator it has made me dislike traditional inside out code a lot more.
daxfohl 2y ago
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.

leansensei 2y ago

Same in Elixir

b6dybuyv 2y ago
and in Haskel/Elm
- MarkMarine 2y ago
  And clojure -> or ->> (thread first or thread last)
deleted 2y ago
[deleted]

fantispug 2y ago

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.

elcritch 2y ago
It also works with universal function call syntax line in Nim. Though aesthetically I prefer `|>` for multi-line expressions.
fjkdlsjflkds 2y ago
> R's magrittr These days, base R already includes a native pipe operator (and it is literally `|>`, rather than magrittr's `%>%`).
evandrofisico 2y ago
yeah, in lua some libs are used just like this, using the : syntatic sugar, something line value = table:function1():function2():function3()

runevault 2y ago

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

daxfohl 2y ago

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.