Pipelining might be my favorite programming language feature

We might be able to cross one more language off your wishlist soon, Javascript is on the way to getting a pipeline operator, the proposal is currently at Stage 2

https://github.com/tc39/proposal-pipeline-operator

I'm very excited for it.

I prefer Scala. You can write

``` params.get("user") |> create_user |> notify_admin ```

Even more concise and it doesn't even require a special language feature, it's just regular syntax of the language ( |> is a method like .get(...) so you could even write `params.get("user").|>(create_user) if you wanted to)

Yes, a small feature set is important, and adding the functional-style pipe to languages that already have chaining with the dot seems to clutter up the design space. However, dot-chaining has the severe limitation that you can only pass to the first or "this" argument.

Is there any language with a single feature that gives the best of both worlds?

It would be even better without the `>`, though. The `|>` is a bit awkward to type, and more noisy visually.

I feel like Haskell really missed a trick by having $ not go the other way, though it's trivial to make your own symbol that goes the other way.

... and then recreate the scripting language...

And base R has had a pipe for a couple years now, although there are some differences between base R's |> and tidyverse's %>%: https://www.tidyverse.org/blog/2023/04/base-vs-magrittr-pipe...

I've always found magrittr mildly hilarious. R has vestigial Lisp DNA, but somehow the R implementation of pipes was incredibly long, complex and produced stack traces, so it moved to a native C implementation, which nevertheless has to manipulate the SEXPs that secretly underlie the language. Compared to something like Clojure's threading macros it's wild how much work is needed.

Base R as well: |> was implemented as a pipe operator in 4.1.0.

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

Yeah, I agree that this can be problem when you lean heavily into monadic handling (i.e. you have fallible operations and then pipe the error or null all the way through, losing the information of where it came from).

But that doesn't have much to do with the article: You have the same problem with non-pipelined functional code. (And in either case, I think that it's not that big of a problem in practice.)

> The author uses examples that function very differently.

Yeah, this is addressed in one of the later sections. Imo, having a unified word for such a convenience feature (no matter how it's implemented) is better than thinking of these features as completely separate.

You can add peek steps in pipelines and inspect the in between results. Not really any different from normal function call debugging imo.

It's just as difficult to debug when function calls are nested inline instead of assigning to variables and passing the variables around.

the paragraph you quoted (atm, 7 mins ago, did it change?) says:

>Let me make it very clear: This is [not an] article it's a hot take about syntax. In practice, semantics beat syntax every day of the week. In other words, don’t take it too seriously.

I think you may have misinterpreted his motive here.

Just before that statement, he says that it is an article/hot take about syntax. He acknowledges your point.

So I think when he says "semantics beat syntax every day of the week", that's him acknowledging that while he prefers certain syntax, it may not be the best for a given situation.

The article also clearly points that that it's just a hot-take, and to not take it too seriously.

This is not functionally different from operator<< which std::cout has taught us is a neat trick but generally a bad idea.

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

> The second approach is open for extension - it allows you to write new functions on old datatypes.

I prefer to just generalize the function (make it generic, leverage traits/typeclasses) tbh.

> Probably for lack of > weird operators like <$>, <*>, $, or >>=

Nope btw. I mean, maybe? I don't know Haskell well enough to say. The answer that I was looking for here is a specific Rust idiosyncrasy. It doesn't allow you to import `std::iter::Iterator::collect` on its own. It's an associated function, and needs to be qualified. (So you need to write `Iterator::collect` at the very least.)

In my eyes newlines don't solve what I feel to be the issue. Reader needs to recognize reading from left->right to right->left.

Of course this really only matters when you're 25 minutes into critical downtime and a bug is hiding somewhere in these method chains. Anything that is surprising needs to go.

IMHO it would be better to set intermediate variables with dead simple names instead of newlines.

fn get_ids(data: Vec<Widget>) -> Vec<Id> {

    let iter = iter(data);

    let wingdings = map(iter, |w| w.toWingding());

    let alive_wingdings = filter(wingdings, |w| w.alive);

    let ids = map(alive_wingdings, |w| w.id);

    let collected = collect(ids);

    collected

}

Oh wow, are we living in the same universe? To me the one-line example and your example with line breaks... they just... look about the same?

See how adding line breaks still keeps the `|w| w.alive` very far from the `filter` call? And the `|w| w.id` very far from the `map` call?

If you don't have the pipeline operator, please at least format it something like this:

    fn get_ids(data: Vec<Widget>) -> Vec<Id> {
        collect(
            map(
                filter(
                    map(
                        iter(data),
                        |w| w.toWingding()
                    ),
                    |w| w.alive
                ),
                |w| w.id
            )
        )
    }

Also see how this still reads fine despite being one line:

    fn get_ids(data: Vec<Widget>) -> Vec<Id> {
        data.iter().map(|w| w.toWingding()).filter(|w| w.alive).map(|w| w.id).collect()
    }

They did touch on that.

> You might think that this issue is just about trying to cram everything onto a single line, but frankly, trying to move away from that doesn’t help much. It will still mess up your git diffs and the blame layer.

Diff will still be terrible because adding a step will change the indentation of everything 'before it' (which, somewhat confusingly, are below it syntactically) in the chain.

I don't see how LINQ provides an especially illuminating example of what is effectively method chaining.

It is an exemplar of expressions [0] more than anything else, which have little to do with the idea of passing results from one method to another.

[0]: https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

Agreed. It would be nice if SQL databases supported something similar.

As well as some-> (exit on null) and cond-> (with predicates) that are often handy.