3 ms·

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 an

by 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.
- ParetoOptimal 5y ago
  > Brevity is not a virtue in programming languages and/or programs. Real world Haskell code isn't the codegolf you are implying. In fact, I think real world Haskell devs overcorrect and make code too verbose. Also, "brevity is not a virtue in programming languages" is something I disagree with. Walls of verbose code are just so damn mentally taxing. Especially hen you finish reading and saybto yourself "all that code just to do X?".

by Zababa 5y ago

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.

ParetoOptimal 5y ago
> Brevity is not a virtue in programming languages and/or programs. Real world Haskell code isn't the codegolf you are implying. In fact, I think real world Haskell devs overcorrect and make code too verbose. Also, "brevity is not a virtue in programming languages" is something I disagree with. Walls of verbose code are just so damn mentally taxing. Especially hen you finish reading and saybto yourself "all that code just to do X?".