Live data from Hacker News

Pipelining might be my favorite programming language feature

herecomesthemoon.net

101–110 of 360 posts

Re: Pipelining might be my favorite programming language feature

#101
post #98
post #24

I'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() ```

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

I disagree, because then it can be very ambiguous with an existing `|` operator. The language has to be able to tell that this is a pipeline and not doing a bitwise or operation on the output of multiple functions.

Re: Pipelining might be my favorite programming language feature

#102
post #61

C# has had "Pipelining" (aka Linq) for 17 years. I do miss this kind of stuff in Go a little.

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

So many things have been called Linq over the years it's hard to talk about at this point. I've written C# for many years now and I'm not even sure what I would say it's referring to, so I avoid the term.

In this case I would say extension methods are what he's really referring to, of which Linq to objects is built on top of.

Re: Pipelining might be my favorite programming language feature

#103
post #93

Earlier quoted context omitted.

Consistency is more important. If you ever wrote: a(b()) then you're already breaking your left-to-right/first-to-last rule.

There are some math books out there that use (x)f. My understanding is (some) algebraists tried to make it a thing ~60 years ago but it never really caught on.

There are, but they leave out the parens and use context to distinguish function application from multiplication.

Re: Pipelining might be my favorite programming language feature

#104
post #24

I'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() ```

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?

FWIW you can pass to other arguments than first in this syntax

```

params

|> Map.get("user")

|> create_user()

|> (&notify_admin("signup", &1)).() ```

or

```

params

|> Map.get("user")

|> create_user()

|> (fn user -> notify_admin("signup", user) end).() ```

Re: Pipelining might be my favorite programming language feature

#105

I feel like, at least in some cases, the article is going out of its way to make the "undesired" look worse than it needs to be. Compairing fn get_ids(data: Vec ) -> Vec { collect(map(filter(map(iter(data), |w| w.toWingding()), |w| w.alive), |w| w.id)) } to fn get_ids(data: Vec ) -> Vec { data.iter() .map(|w| w.toWingding()) .filter(|w| w.alive) .map(|w| w.id) .collect() } The first one would read more easily (and, s…

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) -> Vec {
        collect(
            map(
                filter(
                    map(
                        iter(data),
                        |w| w.toWingding()
                    ),
                    |w| w.alive
                ),
                |w| w.id
            )
        )
    }
...which is still absolutely atrocious both to write and to read!

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

    fn get_ids(data: Vec) -> Vec {
        data.iter().map(|w| w.toWingding()).filter(|w| w.alive).map(|w| w.id).collect()
    }
It's not about line breaks, it's about the order of applying the operations, and about the parameters to the operations you're performing.

Re: Pipelining might be my favorite programming language feature

#106

Earlier quoted context omitted.

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.

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

Re: Pipelining might be my favorite programming language feature

#107
post #98

Earlier quoted context omitted.

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

I disagree, because then it can be very ambiguous with an existing `|` operator. The language has to be able to tell that this is a pipeline and not doing a bitwise or operation on the output of multiple functions.

Yes, I’m talking about a language where `|` would be the pipe operator and nothing else, like in a shell. Retrofitting a new operator into an existing language tends to be suboptimal.

Re: Pipelining might be my favorite programming language feature

#108
Maybe it's because I love the Unix shell environment so much, but I also really love this style. I try to make good use of it in every language I write code in, and I think it helps make my control flow very simple. With lots of pipelines, and few conditionals or loops, everything becomes very easy to follow.

Re: Pipelining might be my favorite programming language feature

#109

This is just super basic functional programming. Seems like we're taking the long way around...

Have you read the article? This isn't about functional vs. imperative programming, it's (if anything) about two different ways to write functional code.

Re: Pipelining might be my favorite programming language feature

#110
A thing I really like about pipelines in shell scripts, is all of the buffering and threading implied by them. Semantically, you can see what command is producing output, and what command is consuming it. With some idea of how the CPU will be split by them.

This is far different than the pattern described in the article, though. Small shame they have come to have the same name. I can see how both work with the metaphor; such that I can't really complain. The "pass a single parameter" along is far less attractive to me, though.

Post reply on HN