4 ms·

Function composition is connecting the output of one function to the input of another. In math it is (f ∘ g)(x) = f(g(x)) Or in javascript: function f(x) { re

Function composition is connecting the output of one function to the input of another. In math it is (f ∘ g)(x) = f(g(x)) Or in javascript: function f(x) { return x + 1 } function g(x) { return x + 2 } f(g(1)) === 4 In functional languages like Haskell function composition is made easy, because functions can be partially applied. Partial application means that given a function that takes two arguments, I can call it with one argument and it will return a function that takes one argument which returns the result. Whereas in languages like javascript it is difficult because functions can have different numbers of arguments and there's no way to partially apply them or flip their arguments, so it is difficult to chain functions together. And because javascript functions aren't pure, they may not have any result which can be composed with other functions. In a functional language, functions are more like the functions in math. In most non-functional languages, functions are more like a procedure of commands. For example, the javascript function logMe(x) { console.log(x) } doesn't return anything. So it can't be composed functionally, and is not like a "real" function.

8note 5y ago
JavaScript has bind() on functions which works well enough. You can partially apply arguments, but I don't think you can project them to a different order.
eternityforest 5y ago
JavaScript has closures. When you want to partially apply something(Which is technically never, because we would probably describe it in different words and think of it differently) we just make a new function. When we want to "compose" two functions, there's f(x){return a(b(x))}. It doesn't matter if the signatures are different, you don't need any nice logical idea of composition, you just explicitly build the new function that does what you want. I would say that is a lot easier than real composition, because real composition requires you first learn to see and think in terms of patterns you would want to compose in the first place. Also, function chaining doesn't use intermediate variables. Named variables are like free documentation. With composition you have to actually remember what you're doing. Making everything explicit makes it easier to comment what's happening. Regular programming is to math as cooking is to chemistry. Functional brings the math back to programming. Math is useful but also hard. In OOP, more often you're doing the equivalent of: if crinkle(a(b(x,68), modes.FOO).bar.baz(9)): x = foo() else: x = wipe(7).bar() And I think it's a lot nicer to just spell it out with meaningful variable names, instead of trying to compose it like an equation.
- Zababa 5y ago
  Not every step has a meaningful name. And usually you already have the name of the function. For example: let batter = mix(water, flour) let saltedBatter = add(salt, batter) let risenSaltedBatter = letToRise(saltedBatter) let bread = bake(batter) on the other hand: let bread = bake(letToRise(add(salt, mix(water, flour))) The first example leads to awkward names and useless variables. The second example feels cleaner to me. Interesting that you take cooking as an example: recipes usually don't name most of the intermediate steps, they describe the actions you take and the ingredients you use. Most recipes also use composition a lot. You start with your actions/functions (cut, cook, bake, dice, etc) and you do a recipe out of them. You don't create new "functions" (actions) specifically for each recipe.
  - eternityforest 5y ago
    Recipes are a lot closer to configuration DSLs than code though. You have standard functions like bake and boil, and they don't tell you to use clean utensils or how to turn the stove on, because an cooking is basically just a few dozen standard functions, end condition rules, etc. If you think of them as programs, the composition they use isn't the same as functional languages, because the individual steps are unstructured and there's no generalized abstract pattern defining what a RecipeStep is or what composing two of them means. You wouldn't say add(flour(add(salt,empty))), you would say "add flour, salt, water, and yeast". "add" can take either an ingredient or a list, and it's pretty encapsulated, since it dynamically selects a way to measure the ingredient based on what it is, what utensils you have, etc. It could trigger dozens of unrelated code paths based on state, and probably includes error recovery. Functional might be nice for implementing the internals of that add() function, but in OOP the idea seems to be that it's a pretty minor detail, since add() is only written once and rarely changed, but used millions and millions of times all over the world for a decade. Usually when people talk about "the beauty of functional" I get the impression that they're not really doing a whole lot of "One really smart function that knows exactly what to do" level abstraction. It seems like they'd literally be composing together their own variations of what "add" is, as needed from the raw findMeasuringStrategy and checkPantry functions instead.
  - 5y ago

8note 5y ago

JavaScript has bind() on functions which works well enough. You can partially apply arguments, but I don't think you can project them to a different order.

eternityforest 5y ago

JavaScript has closures. When you want to partially apply something(Which is technically never, because we would probably describe it in different words and think of it differently) we just make a new function. When we want to "compose" two functions, there's f(x){return a(b(x))}. It doesn't matter if the signatures are different, you don't need any nice logical idea of composition, you just explicitly build the new function that does what you want. I would say that is a lot easier than real composition, because real composition requires you first learn to see and think in terms of patterns you would want to compose in the first place. Also, function chaining doesn't use intermediate variables. Named variables are like free documentation. With composition you have to actually remember what you're doing. Making everything explicit makes it easier to comment what's happening. Regular programming is to math as cooking is to chemistry. Functional brings the math back to programming. Math is useful but also hard. In OOP, more often you're doing the equivalent of: if crinkle(a(b(x,68), modes.FOO).bar.baz(9)): x = foo() else: x = wipe(7).bar() And I think it's a lot nicer to just spell it out with meaningful variable names, instead of trying to compose it like an equation.

Zababa 5y ago
Not every step has a meaningful name. And usually you already have the name of the function. For example: let batter = mix(water, flour) let saltedBatter = add(salt, batter) let risenSaltedBatter = letToRise(saltedBatter) let bread = bake(batter) on the other hand: let bread = bake(letToRise(add(salt, mix(water, flour))) The first example leads to awkward names and useless variables. The second example feels cleaner to me. Interesting that you take cooking as an example: recipes usually don't name most of the intermediate steps, they describe the actions you take and the ingredients you use. Most recipes also use composition a lot. You start with your actions/functions (cut, cook, bake, dice, etc) and you do a recipe out of them. You don't create new "functions" (actions) specifically for each recipe.
- eternityforest 5y ago
  Recipes are a lot closer to configuration DSLs than code though. You have standard functions like bake and boil, and they don't tell you to use clean utensils or how to turn the stove on, because an cooking is basically just a few dozen standard functions, end condition rules, etc. If you think of them as programs, the composition they use isn't the same as functional languages, because the individual steps are unstructured and there's no generalized abstract pattern defining what a RecipeStep is or what composing two of them means. You wouldn't say add(flour(add(salt,empty))), you would say "add flour, salt, water, and yeast". "add" can take either an ingredient or a list, and it's pretty encapsulated, since it dynamically selects a way to measure the ingredient based on what it is, what utensils you have, etc. It could trigger dozens of unrelated code paths based on state, and probably includes error recovery. Functional might be nice for implementing the internals of that add() function, but in OOP the idea seems to be that it's a pretty minor detail, since add() is only written once and rarely changed, but used millions and millions of times all over the world for a decade. Usually when people talk about "the beauty of functional" I get the impression that they're not really doing a whole lot of "One really smart function that knows exactly what to do" level abstraction. It seems like they'd literally be composing together their own variations of what "add" is, as needed from the raw findMeasuringStrategy and checkPantry functions instead.
- 5y ago