4 ms·

The onions seem like the wrong metaphor here, since you are going from inside to outside. Concerning the final note: that is already the case. And then one abs

The onions seem like the wrong metaphor here, since you are going from inside to outside. Concerning the final note: that is already the case. And then one abstracts away from that for two reasons: 1. This works just as well for boats, trucks or non-vehicles, so you use v and a. 2. Have you ever tried to write and read a formula like MassOfTheCar * VelocityOfTheCar * VelocityOfTheCar /2 =....? Notation needs to be actually usable in practice, not just pretty for single line examples.

adam_arthur 5y ago
> The onions seem like the wrong metaphor here, since you are going from inside to outside. I'm describing a "top down" approach, as opposed to "bottom up". Or outside in, rather than inside out. > Notation needs to be actually usable in practice, not just pretty for single line examples. Yes, math was practiced long before computers were a thing. There's a reason it's considered a bad practice to use single letter variables in code. I can assure you it's much easier to read complicated formulas in well written code than in conventional math notation! If you were to use all one letter variable names and cram all computations into a single large expression, that would be considered by most to be poor code. There's a reason why, and it's been proven out in industry. Math is no different, other than cultural biases and historical reasoning.
- diffeomorphism 5y ago
  In math what you suggest is considered bad practice and there is also a strong reason why. Handwaving that away as "bias" or "history" is extremely rude. Both approaches have their merits and optimize for different uses. This could be an interesting discussion, but you seem uninterested in having one.
  - adam_arthur 5y ago
    I'm open to being convinced! What is the strong reason?
    - Quekid5 5y ago
      Not PP, but I can guess at a few, at least: - It easier to see the 'essence' of an equation/problem when all irrelevant detail is omitted. - Many concepts are so general that you'd need a small essay to have a 'descriptive' name, rather than just, say, x. - Algebraic manipulation often leads to non-intuitive concepts in intermediate calculations, e.g. meter-dollars. It's handy to be able to just call such a thing 'a' (or whatever) if it helps make calculations easier.
- nemetroid 5y ago
  > I can assure you it's much easier to read complicated formulas in well written code than in conventional math notation! I could not disagree more. The long names obstruct the shapes of the expressions, making it difficult to recognize common concepts visually. There's a higher need for intermediate variables (to avoid expressions becoming physically too long), and the intermediate variable names often need to be very long to properly describe their meaning (and may represent highly abstract concepts). Terser code can avoid trying to name these things that cannot be meaningfully named. > If you were to use all one letter variable names and cram all computations into a single large expression, that would be considered by most to be poor code. There's a reason why, and it's been proven out in industry. I agree that it's not a good idea to put everything in a single expression. But it's not a good idea to put every single mathematical expression in its own variable either, and in my experience the sweet spot lies much closer to the terse code. I've worked with math-heavy code in both terse and verbose styles, and refuse to work on verbose math code again.

adam_arthur 5y ago

> The onions seem like the wrong metaphor here, since you are going from inside to outside. I'm describing a "top down" approach, as opposed to "bottom up". Or outside in, rather than inside out. > Notation needs to be actually usable in practice, not just pretty for single line examples. Yes, math was practiced long before computers were a thing. There's a reason it's considered a bad practice to use single letter variables in code. I can assure you it's much easier to read complicated formulas in well written code than in conventional math notation! If you were to use all one letter variable names and cram all computations into a single large expression, that would be considered by most to be poor code. There's a reason why, and it's been proven out in industry. Math is no different, other than cultural biases and historical reasoning.

diffeomorphism 5y ago
In math what you suggest is considered bad practice and there is also a strong reason why. Handwaving that away as "bias" or "history" is extremely rude. Both approaches have their merits and optimize for different uses. This could be an interesting discussion, but you seem uninterested in having one.
- adam_arthur 5y ago
  I'm open to being convinced! What is the strong reason?
  - Quekid5 5y ago
    Not PP, but I can guess at a few, at least: - It easier to see the 'essence' of an equation/problem when all irrelevant detail is omitted. - Many concepts are so general that you'd need a small essay to have a 'descriptive' name, rather than just, say, x. - Algebraic manipulation often leads to non-intuitive concepts in intermediate calculations, e.g. meter-dollars. It's handy to be able to just call such a thing 'a' (or whatever) if it helps make calculations easier.
nemetroid 5y ago
> I can assure you it's much easier to read complicated formulas in well written code than in conventional math notation! I could not disagree more. The long names obstruct the shapes of the expressions, making it difficult to recognize common concepts visually. There's a higher need for intermediate variables (to avoid expressions becoming physically too long), and the intermediate variable names often need to be very long to properly describe their meaning (and may represent highly abstract concepts). Terser code can avoid trying to name these things that cannot be meaningfully named. > If you were to use all one letter variable names and cram all computations into a single large expression, that would be considered by most to be poor code. There's a reason why, and it's been proven out in industry. I agree that it's not a good idea to put everything in a single expression. But it's not a good idea to put every single mathematical expression in its own variable either, and in my experience the sweet spot lies much closer to the terse code. I've worked with math-heavy code in both terse and verbose styles, and refuse to work on verbose math code again.