Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pipelining might be my favorite programming language feature

herecomesthemoon.net

Post reply on HN
Print view View original

71–80 of 360 posts

Re: Pipelining might be my favorite programming language feature

#73

Post by delusional »

tantalor wrote: post #71

> allows you to omit a single argument from your parameter list, by instead passing the previous value I have no idea what this is trying to say, or what it has to do with the rest of the article.

It's getting at the essential truth that for all(?) mainstream languages since object orientation and the dot syntax became a thing `a.b()` implicitly includes `a` as the first argument to the actual method `b(a self)`. Different languages have different constructs on top of that, C++ for example includes a virtual dispatch mechanism, but the one common idea of the _method call_ is that the `self` pointer is passed as the first argument.

Re: Pipelining might be my favorite programming language feature

#74

Post by packetlost »

TehShrike wrote: post #62
Cyykratahk wrote: post #36

Earlier quoted context omitted.

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 was excited for that proposal, but it veered off course some years ago – some TC39 members have stuck to the position that without member property support or async/await support, they will not let the feature move forward. It seems like most people are just asking for the simple function piping everyone expects from the |> syntax, but that doesn't look likely to happen.

I don't actually see why `|> await foo(bar)` wouldn't be acceptable if you must support futures.

I'm not a JS dev so idk what member property support is.

Re: Pipelining might be my favorite programming language feature

#75

Post by Symmetry »

bnchrch wrote: 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() ```

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.

Re: Pipelining might be my favorite programming language feature

#76

Post by inetknght »

0xf00ff00f wrote: post #72

First example doesn't look bad in C++23: auto get_ids(std::span data) { return data | filter(&Widget::alive) | transform(&Widget::id) | to (); }

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

Re: Pipelining might be my favorite programming language feature

#77

Post by delusional »

bob1029 wrote: post #61
osigurdson wrote: post #13

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

You might be talking about LINQ queries, while the person you are responding to is probably talking about LINQ in Method Syntax[1]

[1]: https://learn.microsoft.com/en-us/dotnet/csharp/linq/get-sta...

Re: Pipelining might be my favorite programming language feature

#78

Post by higherhalf »

Mond_ wrote: post #49
mrkeen wrote: post #19

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

> 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 impo…

> It doesn't allow you to import `std::iter::Iterator::collect` on its own. It's an associated function, and needs to be qualified.

You probably noticed, but it should become a thing in RFC 3591: https://github.com/rust-lang/rust/issues/134691

So it does kind of work on current nightly:

  #![feature(import_trait_associated_functions)]
  
  use std::iter::Iterator::{filter, map, collect};

  fn get_ids2(data: Vec) -> Vec {
      collect(map(filter(Vec::into_iter(data), |w| w.alive), |w| w.id))
  }  

  fn get_ids3(data: impl Iterator) -> Vec {
      collect(map(filter(data, |w| w.alive), |w| w.id))
  }

Re: Pipelining might be my favorite programming language feature

#79

Post by RHSeeger »

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, since it called out, diff better)

    fn get_ids(data: Vec) -> Vec {
        collect(
            map(
                filter(
                    map(iter(data), |w| w.toWingding()), |w| w.alive), |w| w.id))
    }
Admittedly, the chaining is still better. But a fair number of the article's complaints are about the lack of newlines being used; not about chaining itself.

Re: Pipelining might be my favorite programming language feature

#80

Post by jose_zap »

Symmetry wrote: post #75
bnchrch wrote: 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() ```

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
Post reply on HN