5 ms·

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 saltedBatt

by 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.
lelanthran 5y ago
I feel, in your example, that the first code block is infinitely more useful to the maintainer than the second. It literally tells the reader what each step is *supposed* to do. That second example tells the reader that it is doing, which may or may not be what it was supposed to be doing. As a maintainer, I prefer knowing that: (add(salt, mix(water, flour)) is supposed to result in a salted batter, which the first code block tells me but the second one does not.
- Zababa 5y ago
  My whole point is that sometimes intermediate steps don't have good names. I often have to apply multiple transformations to a collection, but only the first and last step have a name because the intermediate steps are just that. "salted batter" is not a thing, it's just a placeholder name because you needed a name. You will never use "salted batter", you'll only use ingredients and bread.
  - lelanthran 5y ago
    > You will never use "salted batter", you'll only use ingredients and bread. For write-only code, sure, that's great. It's irrelevant when I am tracking down a bug - the label 'saltedBatter' tells me what that intermediate result is supposed to be. If, when debugging, I find that `add(salt, batter)` results in something else[1], using your convention it is literally impossible to tell that the value is supposed to be `saltedBatter`. There is literally no way to tell if the intermediate values are correct. Maybe each caller in the composition chain can throw an Exception? The point is, the variable names are helpful. > but only the first and last step have a name because the intermediate steps are just that. That describes the entire program :-) In all seriousness though, it's because you intend to describe steps in the process that throwing away all labels for the intermediate steps makes sense. You're describing verbs. We don't need to know the in-between verbs for a verb. When you call `driveTo()`, it is not necessary to know all the verbs involved in that action, it is enough to know that it will attempt a certain action. Verbs answers the "what we are doing" questions. Variable names answer the "Why we are doing it" questions - `saltedBatter = foo (bar(), baz);` tells the reader why foo is being called. We don't even need to know the steps involved or even what the other variables (used as parameters) should be. Assigning the result of a function to a variable ensures that the maintainer knows if that variable ever holds the wrong value. I think where a lot of this value (variable-names) is lost is in enterprise development - the names are never helpful, they're just a differently-cased version of the type. Like these gems I see daily: SomeClass someClass = foo(); List<OtherClass> otherClassList = bar(); .... return baz(someClass, otherClassList); So, yeah, I see your point if all you ever see is enterprise-grade naming conventions. OTOH, if those above two lines were written as: SomeClass needle = foo(); List<OtherClass> haystack = bar(); ... return baz(needle, haystack); you, as the maintainer, know exactly what that last line is supposed to do, and if it isn't doing that, then you know it's a bug. Compare with this: return (foo(), bar()); Or, if you wanted descriptive function names: return (calculateResult(), userSubmittedList()); Brevity is not a virtue in programming languages and/or programs. It's probably why Haskell is still not even a rounding error as far as popularity goes. [1] Maybe `doubleSaltedBatter`, in case an upstack caller used `saltedWater` in place of `water`, or perhaps `pepperedBatter` in case a caller switched out the salt for pepper.

by Zababa 5y ago

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.

lelanthran 5y ago

I feel, in your example, that the first code block is infinitely more useful to the maintainer than the second. It literally tells the reader what each step is *supposed* to do. That second example tells the reader that it is doing, which may or may not be what it was supposed to be doing. As a maintainer, I prefer knowing that: (add(salt, mix(water, flour)) is supposed to result in a salted batter, which the first code block tells me but the second one does not.

Zababa 5y ago
My whole point is that sometimes intermediate steps don't have good names. I often have to apply multiple transformations to a collection, but only the first and last step have a name because the intermediate steps are just that. "salted batter" is not a thing, it's just a placeholder name because you needed a name. You will never use "salted batter", you'll only use ingredients and bread.
- lelanthran 5y ago
  > You will never use "salted batter", you'll only use ingredients and bread. For write-only code, sure, that's great. It's irrelevant when I am tracking down a bug - the label 'saltedBatter' tells me what that intermediate result is supposed to be. If, when debugging, I find that `add(salt, batter)` results in something else[1], using your convention it is literally impossible to tell that the value is supposed to be `saltedBatter`. There is literally no way to tell if the intermediate values are correct. Maybe each caller in the composition chain can throw an Exception? The point is, the variable names are helpful. > but only the first and last step have a name because the intermediate steps are just that. That describes the entire program :-) In all seriousness though, it's because you intend to describe steps in the process that throwing away all labels for the intermediate steps makes sense. You're describing verbs. We don't need to know the in-between verbs for a verb. When you call `driveTo()`, it is not necessary to know all the verbs involved in that action, it is enough to know that it will attempt a certain action. Verbs answers the "what we are doing" questions. Variable names answer the "Why we are doing it" questions - `saltedBatter = foo (bar(), baz);` tells the reader why foo is being called. We don't even need to know the steps involved or even what the other variables (used as parameters) should be. Assigning the result of a function to a variable ensures that the maintainer knows if that variable ever holds the wrong value. I think where a lot of this value (variable-names) is lost is in enterprise development - the names are never helpful, they're just a differently-cased version of the type. Like these gems I see daily: SomeClass someClass = foo(); List<OtherClass> otherClassList = bar(); .... return baz(someClass, otherClassList); So, yeah, I see your point if all you ever see is enterprise-grade naming conventions. OTOH, if those above two lines were written as: SomeClass needle = foo(); List<OtherClass> haystack = bar(); ... return baz(needle, haystack); you, as the maintainer, know exactly what that last line is supposed to do, and if it isn't doing that, then you know it's a bug. Compare with this: return (foo(), bar()); Or, if you wanted descriptive function names: return (calculateResult(), userSubmittedList()); Brevity is not a virtue in programming languages and/or programs. It's probably why Haskell is still not even a rounding error as far as popularity goes. [1] Maybe `doubleSaltedBatter`, in case an upstack caller used `saltedWater` in place of `water`, or perhaps `pepperedBatter` in case a caller switched out the salt for pepper.