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

Yeah, I agree that this can be problem when you lean heavily into monadic handling (i.e. you have fallible operations and then pipe the error or null all the way through, losing the information of where it came from).

But that doesn't have much to do with the article: You have the same problem with non-pipelined functional code. (And in either case, I think that it's not that big of a problem in practice.)

> The author uses examples that function very differently.

Yeah, this is addressed in one of the later sections. Imo, having a unified word for such a convenience feature (no matter how it's implemented) is better than thinking of these features as completely separate.

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()

I feel like a sufficiently good debugger should allow you to place a breakpoint at any of the lines here, and it should break exactly at that specific line.

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

It sounds to me like you're asking for linebreaks. Chaining doesn't seem to be the issue here.

I'm only familiar with C++, Python, and SQL. Neither GDB nor PDB helps here, and I've never heard of a SQL debugger that will break apart expressions and let you view intermediate query results.

You can use EXPLAIN and similar keywords to see the execution plans in common SQL database engines. In practice you don't really care about the actual intermediate data so it doesn't show it, usually it's enough to learn whether indices are used at every step.

But you could in many cases easily infer from the execution plan what a query would look like and fetch an intermediate set separately.

That'd be problematic, but also sounds like a (solvable) tooling problem to me.

It’s been a while since I’ve used one, but I’m fairly sure the common debuggers for C#, F#, Rust and Java would all behave correctly when breakpointed like this.

Jetbrains Rider does this does for C# code (I think Visual Studio does as well). Its inlay hints feature will also show you hints with the result type of each line as the data is transformed. I haven't explicitly tested but I would imagine their IDEs for other languages behave the same.

The Clojure equivalent of `c |> baz |> bar |> foo` are the threading macros:

    (-> c baz bar foo)

But people usually put it on separate lines:

    (-> c
        baz
        bar
        foo)

And with the Emacs Enlighten feature the second version enables seeing the results of each step right in the editor, to the right of the step.

You can achieve something similar in Clojure with the Flowstorm debugger[0] (it's free).

[0] https://www.flow-storm.org/

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

I think you may have misinterpreted his motive here.

Just before that statement, he says that it is an article/hot take about syntax. He acknowledges your point.

So I think when he says "semantics beat syntax every day of the week", that's him acknowledging that while he prefers certain syntax, it may not be the best for a given situation.

the paragraph you quoted (atm, 7 mins ago, did it change?) says:

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

It's just as difficult to debug when function calls are nested inline instead of assigning to variables and passing the variables around.

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

The article also clearly points that that it's just a hot-take, and to not take it too seriously.