Epistemic status: Don’t take it too seriously. Or do. idk, I can’t stop you.

Pipelining might be my favorite programming language feature.

What is pipelining? Pipelining is the feature that allows you to omit a single argument from your
parameter list, by instead passing the previous value.

When I say pipelining, I’m talking about the ability to write code like this:

fn get_ids(data: Vec<Widget>) -> Vec<Id> {
    data.iter()              // get iterator over elements of the list
        .filter(|w| w.alive) // use lambda to ignore tombstoned widgets
        .map(|w| w.id)       // extract ids from widgets
        .collect()           // assemble iterator into data structure (Vec)
}

As opposed to code like this. (This is not real Rust code. 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?)

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

I honestly feel like this should be so obvious that it shouldn’t even be up for debate. The first code
example—with its nice ‘pipelining’ or ‘method chaining’ or whatever you want to call it—it
just works. It can be read line-by-line. It’s easy to annotate it with comments. It doesn’t
require introduction of new variables to become more readable since it’s already readable as is.

As opposed to, y’know,
the first word in the line describing the final action our function performs.

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

Second, this is not about imperative vs. functional programming. This article takes for granted that
you’re already on board with concepts such as ‘map’ and ‘filter’. It’s possible to overuse that style, but
I won’t talk about it here.

• You already agree with me
• Code Discovery
• Editing Benefits
• SQL
• The Builder Pattern
• Rust’s pipelining is pretty neat
• Conclusion

You already agree with me

Here is a feature that’s so bog-standard in modern programming languages that it barely feels like a
feature at all. Member access for structs or classes with our beloved friend the .-operator.

This is a form of pipelining. It puts the data first, the operator in the middle, and concludes with the
action (restricting to a member field). That’s an instance of what I call pipelining.

type Bar struct {
	field int
}

func get_field(bar Bar) int {
	return bar.field
}
// vs. syntax like that of Python's `getattr` function
func get_field(bar Bar) int {
	return getattr(bar, "field")
}

You see what I am getting at, right? It’s the same principle. One of the reasons why
x.y-style member access syntax (and x.y()-style method call syntax!) is popular
is since it’s easy to read and chains easily.

Let’s make the comparison slightly more fair, and pretend that we have to write x.get(y).
Compare:

fizz.get(bar).get(buzz).get(foo)
// vs.
get(get(get(fizz, bar), buzz), foo)

Which one of these is easier to read? The pipelined syntax, obviously. This example is easy to parse
either way, but imagine you’d like to blend out some information and purely focus on the final operation.

.get(foo)
// vs.
get(, foo)

You see the problem, right? In the first example, we have ‘all of the previous stuff’ and then
apply another operation to it. In the second example, the operation which we want to perform
(get) and the new operand (foo) are spread out with ‘all of the previous stuff’
sitting between them.

Looking back at our original example, the problem should be obvious:

fn get_ids(data: Vec<Widget>) -> Vec<Id> {
    collect(map(filter(iter(data), |w| w.alive), |w| w.id))
}
-----------------------------1 // it's fun to parse the whole line to find the start
------------------------2
-----------------3
---------------------------------------4 // all the way back to find the second arg
-------------5
------------------------------------------------------6 // and all the way back again
-----7 // okay the final step is the first word in the line that makes sense

I cannot deny the allegations: I just don’t think it makes sense to write code like that as long as a
clearly better option exists.

Why would I have to parse the whole line just to figure out where my input comes in, and why is the data
flow ‘from the inside to the outside’? It’s kind of silly, if you ask me.

Editing Benefits

Readability is nice, and I could add add a whole section complaining about the mess that’s Python’s
‘functional’ features.

However, let’s take a step back and talk about ease of editing. Going back to the example above, imagine
you’d like to add another map (or any other function call) in the middle there. How easy is
this?

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

Consider:

1. You’ll have to parse through the line, counting commas and parentheses to find the exact place to add
   the closing parenthesis.
2. The git diff of this is going to be basically unreadable, everything is crammed onto one
   line.
3. This line is getting long and unreadable, and at that point you’ll want to refactor it anyway!

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

This is adding a single line of code. No parentheses counting. It’s easy and obvious. It’s easy to write
and easy to review. Perhaps most importantly, it shows up incredibly nicely in the
blame layer of whatever editor or code exploration tool you’re using.

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.

You can, of course, just assign the result of every filter and map call to a
helper variable, and I will (begrudgingly) acknowledge that that works, and is
significantly better than trying to do absurd levels of nesting.

Code Discovery

When you press . in your IDE, it will show a neat little pop-up that tells you which methods
you can call or which fields you can access.

This is probably the single IDE feature with the biggest value add, and if not that, then at least the
single most frequently used one. Some people will tell you that static analysis for namespace or
module-level code discovery is useless in the age of AI autocompletion and vibe coding, but I very much
disagree.¹

A wise shaman once said:

“grug very like type systems make programming easier. for grug, type systems most value when grug hit
dot on keyboard and list of things grug can do pop up magic. this 90% of value of type system or more to
grug” — grug

Words to live by. What he’s describing here is something that essentially requires pipelining to
work at all. (And types or type annotation, but having those is the direction the industry is moving in
anyway.)

It doesn’t matter if it’s the trusty . operator, C++’s ->, or if it’s
something more bespoke such as Elm’s or Gleam’s |> or Haskell’s &. In the
end, it’s a pipeline operator—the same principle applies. If your
LSP knows the type of
what’s on the left, it should in principle be able to offer suggestions for what to do next.

If your favorite language’s LSP/IDE does a poor job at offering suggestions during pipelining, then it’s
probably one of the following reasons:

1. You don’t know which type you’re even holding. This happens most often when the language is dynamically
   typed, ’types’ are hard to deduce with static analysis, and you’re touching/writing code without t