The advantage is that you don't have to name things. "v" is a bad name in a larger context, and it quikly becomes unwieldy if you use a full name.
let transformedData = transformFoo(data);
transformedData = transformBar(transformedData);
transformedData = transformBaz(transformedData);
vs.
const transformedData = data
|> transformFoo
|> transformBar
|> transformBaz
If you want have const's the first becomes even more unwieldy, and in general I'd recommend using const by default.
Just like lambda syntax makes it much easier and readable to write small functions, the pipe operator make it much easier and readable to write chains.
I find |> annoying to type. How about making it so unary functions can be invoked like this?
arg function_name
Then instead of
arg |> func1 |> func2 |> func3
you could simply write
arg func1 func2 func3
It might get a bit ugly when used with arrow functions instead of named functions, and there might need to be a special case when arg is a function, but if those problems could be handled not too unreasonably this seems a fine approach for a programming language.
Just like lambda syntax makes it much easier and readable to write small functions, the pipe operator make it much easier and readable to write chains.
succinct =/= more readable.
Readability here is really in the eye of the beholder...
It's certainly quicker to type, but that's not a good argument enough to make such a drastic change in javascript.
It's certainly quicker to type, but that's not a good argument enough to make such a drastic change in javascript.
I am so glad this argument has not been winning out in the JavaScript language design community. There are so many wonderful constructs that have been added in the last 20 years that are just sorter ways to write things that could mostly already be done in the language. Many of these features focused on allowing developers to write what they intended to do without having to explicitly construction the intermediate steps to express the mechanics of how that should be carried out using basic language features.
After all why do we need arrow functions when we could just sprinkle our code with `var self = this;` declarations for anonymous functions to bind to, the way it was done in the late 90's and early 00's.
I'd much rather JavaScript adopt succinct ways to write common code patterns and let the developers and the community decide if those constructs are the correct ones to use on a case by case basis.
I am so glad this argument has not been winning out in the JavaScript language design community. There are so many wonderful constructs that have been added in the last 20 years that are just sorter ways to write things that could mostly already be done in the language.
Beware of survival bias, though. There have been many proposals that aren't part of JS today.
Comments
The advantage is that you don't have to name things. "v" is a bad name in a larger context, and it quikly becomes unwieldy if you use a full name.
If you want have const's the first becomes even more unwieldy, and in general I'd recommend using const by default.Just like lambda syntax makes it much easier and readable to write small functions, the pipe operator make it much easier and readable to write chains.
I find |> annoying to type. How about making it so unary functions can be invoked like this?
Then instead of you could simply write It might get a bit ugly when used with arrow functions instead of named functions, and there might need to be a special case when arg is a function, but if those problems could be handled not too unreasonably this seems a fine approach for a programming language.succinct =/= more readable.
Readability here is really in the eye of the beholder...
It's certainly quicker to type, but that's not a good argument enough to make such a drastic change in javascript.
I am so glad this argument has not been winning out in the JavaScript language design community. There are so many wonderful constructs that have been added in the last 20 years that are just sorter ways to write things that could mostly already be done in the language. Many of these features focused on allowing developers to write what they intended to do without having to explicitly construction the intermediate steps to express the mechanics of how that should be carried out using basic language features.
After all why do we need arrow functions when we could just sprinkle our code with `var self = this;` declarations for anonymous functions to bind to, the way it was done in the late 90's and early 00's.
I'd much rather JavaScript adopt succinct ways to write common code patterns and let the developers and the community decide if those constructs are the correct ones to use on a case by case basis.
Beware of survival bias, though. There have been many proposals that aren't part of JS today.