Live data from Hacker News

Pipelining might be my favorite programming language feature

herecomesthemoon.net

181–190 of 360 posts

Re: Pipelining might be my favorite programming language feature

#181

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.

It also has barely seen any activity in years. It is going nowhere. The TC39 committee is utterly dysfunctional and anti-progress, and will not let any this or any other new syntax into JavaScript. Records and tuples has just been killed, despite being cited in surveys as a major missing feature[1]. Pattern matching is stuck in stage 1 and hasn't been presented since 2022. Ditto for type annotations and a million oth…

Records and Tuples weren't stopped because of tc39, but rather the engine developers. Read the notes.

Re: Pipelining might be my favorite programming language feature

#182
post #45

Earlier quoted context omitted.

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

Yes, but here's my hot take - what if you didn't have to edit the source code to debug it? Instead of chaining method calls you just assign to a temporary variable. Then you can set breakpoints and inspect variable values like you do normally without editing source. It's not like you lose that much readability from foo(bar(baz(c))) c |> baz |> bar |> foo c.baz().bar().foo() t = c.baz() t = t.bar() t = t.foo()

A debugger should let you inspect the value of any expression, not just variables.

Re: Pipelining might be my favorite programming language feature

#183
post #134

Lisp macros allow a general solution to this that doesn't just handle chained collection operators but allows you to decide the order in which you write any chain of calls. For example, we can write: (foo (bar (baz x))) as (-> x baz bar foo) If there are additional arguments, we can accommodate those too: (sin (* x pi) as (-> x (* pi) sin) Where expression so far gets inserted as the first argument to any form. If yo…

I find the threading operators in Clojure bring much joy and increase readability. I think it's interesting because it makes me actually consider function argument order much more because I want to increase opportunities to use them.

Re: Pipelining might be my favorite programming language feature

#184
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 >>=

Rust has such open extensibility through traits. The prime example is Itertools that already adds a bunch of extra pipelining helper methods.

Re: Pipelining might be my favorite programming language feature

#185
I think the biggest win for pipelining in SQL is the fact that we no longer have to explain that SQL execution order has nothing to do with query order, and we no longer have to pretend that we're mimicking natural language. (That last point stops being the case when you go beyond "SELECT foo FROM table WHERE bar LIMIT 10".)

No longer do we have to explain that expressions are evaluated in the order of FROM -> JOIN -> ON -> SELECT -> WHERE -> GROUP BY -> HAVING -> ORDER BY -> LIMIT (and yes, I know I'm missing several other steps). We can simply just express how our data flows from one statement to the next.

(I'm also stating this as someone who has yet to play around with the pipelining syntax, but honestly anything is better than the status quo.)

Re: Pipelining might be my favorite programming language feature

#186
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 simplifies debugging. Each step is obvious and it is trivial to insert logging between pipeline elements. It is easier to debug than the patterns compared in the article.

Exception handing is only a problem in languages that use exceptions. Fortunately there are many modern alternatives in wide use that don't use exceptions.

Re: Pipelining might be my favorite programming language feature

#187

The tidyverse folks in R have been using that for a while: https://magrittr.tidyverse.org/reference/pipe.html

R, specifically tidyverse, has a special place in my heart. Tidy principles makes data analysis easy to read and easy to use new functions, since there are standards that must be met to call a function "tidy."

Recently I started using Nushell, which feels very similar.

Re: Pipelining might be my favorite programming language feature

#189

While the author claims "semantics beat syntax every day of the week," the entire article focuses on syntax preferences rather than semantic differences. 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. They do make fun of Python, however. But don't say much about why they don't like it other than showi…

Agreed that long chains are hard to debug. I like to keep chains around the size of a short paragraph.

Re: Pipelining might be my favorite programming language feature

#190
post #185

I think the biggest win for pipelining in SQL is the fact that we no longer have to explain that SQL execution order has nothing to do with query order, and we no longer have to pretend that we're mimicking natural language. (That last point stops being the case when you go beyond "SELECT foo FROM table WHERE bar LIMIT 10".) No longer do we have to explain that expressions are evaluated in the order of FROM -> JOIN -…

You flipped SELECT and WHERE, which probably just solidifies your point. I can't count the number if times I've seen this trip up analysts.
Post reply on HN