While yes, pipes improve readability, how do they deal with errors? How do they deal with understanding what each thing is supposed to return?
I would prefer something like this, (descriptive variable names):
```
var userData = other_function();
var userDetails = new_function(userData);
var userComments = baz(userDetails);
var userPosts = bar(userComments);
var finalUserDetails = foo(userPosts);
return finalUserDetails;
```
Then I can easily debug each step, I can easily understand what each call is supposed to do, if I'm using type script, I can assign types to each variable.
I strongly oppose clean code for the sake of looking pretty, or being quick to type. Code is meant to be run and read more then written, it should be descriptive, it should describe what it's doing not a nasty chain of gibberish. Hence why most people hate REGEX.
I think there is merit to the argument that if naming is one of the hard problems, programmers writing that code are having to do a lot of ‘naming’ and that is hard for them. The proposed pipe operation eliminates those names and lets the programmer just use %.
But these variables are rarely the kind of thing it’s hard to name, so it feels like a slightly disingenuous argument.
Usually that effort should go toward naming functions rather than their results, though, and if the functions have good names, the results don't need them. In this example, `other_function` could have been named `get_user_data`, `new_function` could have been called `extract_user_details`, whatever.
Once you have good function names, which you should generally be spending a lot more effort on than good local variable names, you won't find any value in adding variables like `var foo = get_foo()`.
A good language treats errors as a first class type. Functions that can error have no business returning an A.
Example given, the fetch API, is basically typed as fetch<A>(): Promise<A>
In reality, there might not be A at all, it should return a data type such as Either (or Result) which encodes linearly and forces the consumer to consider and handle the error.
There's nothing stopping JS devs from combining pipes with heavy use of a Maybe library. You don't need to use pipes everywhere, but it would be useful for a system that was designed with that pattern in mind.
I already use Maybe patterns quiet a bit in my TS project but there always the libraries and frameworks you work with that don't. So yeah I can see it being a language level thing (the way Promises were used) pushing for wide adoption.
Elixir handles errors as you describe, the example does not cover it. The pipeline also assumes a single direction, which pushes error handling to the next step, but there are also constructs (case and with) for handling and composing errors in one go.
``` foo(bar(baz(new_function(other_function())))) ```
They offer this example of an improvement:
``` other_function() |> new_function() |> baz() |> bar() |> foo() ```
While yes, pipes improve readability, how do they deal with errors? How do they deal with understanding what each thing is supposed to return?
I would prefer something like this, (descriptive variable names):
``` var userData = other_function();
var userDetails = new_function(userData);
var userComments = baz(userDetails);
var userPosts = bar(userComments);
var finalUserDetails = foo(userPosts);
return finalUserDetails; ```
Then I can easily debug each step, I can easily understand what each call is supposed to do, if I'm using type script, I can assign types to each variable.
I strongly oppose clean code for the sake of looking pretty, or being quick to type. Code is meant to be run and read more then written, it should be descriptive, it should describe what it's doing not a nasty chain of gibberish. Hence why most people hate REGEX.