Earlier quoted context omitted.
Why, if you don't have to, would you write the functions in reverse order of when they're applied?
Because it makes more sense?
Does it actually make more sense, or is it just more familiar?
Pipelining might be my favorite programming language feature
51–60 of 360 posts
Re: Pipelining might be my favorite programming language feature
#52Is this pipelining or the builder pattern?
"These are the same picture." (Sort of.)
Re: Pipelining might be my favorite programming language feature
#53Am I the only one who thinks yuck? Instead of writing: a().b().c().d(), it's much nicer to write: d(c(b(a()))), or perhaps (d ∘ c ∘ b ∘ a)().
Why, if you don't have to, would you write the functions in reverse order of when they're applied?
function application is right associative?
Re: Pipelining might be my favorite programming language feature
#54While the author claims "semantics beat syntax every day of the week," the entire article focuses on syntax preferences rather than semantic differences. Pipelining can become hard to debug when chains get very long. The author doesn't address how hard it can be to identify which step in a long chain caused an error. They do make fun of Python, however. But don't say much about why they don't like it other than showi…
It's just as difficult to debug when function calls are nested inline instead of assigning to variables and passing the variables around.
Re: Pipelining might be my favorite programming language feature
#55Kotlin sort of have it with let (and run)
a().let{ b(it) }.let{ c(it) }Re: Pipelining might be my favorite programming language feature
#56C# has had "Pipelining" (aka Linq) for 17 years. I do miss this kind of stuff in Go a little.
Agreed. It would be nice if SQL databases supported something similar.
I've used "a series of CTEs" to apply a series of transformations and filters, but it's not nearly as elegant as the pipe syntax.
Re: Pipelining might be my favorite programming language feature
#57Earlier quoted context omitted.
You can add peek steps in pipelines and inspect the in between results. Not really any different from normal function call debugging imo.
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()
I feel like a sufficiently good debugger should allow you to place a breakpoint at any of the lines here, and it should break exactly at that specific line.
fn get_ids(data: Vec) -> Vec {
data.iter()
.filter(|w| w.alive)
.map(|w| w.id)
.collect()
}
Re: Pipelining might be my favorite programming language feature
#58C# has had "Pipelining" (aka Linq) for 17 years. I do miss this kind of stuff in Go a little.
Agreed. It would be nice if SQL databases supported something similar.
PRQL [1] is a pipeline-based query language that compiles to SQL.
Re: Pipelining might be my favorite programming language feature
#59Earlier quoted context omitted.
Cool I love it, but another thing we will need polyfills for...
How do you polyfill syntax?
Letting your JS/TS compiler convert it into supported form. Not really a polyfill, but it allows to use new features in the source and still support older targets. This was done a lot when ES6 was new, I remember.
Re: Pipelining might be my favorite programming language feature
#60You can somewhat achieve a pipelined like system in sql by breaking down your steps into multiple CTEs. YMMV on the performance though.
Yeah, the way to get logical pipelining in SQL without CTEs is nested subqueries in the FROM clause. Unfortunately, the nesting is syntactically ugly and confusing to read which is basically the whole idea behind pipeline syntax.