One issue (problem) with the pipe is that in one way it hides what you are doing. Yes, you can see the actual operations being done but it can also hide what the actual data along the way is. Yes, you can add comments. However, using assignments means that you automatically do get information about what the actual data along the way is (at least if you use reasonable variable names).

I am not saying that you should avoid pipes and always use assignments, but I do think you can go too far with long pipe sequences.

This gets back to what I think is a very important question: for whom and why are you writing this code? Is it a quick hack which you don’t expect to have a long life? If it is for a product you envisage to be in use a long time which other people will maintain and develop then it is very important that you write clear, easily understandable and very explicit code. In this case maybe using judiciously using assignments can be a Good Thing™. I try to ask myself “in six months time will I understand what i have done here?” [*]

What I was really poking fun at was how far they had gone with the Kernel.- to be available to use a pipe.

[*] This also explains my opinion on having too many implicit default values which I can vent in a later post.

It is much harder to grasp than

remaining_time = max(0, interval - elapsed_time)
schedule_events(remaining_time)

Another point to consider: pipelines are quite clear when a new version of the same thing is being passed along to each function, but when the context of what is being passed changes midway through, that makes it hard to read. A Plug.Conn being passed through adding headers, setting status, body, sending, etc is the perfect example of a good use.

In your example, even though it’s a number being passed, what that number represents is different at each stage. And the fact that foo |> Kernel.-(bar) is vastly less clear than foo - bar means you’re starting off the pipeline with the very first step obscuring rather than clarifying.