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

171–180 of 360 posts

Re: Pipelining might be my favorite programming language feature

#171

Post by packetlost »

porridgeraisin wrote: post #167
packetlost wrote: post #163

Earlier quoted context omitted.

It wouldn't though? The first await would... await the value out of the future. You still do the syntactic transformation with the magic parameter. In your example you're awaiting the future returned by getFuture twice and improperly awaiting the output of baz (which isn't async in the example). In reality it would look like: "bar" |> await getFuture() |> baz() |> await bat() (assuming getFuture and bat are both asyn…

Correct me if I'm wrong, but if you use the below syntax "bar" |> await getFuture() How would you disambiguate it from your intended meaning and the below: "bar" |> await getFutureAsyncFactory() Basically, an async function that returns a function which is intended to be the pipeline processor. Typically in JS you do this with parens like so: (await getFutureAsyncFactory())("input") But the use of parens doesn't tran…

I don't think |> really can support applying the result of one of its composite applications in general, so it's not ambiguous.

Given this example:

    (await getFutureAsyncFactory("bar"))("input")
the getFutureAsyncFactory function is async, but the function it returns is not (or it may be and we just don't await it). Basically, using |> like you stated above doesn't do what you want. If you wanted the same semantics, you would have to do something like:

    ("bar" |> await getFutureAsyncFactory())("input")
to invoke the returned function.

The whole pipeline takes on the value of the last function specified.

Re: Pipelining might be my favorite programming language feature

#172

Post by huyegn »

I liked the pipelining syntax so much from pyspark and linq that I ended up implementing my own mini linq-like library for python to use in local development. It's mainly used in quick data processing scripts that I run locally. The syntax just makes everything much nicer to work with.

https://datapad.readthedocs.io/en/latest/quickstart.html#ove...

Re: Pipelining might be my favorite programming language feature

#173

Post by bsder »

amai wrote: post #143

Pipelining 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 also nice until you have to use it for everything because you can't do alternatives (like default function arguments) properly.

Rust chains everything because of this. It's often unpleasant (see: all the Rust GUI toolkits).

Re: Pipelining might be my favorite programming language feature

#175

Post by w4rh4wk5 »

amai wrote: post #143

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

Yes, certainly!

I've encountered and used this pattern in Python, Ruby, Haskell, Rust, C#, and maybe some other languages. It often feels nice to write, but reading can easily become difficult -- especially in Haskell where obscure operators can contain a lot of magic.

Debugging them interactively can be equally problematic, depending on the tooling. I'd argue, it's commonly harder to debug a pipeline than the equivalent imperative code and, that in the best case it's equally hard.

Re: Pipelining might be my favorite programming language feature

#177

Post by michalsustr »

huyegn wrote: post #172

I liked the pipelining syntax so much from pyspark and linq that I ended up implementing my own mini linq-like library for python to use in local development. It's mainly used in quick data processing scripts that I run locally. The syntax just makes everything much nicer to work with. https://datapad.readthedocs.io/en/latest/quickstart.html#ove...

Looks really neat, might use that in my work!

Re: Pipelining might be my favorite programming language feature

#179

Post by dayvigo »

duped wrote: post #95

A pipeline operator is just partial application with less power. You should be able to bind any number of arguments to any places in order to create a new function and "pipe" its output(s) to any other number of functions. One day, we'll (re)discover that partial application is actually incredibly useful for writing programs and (non-Haskell) languages will start with it as the primitive for composing programs instea…

Sure. But how do you write that in a way that is expressive, terse, and readable all at once? Nothing beats x | y | z or (-> x y z). The speed of both writing and reading (and comprehending), the sheer simplicity, is what makes pipelining useful in the first place.

Re: Pipelining might be my favorite programming language feature

#180

Post by pixelmeister »

neuroelectron wrote: post #174

I really like the website layout. I'm guessing that they're optimizing for Kindle or other e-paper readers.

I recognized this site layout from a past HN post about a solar powered website. Check out their about page. It links to the source for the style that explains why it looks the way it does. Not to spoil it, but it's not for e-readers :)
Post reply on HN