I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
First off, there is nothing in FP that says you have to decompose every single operation to the greatest degree possible and make everything operate in a curied manner. This is simply stuff that functional purists want, but a lot of it actually doesn’t have much practical benefit to developers or users.
Composition is useful in a number of cases, but it becomes visibly less practical the smaller your functional units are. Same for the concept of pipelines.
As an easy example, the following two samples of Elixir code are functionally identical, but the second is far more readable for most people (the |> operator in Elixir takes the value on the left side and passes it as the first argument to the function on the right, evaluating left to right as it goes):
x=f(g(h(y)))
x=y|>f()|>g()|>h()
Of course, you could also do the same thing with temporary variables (and that would be the norm in many languages that have mutable data types), but that requires you as the developer to keep track of more things. And, again, this looks impractical to some because of how short the sequence is, but once you have a pipeline a dozen or more functions long, or all the parts of the pipeline take anonymous functions in addition to the starting argument, it makes things visibly less cleaner.
I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
Quite so. I’m obviously not used to writing pipes all on one line in Elixir (though that kind of makes sense, as the main places where this gets used are longer sequences of calls with multiple arguments to the individual functions, and there it’s preferred to have a newline before each pipe operator and have them all lined up under the initial value being operated on).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
First off, there is nothing in FP that says you have to decompose every single operation to the greatest degree possible and make everything operate in a curied manner. This is simply stuff that functional purists want, but a lot of it actually doesn’t have much practical benefit to developers or users.
Composition is useful in a number of cases, but it becomes visibly less practical the smaller your functional units are. Same for the concept of pipelines.
As an easy example, the following two samples of Elixir code are functionally identical, but the second is far more readable for most people (the
|>operator in Elixir takes the value on the left side and passes it as the first argument to the function on the right, evaluating left to right as it goes):Of course, you could also do the same thing with temporary variables (and that would be the norm in many languages that have mutable data types), but that requires you as the developer to keep track of more things. And, again, this looks impractical to some because of how short the sequence is, but once you have a pipeline a dozen or more functions long, or all the parts of the pipeline take anonymous functions in addition to the starting argument, it makes things visibly less cleaner.
Isn't it other way around?
|>operator is calledpipe, you can construct similar function in JSQuite so. I’m obviously not used to writing pipes all on one line in Elixir (though that kind of makes sense, as the main places where this gets used are longer sequences of calls with multiple arguments to the individual functions, and there it’s preferred to have a newline before each pipe operator and have them all lined up under the initial value being operated on).