Is pipelining the right term here? I've always used the term "transducer" to describe this kind of process, I picked it up from an episode of FunFunFunction if I'm not mistaken.
Pipelining might be my favorite programming language feature
251–260 of 360 posts
Re: Pipelining might be my favorite programming language feature
#252Earlier quoted context omitted.
Base R as well: |> was implemented as a pipe operator in 4.1.0.
Importantly, the base R pipe implements the operation at the language parsing level, so it has basically zero overhead.
I would assume, that most languages do that, or alternatively have a compiler, that is smart enough to ensure there is no actual overhead in the compiled code.
Re: Pipelining might be my favorite programming language feature
#253I don't know. I find this:
fn get_ids(data: Vec) -> Vec {
let mut result = Vec::new();
for widget in &data {
if widget.alive {
result.push(widget.id);
}
}
result
}
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
#254I've always wondered why more languages don't do this. It just makes sense
Re: Pipelining might be my favorite programming language feature
#255I'm personally someone who advocates for languages to keep their feature set small and shoot to achieve a finished feature set quickly. However. I would be lying if I didn't secretly wish that all languages adopted the `|>` syntax from Elixir. ``` params |> Map.get("user") |> create_user() |> notify_admin() ```
[deleted]
Re: Pipelining might be my favorite programming language feature
#256Is pipelining the right term here? I've always used the term "transducer" to describe this kind of process, I picked it up from an episode of FunFunFunction if I'm not mistaken.
Aren't transducers strictly functional terminology?
Also, does the name matter if it works the same and has the same properties?
Maybe the author called it "pipelines" to avoid functional purists from nitpicking it.
Re: Pipelining might be my favorite programming language feature
#257PowerShell has the best pipeline capability of any language I have ever seen.
For comparison, UNIX pipes support only trivial byte streams from output to input.
PowerShell allows typed object streams where the properties of the object are automatically wired up to named parameters of the commands on the pipeline.
Outputs at any stage can not only be wired directly to the next stage but also captured into named variables for use later in the pipeline.
Every command in the pipeline also gets begin/end/cancel handlers automatically invoked so you can set up accumulators, authentication, or whatever.
UNIX scripting advocates don’t know what they’re missing out on…
Re: Pipelining might be my favorite programming language feature
#258Is pipelining the right term here? I've always used the term "transducer" to describe this kind of process, I picked it up from an episode of FunFunFunction if I'm not mistaken.
Aren't transducers strictly functional terminology? Also, does the name matter if it works the same and has the same properties? Maybe the author called it "pipelines" to avoid functional purists from nitpicking it.
Yeah I do think of transducers as a functional paradigm, I read the article as describing a very functional paradigm as well.
In the context of a specific programming language feature it seems like terminology would be important, I wasn't trying to nitpick unintentionally.
Re: Pipelining might be my favorite programming language feature
#259First example doesn't look bad in C++23: auto get_ids(std::span data) { return data | filter(&Widget::alive) | transform(&Widget::id) | to (); }
To me, the cool (and uncommon in other languages' standard libraries) part about C++ ranges is that they reify pipelines so that you can cut and paste them into variables, like so:
auto get_ids(std::span data)
{
auto pipeline = filter(&Widget::alive) | transform(&Widget::id);
auto sink = to();
return data | pipeline | sink;
}Re: Pipelining might be my favorite programming language feature
#260Pipelining looks nice until you have to debug it. And exception handling is also very difficult, because that means to add forks into your pipelines. Pipelines are only good for programming the happy path.
Pipelining is just syntactic sugar for nested function calls. If you need to handle an unhappy path in a way that isn’t optimal for nested function calls then you shouldn’t be nesting your function calls. Pipelining doesn’t magically make things easier nor harder in that regard. But if a particular sequence of function calls do suit nesting, then pipelining makes the code much more readable because you’re not mixing…
I think they are talking about nested loops, not nested function calls.