Pipelining might be my favorite programming language feature
121–130 of 360 posts
Re: Pipelining might be my favorite programming language feature
#122Re: Pipelining might be my favorite programming language feature
#123Earlier quoted context omitted.
Yes, but here's my hot take - what if you didn't have to edit the source code to debug it? Instead of chaining method calls you just assign to a temporary variable. Then you can set breakpoints and inspect variable values like you do normally without editing source. It's not like you lose that much readability from foo(bar(baz(c))) c |> baz |> bar |> foo c.baz().bar().foo() t = c.baz() t = t.bar() t = t.foo()
The Clojure equivalent of `c |> baz |> bar |> foo` are the threading macros: (-> c baz bar foo) But people usually put it on separate lines: (-> c baz bar foo)
Re: Pipelining might be my favorite programming language feature
#124Re: Pipelining might be my favorite programming language feature
#125Earlier quoted context omitted.
Haskell has & which goes the other way: users & map validate & catMaybes & mapM persist
Yes, `&` (reverse apply) is equivalent to `|>`, but it is interesting that there is no common operator for reversed compose `.`, so function compositions are still read right-to-left. In my programming language, I added `.>` as a reverse-compose operator, so pipelines of function compositions can also be read uniformly left-to-right, e.g. process = map validate .> catMaybes .> mapM persist
There is also https://hackage.haskell.org/package/flow which uses .> and EDIT: in no way do I want to claim the originality of these things in Elm or the Haskell package inspired by it. AFAIK |> came from F# but it could be miles earlier.
Re: Pipelining might be my favorite programming language feature
#126A pipeline operator is just partial application with less power. You should be able to bind any number of arguments to any places in order to create a new function and "pipe" its output(s) to any other number of functions. One day, we'll (re)discover that partial application is actually incredibly useful for writing programs and (non-Haskell) languages will start with it as the primitive for composing programs instea…
... and then recreate the scripting language...
Re: Pipelining might be my favorite programming language feature
#127Kotlin sort of have it with let (and run) a().let{ b(it) }.let{ c(it) }
And it's already idiomatic unlike bolting a pipeline operator onto a language that didn't start with it.
Re: Pipelining might be my favorite programming language feature
#128I miss F#
Re: Pipelining might be my favorite programming language feature
#129data.iter() .filter(|w| w.alive) .map(|w| w.id) .collect() collect(map(filter(iter(data), |w| w.alive), |w| w.id)) The second approach is open for extension - it allows you to write new functions on old datatypes. > Quick challenge for the curious Rustacean, can you explain why we cannot rewrite the above code like this, even if we import all of the symbols? Probably for lack of > weird operators like , , $, or >>=
Extension methods to the rescue: https://en.wikipedia.org/wiki/Extension_method Examples: https://kotlinlang.org/docs/extensions.html https://docs.scala-lang.org/scala3/reference/contextual/exte... See also: https://en.wikipedia.org/wiki/Uniform_function_call_syntax
I wrote a little pipeline macro in https://nim-lang.org/ for Advent of Code years ago and as far as I know it worked okay.
``` import macros
macro `|>`\* (left, right : expr): expr =
result = newNimNode(nnkCall)
case right.kind
of nnkCall:
result.add(right[0])
result.add(left)
for i in 1..
```Makes me want to go write more nim.